Hi All,
I’m doing some research at Uni, and using openfire as part of the message middleware layer to exchange data on a pub-sub approach, with vehicles sending their position data via this layer, back to an AI component to control them.
I’ve noticed some odd behaviour, and first thought it might be messages being delivered out of order, but this looks OK (though I don’t know if this is guaranteed).
But, after running some tests last night, it looks like at about > 200 messages per second things start to struggle, and I get a backlog of messages starting to build up.
I wondered if anyone else has found any such limits? I’m connecting using smack if it makes any difference.
Thanks!
Obviously this will be very dependent on a few things, your hardware, IO speed and memory for example.
When I refactored pubsub for 3.8, I was able to publish 750 - 800K persistent events in 5 minutes (~2500 p/s), stored to a MySQL db. Of course there were no subscribers, so the situation was pretty much ideal for just publishing and storing, which is what I was trying to test. Unfortunately I don’t remember all the details of the testing, I think I only had a single publisher, but it may have been two.
The number of subscribers you have will have a signifcant impact on your throughput as well.
Thanks for the feedback!
Yeah I just upgraded the hardware significantly on the PC running openfire which I think helped the bottleneck a bit.
Thats very useful data to have… I hadn’t thought about the issue of number of subscribers affecting performance. I think I’ll have to add a few tests around that. And, I suspect, just develop some alert measure if messages are delayed rather than knowing 100% upfront where the limit will be.