[ejabberd] How to handle more than 30000 mobile connections on one EC2 large instance ?

Sylvain Niles sylvain.niles at gmail.com
Wed Sep 29 02:45:13 MSD 2010


You may want to change some of the ejabberd  mnesia tables to RAM only if
you don't need the data to survive a reboot.
On Sep 28, 2010 3:36 PM, "Vincent Barat" <vbarat at ubikod.com> wrote:
> OK, I enabled thread poll and SMP (which was also disabled)...
> Actually, it makes a real difference for CPU usage (from 75% down to
> 4%). It helps, but it does not solve my issue: my 2 servers seem to
> be stuck at handling more or less 100 down/up per s which is not
> sufficient when you have 30000 mobile users.
>
> It seems that it is due to the poor I/O performance of EC2 instances...
>
> Le 28/09/10 19:30, Pablo Polvorin a écrit :
>> Hi Vincent,
>> why do you have kernel poll disabled?, it is some EC2 restriction?
>> it won't make a difference if you have few connections, but at> 10k
>> clients that
>> starts to count.
>>
>>
>>
>> On 28 September 2010 14:09, Vincent Barat<vbarat at ubikod.com> wrote:
>>> Hi everybody,
>>>
>>> We are running 2 eJbaberd 2.1.0 servers on one EC2, large instances (8
GB
>>> RAM). These 2 servers handle nearly 25000 XMPP connections from mobile
>>> devices.
>>>
>>> Because we handle mobile device connections, we face the following
issue:
>>> the servers open and close a LOT of connection each second (from 10 to
20)
>>> because connections are not stable. When we start to reach 20000
>>> simultaneously connected users, the time eJabberd take to open the
incoming
>>> C2S socket increase until 50s. (i.e. 50s to see this first
damned<stream>
>>> stanza !). Once the socket has been opened, the signin process itself is
>>> fast.
>>>
>>> What is interesting to note: the EC2 instance itself is not slow, and
>>> opening any other incoming socket (e.g. SSH) is FAST.
>>>
>>> So the question is: do you know how to improve the time needed by
eJabberd
>>> to ACCEPT an incoming connection ?
>>>
>>> My configuration:
>>>
>>> Mnesia (I don't think that using SQL would improve, since we don't have
any
>>> roster, but I need some advice here...
>>>
>>> All standard modules have been deactivated. Here is our typical .cfg
file:
>>> {modules,
>>> [
>>> {mod_adhoc, []},
>>> {mod_configure,[]},
>>> {mod_disco, []},
>>> {mod_version, []}
>>> ]}.
>>>
>>> We are using Erlang R13B04 (erts-5.7.5) [source] [64-bit] [smp:2:2]
[rq:2]
>>> [async-threads:0] [kernel-poll:false]
>>>
>>> Thanks for your help
>>>
>>>
>>> _______________________________________________
>>> ejabberd mailing list
>>> ejabberd at jabber.ru
>>> http://lists.jabber.ru/mailman/listinfo/ejabberd
>>>
>>
>>
> _______________________________________________
> ejabberd mailing list
> ejabberd at jabber.ru
> http://lists.jabber.ru/mailman/listinfo/ejabberd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jabber.ru/pipermail/ejabberd/attachments/20100928/8b17c83a/attachment-0001.html>


More information about the ejabberd mailing list