jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tanakiat Srisaranayakul <>
Subject Re: Testing CometD server using jmeter
Date Tue, 06 Dec 2011 14:41:44 GMT
Please see my answer inline.

Appreciated your help :)

On Tuesday, December 6, 2011, Felix Frank <> wrote:
> Hi,
> On 12/06/2011 03:23 AM, Tanakiat Srisaranayakul wrote:
>> The script looks like this.
>> 1st thread group: Referred as main group
>> 2nd thread grounp: Referred as polling group
>> polling group will check whether there is a authen cookie passed via
>> property, authen_token_${__threadNum} , from main thread or not.
>> Let's say 1st thread of polling group found authen cookie,authen_token_1,
>> it will do whatever specified inside the while loop.
> this sounds complicated. How did you come up with it?
> Couldn't you simplify your Test Plan by doing everything in the main

The script simulates the real IM web based user so that's why it's so
The main thread is to send the authentication request, post message request
or create conversation request, etc.  which is a synchronous call.
On the other hand, the long polling thread is to simulate the persistent
connection to get update in real time fashion as much as possible.

Therefore, for this web app 1 user will have 2 connections which 1 of them
is left opened all the time to simulate the persistent connection.
Moreover, there will be 2 shared properties per user which frequently be
written by main thread and read by polling thread.
The written rate would be 40 time/hour/user and the read rate is higher.

> As for your CPU usage, are you sure that the value passing is to blame?
I'm not quite sure the value passing is the cause but I cannot come up with
other points. Do you have any other suspects?
I have investigated the following suspects and believed that it's not
- GC : visual vm shows no sign of this issue.
- Heap: visual vm shows no sign of this issue.
- %Disk Time : It's just 5% with 10% at max so I believe it's not the cause.
- number of elements : I believe that number of elements affects more in
term of memory than CPU but if my belief was wrong please correct me.
- Concurrent thread : 2000 concurrent threads can be run on this machine
with 25 elements, 1 instance of jmeter and 60 %CPU time so I assume that it
should be at least 1000 concurrent threads with 35 elements.
- Jmeter properties: As I stated earlier, it is written and read frequently.

> How many and what kinds of Listeners are you using?
1 simple writer to write error only in csv format.

> What OS is this, how much heap space does Java use and how many elements
> comprise your Test Plan in total?
- Windows Server 2003 32bit EE with 1x2.1 GHz CPU which contains 4 logical
core inside and 4 GB of RAM.
- Heap space is set as followings;
Min = 1GB
Max = 2GB
It was observed using visual vm that the heap size is steady at 1.25GB and
hasn't reached 2GB as well as the gc activity is quite low so we suspect
that it's neither heap issue nor GC issue.
- 35 elements in total including 29 elements in main thread group and 6
elements in polling thread group.

> How many concurrent threads are you running?
It can increase up to 300 users, 600 concurrent threads, per instance with
4x% CPU usage.
The ramp up rate is around 2 threads, 1 from main TG and 1 from polling TG,
per second.

> Cheers,
> Felix
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message