Hi, Thanks a lot for all the replies. The problem was a single connection, once I moved to 1 session/connection the problem resolved.
Regards, Siva. On Thu, May 14, 2015 at 1:24 PM, Alan Conway <[email protected]> wrote: > On Wed, 2015-05-06 at 22:38 -0700, Sivananda Reddys Thummala Abbigari > > Based on the above comments I have a questions here to both of you guys: > > "How many sessions do you normal use per connection, in production?. > Also, > > if we have one sessions per connection we would be bound by number of > > TCP/IP connections to the broker at some point(OS would need to maintain > > more file handlers as the number of connections increase)". Could you > > please suggest how many connections should I be using?. Please advice. > > > > The number of sessions is not really significant. Sessions are cheap but > you don't get much for your money ;) They are significant if you need > multiple parallel transactions over a connection, otherwise not really. > > The performance issue is connections. The connection is a point of > serialization (it's just a TCP connection after all) Even if you feed > many sessions or links concurrently from threads, the data all has to > line up to leave the process if it's on one connection. > > On the broker side, the connection is the unit of concurrency so a > broker running on a multi-core host will be able to do more work in > parallel if there are more connections. > > It's no different from other protocols. A httpd on a multi-core machine > can parallelize more of the work if it gets 1 request each on N > connections than if it gets N requests sequentially on 1 connection. > > So if an application will have a lot of clients, a throughput or scale > benchmark should have a lot of connections (ideally from separate > clients on separate hosts on an unloaded network, but it is never > ideal ;) Stuffing all the test data down one connection will give you an > idea of througput for a single client, but will not give an accurate > idea of how the broker scales with more clients. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
