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. Thank you, Siva. On Tue, May 5, 2015 at 3:43 AM, Rob Godfrey <[email protected]> wrote: > Hi Siva, > > Firstly are you testing the Java or the C++ broker? Which client? > > Secondly, it would probably help to know a little more about the set > up of your test (or you could create a JIRA and attach your test code > there if you like)... > > In particular, how big are the messages you are sending? Are they > transient or persistent (if the latter then which store are you using > - Derby or BDB or a JDBC store)? > Are you using transactions, if not which acknowledgement mode are you > using? > > The numbers you are seeing are certainly unreasonable (unless you're > using multi gigabyte messages :-) )... > > -- Rob > > On 5 May 2015 at 06:31, Sivananda Reddys Thummala Abbigari > <[email protected]> wrote: > > Hi, > > > > *I am trying to benchmark Qpid with the following use case*: > > # Default Qpid configs are used(ex: 2GB is the max memory set), broker > and > > client are on the same machine > > # I have 1 connection and 256 sessions per connection, each sessions > has a > > producer and consumer. So, there are 256 producers and 256 consumers > > # All the producers/consumers are created before they start > > producing/consuming messages. Each producer/consumer is a thread and they > > run parallely > > # Consumers start consuming(they wait with .receive()) > > # producers start producing messages, each producer produces only 1 > > message, so there are 256 messages produced in total > > # A fanout exchange is > used(topic.fanout=fanout://amq.fanout//fanOutTopic), > > and there are 256 consumers, each consumer receives 256 messages and so > > there are 256*256 messages received in total > > # *Following are the response times(RT's) for the messages*: > > > > - Response time is defined as the difference in the time when the > > message is sent to the broker and the time at which the message is > received > > at the client > > - min: 144.0 ms > > - max: 350454.0 ms > > - average: 151933.02 ms > > - stddev: 113347.89 ms > > - 95th percentile: 330559.0 ms > > > > Is there any thing that I am doing wrong fundamentally?. I am worried > about > > the avg response times of "*152 secs*". Is this expected from qpid?. I > see > > a pattern here, as the test is running the RT's are increasing linearly > > over time. > > > > Thank you, > > Siva. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
