We have been able to mitigate the problem by modifying our server-side
code so that it batches up PubSub items publication and sends only a
few messages per second (with many published items in each message),
instead of publishing items as soon as they are available (with one
item per message).
So our gloox client doesn't have as many stanzas to parse as before
(even if the same amount of Item xml needs to be parsed), so the
StanzaExtensionFactory::addExtension() overhead is reduced.
As for ideas on how to make the StanzaExtensions more efficient, I
must admit that I haven't dug through the gloox code deep enough to
make informed and useful suggestions. It doesn't seem like a light and
easy refactoring though, as (almost) everything revolves around
StanzaExtensions...
One thing that comes to mind would be to profile and optimise the hell
out of the gloox XML parser, since most of gloox's work is done in the
parser (not just for StanzaExtensions).
Thanks,
Pascal
Le 2009-10-13 à 15:19, Jakob Schroeter a écrit :
Quoting Pascal Bourque <pascal@xxxxxxxxxxxxx>:
Hello,
We are buiding a system based on XMPP PubSub, and our client can
receive a lot of PubSub messages. In profiling the performance of
message reception and handling, we discovered that about half the
time spent in Parser::feed() is spent in
StanzaExtensionFactory::addExtensions(), which is spending most of
its time in Tag::findTagList().
It seems like the current StanzaExtension architecture requires
gloox to call findTagList() for each registered StanzaExtension, on
each received stanza. The PubSub Manager itself registers 3
StanzaExtensions...
Are there any plans to refactor this into something that would be
more efficient?
Well, there are now. :) Ideas welcome.
cheers,
Jakob
--
gloox-dev mailing list
to unsubscribe:
send a message with subject 'unsubscribe gloox-dev' to minimalist@xxxxxxxxxx