Pubsub performance.. again

Openfire Openfire Support
1

Hi All,

I posted a while back about pubsub performance http://community.igniterealtime.org/message/228731#228731

I wondered if anyone has looked at this in the meantime, or anyone might read this post that didn’t see that previous.

I’ve been carrying on with research… and due to an odd issue with disconnections at high message volume, experimented with ejabberd.

Using the exact same server, connection pub sub (using smack lib), all I do is start openfire, run the test, stop openfire, start ejabberd, run the test (and in the reverse order just to double check), I get:

Openfire:

Publish msgs 7000 per sec

1 subscriber, 250 per sec

(and a bigggg queue)

Ejabberd

Publish msg 5000 per sec

1 subscriber, around 2500 per sec

I can’t say I’ve done extensive tuning on either, simply as there doesn’t really seem to be much tuning guidelines. A recent java, the latest openfire version, decent -Xmx settings…

Just seems a huge difference between the two, wondered if anyone has seen anything similar?

2

what kind of client are you using to consume the subscribed messages at 250 per sec?.

3

Hi,

Not sure exactly what you mean… so I’ll just put down some info… client is java based, using the smack lib, implementation of the main Sensor.java we use is here http://code.google.com/p/bsf/source/browse/trunk/javaFramework/src/edu/bath/sens orframework/sensor/Sensor.java

Then for the test implementation, pretty much just a while loop that counts how many DataReadings are received each second.

With no code change to this component, running exactly the same built class retrieves 2500 from ejabberd, so I’m keen to find out if this is some config issue, or thats to be expected, or what others have achieved.

If it helps, the code is all available from that repository, a couple of ant build commands and you can reproduce the test - would just need to create a couple of user accounts in whatever openfire/ejabberd server you wanted to test against

Thanks!

4

Just making sure your client was not using an HTTP-BIND type connection.

Next thing I would check would be the cache settings and also confirming that your Openfire DB was not the bottleneck. If your published pubsub node is persistent, then the database hit could affect performance I think.

Openfire default cache settings are very safe and conservatory. There are a few postings some where here in igniterealtimeland about fine tunning Openfire for performance.

5

OK will try to track down some cache improvements. Regarding persistant node, the configuration code for new nodes used is:

leaf = mgr.createNode(nodeName);

ConfigureForm form = new ConfigureForm(FormType.submit);

form.setAccessModel(AccessModel.open);

form.setDeliverPayloads(true);

form.setNotifyRetract(false);

form.setPersistentItems(false);

form.setPublishModel(PublishModel.open);

leaf.sendConfigurationForm(form);

So, not persistant, and hopefully none of the other settings look bad.