[ejabberd] postgres + testing

Mickael Remond mickael.remond at erlang-fr.org
Wed Feb 23 01:30:33 MSK 2005


Matthew Nourse wrote:
> The most users I could connect at one time was about 3500, with these 
> settings:
> 
> export ERL_OPTIONS="-heart +P 268435455 +K true"
> export ERL_MAX_PORTS=65000
> 
> Ejabberd would refuse to accept new connections after about 3500 users 
> were connected.  I couldn't even open a socket to it by telnet'ing to 5222.
> 
> Before I set the +P option, I could log in about 500 users.  When I set 
> it to 250,000 I could log in about 1800 users.
> 
> The "users" were logging in at a rate of about 1 or 2 per second.
> 
> I'm using mnesia for the roster but will soon switch to LDAP or 
> (ideally) postgres.
> 
> I'm running Debian Sarge with a 2.6 kernel on a 3 Ghz P4 with 1 gig of 
> RAM.  I wasn't running out of memory...with 3500 connected users, 
> ejabberd was using about 50 meg and total memory usage was about 500 meg.
> 
> If you'd like me to re-run my tests and/or modify the tests in some way, 
> please let me know.

Your behaviour is very strange. What is your erlang/otp version ? What 
is your OS ? I suppose it is freeBSD as your are using the +K flag.

By default the number of process is 32768 and your are not likely to 
reach it with the number of connected users your are using.
We did some benchmarking with Jonathan Bresler with Tsunami. We did not 
change the default number of process. We only increased the number of 
port to 32000 as this is a ressource you can exaust quickly during a 
benchmark.
We manage to reach 7000 simultaneous users exchanging messages without 
any problem.
We did not push the test any further because we run out of time and I 
had to present the result during my talk at the Erlang User Conference.

So your problem is strange. Did you had the same behaviour without the 
+K parameter (We did not use it) ?

You will find some information on our benchmark in the following document:
http://www.erlang.se/euc/04/jabber.pdf

It contains data regarding the machine and some graph on the server 
behaviour.

As a side note, regarding your benchmark tool: Are you sure you can 
simulate this number of simultaneous connections with smack ? I have 
previous experience with Java benchmark HTTP tool and threading 
limitation make it almost unless as long as we were reaching 200 
simultaneous connections. With Java-based injection tool our problem 
obviously came from the injection tool.

Your problem is different as the behaviour you describe is different 
with the same injection tool however.

Thank you for your feedback !

-- 
Mickaël Rémond
  http://www.erlang-projects.org/


More information about the ejabberd mailing list