On 05/07/2015 06:38 AM, Sivananda Reddys Thummala Abbigari wrote:
Hi Gordon/Rob,
Sincere apologizes for the delayed response.
Please find my responses:
@Gordon:
Q) You don't mention which client/broker you are using. However I think its
true in most cases that there will be no performance benefit in running the
producers and consumers in parallel if they share a connection.
A) I am using Java client/broker. Right, I agree with you, I saw that by
decreasing number of sessions per connection I saw the increase in response
times.
Q) What is it exactly you want to test here? Is having lots of
sessions/producers/consumers on the same connection an important aspect?
A) My test case is simple, I create a topic and there are multiple
publishers/durable subscribers to that topic. My test case doesn't need
many sessions per connection(I just experimented with many sessions per
connection).
@Rob:
Q) In particular, how big are the messages you are sending? Are they transient
or persistent (if the latter then which store are you usin - Derby or BDB
or a JDBC store)? Are you using transactions, if not which acknowledgement
mode are you using?
A) I am sending a serialized object(which contains a string(< 500 chars),
two timeStamp variables) to the receiver. I am running a single border and
so didn't use any storage for HA purposes. I am not using transactions. I
am suing AUTO_ACKNOWLEDGE mode. My test case is very simple.
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.
How many subscribers do you expect to have? I would start off with a
connection per subscriber, and only revisit that if there were some real
need.
If the subscribers are on the same topic, there isn't really any need to
have more than one in the same process anyway. Why would you need to
pull the exact same set of messages off the broker more than once.
If what you want to do is *distribute* the messages between competing
consumers, then you want a shared subscription, or a queue bound to the
exchange with multiple consumers on the queue (to put in pre 1.0 model
terms). That way each subscription is pulling a different set of
messages that are processed in parallel for greater overall throughput.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
