No this does not work. If I specify tcpNoDelay option -- I can not connect to the broker. Anyway, I doubt that it can make such a big difference. There is something else that blocks transactions. Note, if I turn transactions off -- everything works fast on Linux as well.
I have tried different Linux installation (even different distribution) -- same thing. James.Strachan wrote: > > The only thing I can think of is you're hitting the Nagler part of TCP > - the TCP_NODELAY setting. > > I've just patched SVN HEAD to allow you to explicitly set/unset the > Socket.setTcpNoDelay() option. If you grab the latest source code > http://incubator.apache.org/activemq/source.html > > then building it > http://incubator.apache.org/activemq/building.html > > you should be able to try linux with these 2 URLs to see if it makes a > difference... > > tcp://localhost:61616?tcpNoDelay=true > tcp://localhost:61616?tcpNoDelay=false > > Let us know if thats it. > > > On 8/25/06, kaipa <[EMAIL PROTECTED]> wrote: >> >> Hi James, >> >> Thank you for reply. I still can not get it solved. >> >> 1. Yes, I send a number of messages to the queue first and then start to >> receive >> 2. If I disable persistence Linux is still that bad. >> 3. However, if I disable transactions -- everything works fine and fast >> both >> with/without persistence. So the problem is in how transactions are >> handled, >> I believe. >> 4. Broker is running on local file system. >> >> I have tried simpler test scenario: send-commit-receive-commit. On the >> same >> connection and session. >> >> Windows: >> Testing QService.sendMessage() followed by QService.receiveMessage() >> 1000 ops 1578ms >> Average speed: 633 ops/s >> >> Linux: >> Testing QService.sendMessage() followed by QService.receiveMessage() >> 1000 ops 202094ms >> Average speed: 4 ops/s >> >> I am absolutely lost! >> >> I have also tried to split message consumption into several threads and >> sessions -- that improves message consumption proportionally but this is >> not >> the root cause. >> >> >> >> >> James.Strachan wrote: >> > >> > BTW for the consumer tests, are there pleny of messages on the queue >> > before you start trying to consume? How does the performance differ >> > between linux and windows if you disable persistence? >> > >> > The only real difference between the two - assuming things are not >> > CPU, network or IO bound is the performance of the disk writes. >> > Persistent sending/consuming of messages by default requires blocking >> > the client until the broker does a sync-to-disk of the journal. >> > >> > Is the broker running on a local file system or a shared network drive? >> > >> > On 8/24/06, kaipa <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> >> >> I've read through archives and found that some people experience the >> same >> >> problem but there were no solution. Tests work great fast on Windows >> >> Laptop >> >> but unbarely slow on Linux server. >> >> >> >> - I have the standard configuration from Latest AMQ release (4.*). The >> >> only >> >> difference that I have tried Kaha persistence that works much faster >> than >> >> JDBCJournal. I tried JDBCJournal as well -- perfomance difference is >> the >> >> same. >> >> - I use tcp transport >> >> - Queue is persistent >> >> - Session is transactional >> >> >> >> First pair of tests commit session after every message. Second pair >> >> commit >> >> after all messages are sent or received. I am especially concerned >> about >> >> first pair that is too slow. >> >> >> >> Windows: >> >> >> >> Testing QService.sendMessage() >> >> 500 ops 453ms >> >> Average speed: 1103 ops/s >> >> >> >> Testing QService.consumeMessage() >> >> 500 ops 484ms >> >> Average speed: 1033 ops/s >> >> >> >> Testing QService.sendMessageNoCommit() >> >> 500 ops 188ms >> >> Average speed: 2659 ops/s >> >> >> >> Testing QService.consumeMessageNoCommit() >> >> 500 ops 125ms >> >> Average speed: 4000 ops/s >> >> >> >> Linux: >> >> >> >> [java] Testing QService.sendMessage() >> >> [java] 500 ops 22290ms >> >> [java] Average speed: 22 ops/s >> >> >> >> [java] Testing QService.consumeMessage() >> >> [java] 500 ops 40366ms >> >> [java] Average speed: 12 ops/s >> >> >> >> [java] Testing QService.sendMessageNoCommit() >> >> [java] 500 ops 926ms >> >> [java] Average speed: 539 ops/s >> >> >> >> [java] Testing QService.consumeMessageNoCommit() >> >> [java] 500 ops 1017ms >> >> [java] Average speed: 491 ops/s >> >> >> >> I suspect it is something with activemq io libraries. Java web >> services >> >> work >> >> fine on the same server, the problem is only with activemq. >> >> >> >> Please, advise where I can look into >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/Bad-AMQ-Linux-performance-tf2159490.html#a5966799 >> >> Sent from the ActiveMQ - User forum at Nabble.com. >> >> >> >> >> > >> > >> > -- >> > >> > James >> > ------- >> > http://radio.weblogs.com/0112098/ >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Bad-AMQ-Linux-performance-tf2159490.html#a5980491 >> Sent from the ActiveMQ - User forum at Nabble.com. >> >> > > > -- > > James > ------- > http://radio.weblogs.com/0112098/ > > -- View this message in context: http://www.nabble.com/Bad-AMQ-Linux-performance-tf2159490.html#a5983897 Sent from the ActiveMQ - User forum at Nabble.com.
