I'm currently testing hornet with the STOMP acceptor and PHP using the STOMP PHP extension. The connection works fine however the performance has been really bad.
2.1.1 resulted in 187 seconds to insert 50,000 items.
2.1.2 was slightly worse averaging 191 seconds to insert 50,000 items.
I was reusing the same connection, only calling $stomp->send() to insert new data.
Here is my acceptor xml block:
<acceptor name="stomp-acceptor"> <factory-class>org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory</factory-class> <param key="protocol" value="stomp"/> <param key="host" value="grv-cache09"/> <param key="port" value="61613"/> </acceptor>
Halfway through the cpu measured at 102% with only this client performing operations on it. QuadCore, 16 Gig production box.
Is this the expected performance for the STOMP Protocol or are there other server or client options I can tune?
I also tested it from Python on the same network configuration in production and it was even higher than the php client avg'ing at 248 seconds to insert 50,000 items.
I'm using the barebones default server config for hornet, the only thing I changed is adding a new queue to the jms queues xml file and in the configuration file I changed all references to localhost to my actual server host along with adding the acceptor above. Everything else is default hornet 2.1.2 out of the box.
The python test code is here:
I was using the stompy library client.
Let me know if theres anything else. I'm looking for a general, "no it shouldn't be that slow our benchmarks showed good performance" or "yes it's know stomp is 10 fold slower than direct JMS connections"
Jeff is best to comment since he wrote the STOMP implementation.
IIRC STOMP is not well optimised compared to core protocol.
However you could try different clients to see if the problem is with the client or server, also compare it to a test program that uses the core protocol and see if there is much difference.
When you say "187 seconds to insert 50000 items" I assume you are sending persistent messages and you have the server setup to sync on each message received, and disc write cache is disabled on your disk? (See user manual)
50000/187 = 267 syncs per second.
That's actually a very good sync rate. Not many disks can go faster than that. Looks like you've hit your hardware limit. This would be the same whether it's HornetQ, Orackle, MySQL or any other application using your disk.
Not sure what you were expecting really...
BTW this has been discussed on several other threads before.
Jimmy Beagle wrote:
profiling shows that it's spending the majority of CPU time on
Stomp frames being text-based are significantely slower to decode that HornetQ binary messages.
We have not optimized Stomp decoding yet and it is likely there are low-hanging performance fruits that could improve the performance.
I'd be interested to get your profiling data to see where we could improve the decoding.
I will try that today and report back, however could you please answer why when I set durable to false and send non-persistent msgs that disk sync comes into play?
I'm asking a basic question... how can I improve inserts per second for a particular queue using stomp?
Based on my jira configurations I posted, do I have the config files set up correctly? Even if JMS proves to be the same speed with blockondurable set to false I still have the underlying question of how to get better insert performance with stomp. 260 MSGS per second cannot be the top end for writing to memory.