Hi,
I'm looking for some guidance on the best practices for configuring Ziti to secure and share a message queue application. My specific use case involves a persistent TCP connection to the message queue, and I need to handle a relatively high throughput, specifically around hundreds of transactions per second (TPS) for both publishing and subscribing data.
Given above requirement, can I get suggestion of ziti configuration, whether in the edge-tunneler side, or in the router or controller side? Maybe I need to ramp up openfile config or something like that? Or maybe the architecture (need more than 1 router, etc). Thanks in advance for your help.
Hi All,
Just want to bump this question again? Any best practice if I want to use openziti to expose high traffic message queue with persistent tcp connection? Maybe there is configuration in openziti that limit the lifetime of persistent tcp connection that I should know?
Thanks in advance for your help.
Hi @rsatrio, welcome to the communtiy and to OpenZiti!
I don't think there's anything special you should do. Generally speaking you want an edge router as close to both sides as you can get to onboard to fabric as soon as possible so that it can route traffic across the fastest path.
There really isn't anything other than that, that I can think of that's really vitally important. You'll want to watch all the metrics, every network is different so there are none I can say are more important than another without doing that work to figure out which metrics might be best for you to watch. (metrics doc Overview | OpenZiti)
Personally, I just recommend people start with one controller and a couple of edge routers, do that monitoring, and iterate the design as it evolves. It's always a pretty individual thing to tweak, but I think you just need to experiment and look at logs/monitoring. Sorry I don't have any more detailed advice to share. Let us know how you get along! 
hth
@TheLumberjack thanks for your suggestion. Will try it and report here if there are any problems
On the question of the persistent TCP connection, there is an option to put an idle timer on a service, but it is off by default, and there are no other functions that will close a connection without an error condition. Throughput isn't very stressful to the system, honestly. If you are pushing a lot of data through persistent connections, the resources should scale very linearly. Watch the CPU and memory resources, and you should be fine.