[ejabberd] add_ and delete_rosteritem throughput

Steven Lehrburger lehrburger at gmail.com
Thu May 16 11:48:09 MSK 2013


To answer the last of my questions: I can just call
ejabberdctl's connected_users_info instead of user_sessions_info to
efficiently get the information I need to further-prioritize roster changes.

That said, I'm still curious about how I might increase the overall
add_rosteritem and delete_rosteritem throughput, and, if I can't increase
throughput, whether my priority queue workaround sounds reasonable, and, if
it is reasonable, how to figure out how many requests the queue readers can
make simultaneously.

Thanks!

/~s


On Wed, May 15, 2013 at 1:37 PM, Steven Lehrburger <lehrburger at gmail.com>wrote:

> Hi,
>
> I've been using ejabberd along with an XMPP component in an application
> that requires regular changes to user rosters.
>
> I often need to make as many as 150 of these changes at a time, and this
> number will increase as the service grows. I've been doing this from my
> component via XML-RPC, but get "[Errno 104] Connection reset by peer" on
> some requests, while others take 20 seconds or more to return, even though
> the timeout is set to 5 seconds and maxsessions is set to infinity.
>
> I've just been retrying the requests that fail, but the slow requests
> cause user experience problems. Furthermore, some of the requests are more
> urgent than others, and if ejabberd is still busy churning through one
> batch of 150 when a second comes in, then things get really clogged up. I'm
> running ejabberd on an m1.small Amazon EC2 instance.
>
> Does anyone have any suggestions on how I might increase throughput?
>
> A few other thoughts/ideas/questions:
>
>
> 1) I considered switching from Mnesia to MySQL so that I could modify the
> rosters directly, and to generally simplify my application by using only
> one datastore. It doesn't sound like this will work for me, however, based
> on various forum posts and a conversation with Badlop last week:
> http://chatlogs.jabber.ru/ejabberd@conference.jabber.ru/2013/05/08.html.
>
> 2) The best workaround I've been able to come up with is to buffer the
> XML-RPC requests in a priority queue (or, if I use Amazon SQS, in separate
> low- and high-priority queues). The queue readers could make sure they
> performed the high-priority requests first, but it would still be
> preferable to somehow increase overall throughput. Also, how should I
> select a number of queue readers/concurrent requests so as to saturate, but
> not overwhelm,ejabberd?
>
> (I had hoped by putting the queue readers on the same machine as ejabberd I
> could further improve performance by using ejabberctl, but
> http://lists.jabber.ru/pipermail/ejabberd/2012-August/007674.html says
> that XML-RPC is faster, and I confirmed this with my own tests.)
>
> 3) At any given time most of the users who require roster changes are not
> logged in. I could further prioritize my XML-RPC requests by first calling
> user_sessions_info, but I doubt that would be an overall performance gain.
> Is there a way for my component to directly readejabberd's "Last Activity"
> information for a user? If this is stored in Mnesia, is there a Python
> library I could use to query this information from my component?
>
> Thanks!
>
> Best,
> Steven Lehrburger
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jabber.ru/pipermail/ejabberd/attachments/20130516/2534a832/attachment.html>


More information about the ejabberd mailing list