Hi
we were recently hunting a bug in a plugin and played arround with VisualVM. This allows to look at the CPU consumption of different methods. The biggest CPU hog is org.xmlpull.mxp1.mxparser.fillBuf() which eats 15% of the CPU alone. Is this normal? Should XMLPULL be replaced by a more advanced implementation like Woodstox?
Walter
P.S… Kraken is the worst CPU offender…
I’d consider it a good sign that a good part of the CPU cycles are spend on XML serialization/deserialization. I’m a bit surprised by the method name (“fillBuffer” - I’d expected something like “processBytes”), but I’m not to worried about that. I’m not saying there is no room for improvement, but I’m quite happy to see the XML parsing being the most resource-intensive part of the server.
On top of serialization, Kraken performs a lot of protocol-to-protocol translation, as well as maintaining a lot of socket connections. The code base of Kraken could use a refactoring with concurrency/performance in mind (that wasn’t the primary goal of the current code base), but I’m not to surprised that it’s very CPU intensive (and will be, even after improving it).
As for Woodstox (or another replacement of the parser) - although I’m not unhappy with the pull parsing we do now, I believe the implementation is both outdated, and way to customized by us for it to be maintainable. I was already aiming at a replacement in the 4.x version of Openfire. For maintainability, I’d love to go with standard StAX - not sure which implementation, but I’m definitely not ruling out Woodstox.
Thanks for the input.
With respect to Kraken; i would comment that we are closing into get Spectrum.im to interact with Openfire via GoJara. There are ongoing changes in Spectrum.im to get this working and I am looking forward to present that in Q1/13.