[Tsung] Suggested method of testing a Jabber Servers max user connects

Taylor Laramie taylor.laramie at globalrelay.net
Wed Feb 6 09:46:40 CET 2008


Wow that made a big difference now that I'm not DDoS'ng the server 
during the bench run. However I have noticed that while the total 
attempted connections don't exceed the restriction, they aren't reaching 
the mark either. For example I've set the limits to 2000 users but total 
user connections only reach 1829. When I inspects the logs and compile 
the report, I don't see any connection errors.

Pablo Polvorin wrote:
> Hello,
> 
> You are running out of available users id.
> The option "global_number" is for global request
> acknowledgement, its main use is for waiting for all
> users to connect before sending messages.(6.1)
> 
> But you arrival rate at 0.05 is creating more clients
> than available ids for those users ("userid_max").
> You could try to fix this by limiting the number of
> users to 9000, using the "maxnumber" attribute when
> defining the load, something like this:
>  <users maxnumber="9000" interarrival="0.05" >
> unit="second">
> 
> Hope this help,
> pablo.
> 
> 
> --- Taylor Laramie <taylor.laramie at globalrelay.net>
> escribió:
> 
>> Wow! Just to preface, thanks for the responses :)
>>
>>> Hello,
>>>
>>> What is the error message ?
>>>
>>>
>>> --
>>> Nicolas
>> This is the error message I'm seeing in
>> tsung_controller:
>> ** {badarg,[{erlang,list_to_binary,
>>                      [["<iq id='",
>>                        "248376",
>>                        "' type='get' >",
>>                        "<query xmlns='jabber:iq:",
>>                        "auth",
>>                        "'>",
>>                        "<username>",
>>                       
>>
> [106,98,95,98,101,110,99,104|{error,no_free_userid}],
>>                       
>> "</username></query></iq>"]]},
>>              {ts_jabber_common,auth_get,3},
>>              {ts_client,handle_next_request,2},
>>              {gen_fsm,handle_msg,7},
>>              {proc_lib,init_p,5}]}
>>
>> One thing I did notice from tailing the logs in
>> ejabberd was that even 
>> when the max number number of connections I thought
>> I had specified in 
>> the tsung.xml had been reached, it still attempts to
>> connect.
>>
>> <-- snip of top of tsung.xml -->
>>    <clients>
>>      <client host="localhost"
>> use_controller_vm="true" 
>> maxusers='25000'></client>
>>    </clients>
>>
>>   <servers>
>>    <server host="10.20.7.12" port="5223"
>> type="ssl"></server>
>>   </servers>
>>
>>    <load>
>>     <arrivalphase phase="1" duration="20"
>> unit="minute">
>>      <users interarrival="0.05"
>> unit="second"></users>
>>     </arrivalphase>
>>    </load>
>>
>>   <options>
>>    <option type="ts_jabber" name="global_number"
>> value="9000"></option>
>>    <option type="ts_jabber" name="userid_max"
>> value="9000"></option>
>>    <option type="ts_jabber" name="domain"
>> value="globalrelay.net"></option>
>>    <option type="ts_jabber" name="username"
>> value="jb_bench"></option>
>>    <option type="ts_jabber" name="passwd"
>> value="test"></option>
>>   </options>
>>
>>    <sessions>
>>     <session probability="100" name="jabber-example"
>> type="ts_jabber">
>>
>> </-- snip-->
>>
>> In the above the intention is to try and connect
>> 9000 users @ 20ps.
>>
>>> Did you use ssl support included in tsung or do
>> you change something to
>>> get tls ?
>>>
>>> How many machines are you using for injection ? a
>> single ?
>>
>> Just the included SSL support. Unfortionately I only
>> have a single 
>> machine to use for my testing purposes though the
>> load on the system 
>> itself is quite low.
>>
>>> Not sure which Erlang your using, but if it is one
>> of the single-threaded
>>> versions, then you have to be really careful to
>> watch your CPU utilization
>>> on the Tsung controller. Even on a multi-cpu box,
>> the single-threaded erlang
>>> will only use 1 CPU or core for the controller,
>> and once that controller
>>> process maxes out that CPU, you're done. Doesn't
>> matter how many Tsung
>>> client processes your are using to spread the
>> load, the controller process
>>> will be a bottleneck in that situation. I've
>> gotten around this problem in
>>> the past by simultaneously running multiple Tsung
>> instances (with separate
>>> sets of users for each controller instance).
>>>
>>> SMP erlang should help solve that controller
>> bottleneck problem, but I
>>> haven't don't have too much first-hand experience
>> with that yet.
>>
>> I'm using R11B-5 built against OpenSSL 0.9.8g with
>> the current flags for 
>> erl in the Tsung script:
>> ERL_OPTS=" -smp +K true +A 1 ERL_MAX_ETS_TABLES
>> 40000 +P 100000 "
>> Also ERL_MAX_PORTS is set to 50000. Load on the
>> tsung system is really 
>> quite low as is the memory usage (I haven't
>> installed snmpd though to 
>> track the  min/max so I can't confirm right now).
>> I also reset the ephemeral from what they were
>> defaulted to (32768 
>> 61000) to a higher value though I didn't see any
>> sign of port exhaustion.
>> Lastly :) ulimit for nofile has been set to 65535.
>>
>> -- 
>> Taylor Laramie
>> Systems Administrator
>> _______________________________________________
>> Tsung-users mailing list
>> Tsung-users at lists.process-one.net
>>
> https://lists.process-one.net/mailman/listinfo/tsung-users
> 
> 
> 
>       Tarjeta de crédito Yahoo! de Banco Supervielle.
> Solicitá tu nueva Tarjeta de crédito. De tu PC directo a tu casa. www.tuprimeratarjeta.com.ar 
> 

-- 
Taylor Laramie
Systems Administrator

Global Relay Communications Inc.
T: 866.484.6630 (toll free)
F: 604.608.2941
www.globalrelay.com
Over Eight Years of Email Archiving & Compliance Excellence

Important - Confidential Information & Disclaimer.   All email sent to 
or from this address will be retained by Global Relay’s email archiving 
system. This message is intended only for the use of the individual or 
entity to which it is addressed, and may contain information that is 
privileged, confidential, and exempt from disclosure under applicable 
law. Any other distribution, copying, or disclosure is strictly 
prohibited. If you have received this message in error, please notify us 
immediately and delete the message without copying or forwarding it to 
anyone. Global Relay will not be liable for any compliance and technical 
information or guidance provided herein.  The information contained in 
this communication is not intended to be a legal opinion and should not 
be relied upon as legal advice. It is important to seek independent 
legal and/or compliance advice for all inquiries regarding compliance, 
legal or regulatory obligations in connection with Global Relay’s Services.


More information about the Tsung-users mailing list