[ejabberd] add_ and delete_rosteritem throughput

Steven Lehrburger lehrburger at gmail.com
Tue May 21 11:14:28 MSK 2013


David, thanks for your response! MUCs are certainly similar to what I've
described, and I did consider them, yet there are a handful of differences*
that led to my component-based approach. When I control the client software
then I might be able to re-purpose the MUC abstractions, but that's only a
long-term solution. Regardless, even if MUCs would work, then I would still
have the same problem I have now, since I'd need to add/delete those MUCs
from the rosters of many users at once.

So, the questions remain:

1) How can I might increase the overall ejabberdctl add/delete_rosteritem
XML RPC throughput?

2) If I can't increase throughput and need to implement a priority queue,
then how can I approximately predict how quickly ejabberd can handle
rosteritem changes?


Thanks again!

/~s


*If anyone is curious, the major issue with MUCs is that they don't behave
like normal roster items. I can add an MUC to a user's roster with
ejabberdctl add_rosteritem, but the MUC a) won't send presences and b)
can't receive private messages. It's important to the user experience that
active conversations appear automatically in the user's roster, and that
the user can join the MUC by simply sending a message to it. Bookmarking
the MUCs in the client, like you can do in Adium, doesn't work for me
either, since I need to dynamically manage the list of visible MUCs on the
server.




On Mon, May 20, 2013 at 9:33 AM, David Laban <alsuren at gmail.com> wrote:

> On Thursday 16 May 2013 17:50:15 Steven Lehrburger wrote:
> > Hi David, thanks for the algorithm/questions. Answers below!
> >
> > a.1) What are these roster pushes for?
> >
> > I'm working on a chat product that feels more like real-life group social
> > situations (office, conference, party, coffee shop, etc). Users can see
> the
> > conversations their friends are having, but not what they're saying
> unless
> > they join that conversation. I've built it on top of XMPP so that it
> works
> > with existing clients, and this GIF shows the basics of what I've built
> so
> > far: https://dashdash.com/static/img/screencast.gif.
> >
> > The roster displays for the user the active conversations that s/he can
> > see. I do a roster push when: a conversation starts, a conversation ends,
> > or the participants in a conversation change. That push needs to go to
> the
> > participants, as well as to each user who is a "friend" on the service of
> > any of the participants, so it's a potentially large number.
> >
> a.3) Why don't you just use MUCs for these conversations?
> ("join groupchat" ... prosody at conference.prosody.im
>                    or jdev at conference.jabber.org
>  in a competant IM client and you will see a workflow that looks very
> similar
>  to the one you describe)
>
> > b.1) How are they grouped?
> >
> > Each user has one roster group of contacts, and one roster group of
> > conversations. Contacts move from the former to the latter when a
> > conversation becomes active (via a roster push), and vice versa when the
> > conversation ends.
> >
> >   b.3) Would something like http://www.ejabberd.im/shared-roster-all ?)
> >
> > I've considered shared roster groups, but not recently. As I understand
> it,
> > I'd need a shared roster group for every edge in the social graph + every
> > active conversation, and that might not even work, since I need to set
> and
> > change contact nicknames whenever the conversation state changes.
> >
> b.3) Sounds suspiciciously like MUC room lists.
>
> > f.1) Do you have control of the client software?
> >
> > No - it works with Adium/Pidgin/etc. One day I'll write my own clients,
> but
> > not yet :)
>
> f.3) I assume that pidgin already supports MUCs
>
> > 3) Where Could we be?
> >
> > I could be modifying ejabberd itself instead of relying on a Python
> > component, but have only a superficial knowledge of Erlang.
> >
> Step 3) is the "let's list all of the possibilities" phase. Normally,
> answers
> to this question become obvious when you have gone over steps 1 and 2
> thoroughly.
>
> > 4) Where Should we be?
> >
> > I should probably write an XMPP server from scratch that has all of this
> > weird custom group logic built in, but I don't have enough users to
> justify
> > that amount of work yet.
> >
> One step at a time. Get yourself a nice big list of possibilities for step
> 3
> and then we'll go from there.
>
> David.
> _______________________________________________
> 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/20130521/860bcab0/attachment.html>


More information about the ejabberd mailing list