[ejabberd] add_ and delete_rosteritem throughput

Kirk Bateman kirk.bateman at gmail.com
Tue May 21 12:38:05 MSK 2013


We had a similar issue with muc and clients with early BuddyCloud setups.

You aren't getting muc presence because the client won't automatically
enter the muc rooms even if they are in the roster.

What you could do though is using hooks on the server, detect the online
presence for the user and automatically send a presence to the muc from a
component thus making the user actually enter the muc on login. You just
need a list of muc rooms to send presence to.

Cheers

Kirk Bateman
On 21 May 2013 08:15, "Steven Lehrburger" <lehrburger at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/be7c92f0/attachment.html>


More information about the ejabberd mailing list