Brock, I've been digging into this, and was able to replicate your problem with a concurrency cap at 5 transactions. It appears it is the Grizzly server running REST that imposes this limit by not expanding its thread pool the way it's supposed to. Increasing the initial number of threads (default is 5) leads to a proportional increase in the peak number of concurrent transactions reported. If I bring the minimum number of threads up to 128, I get 128 concurrent transactions too, so the culprit definitely is the web tier.
By hammering the server really hard I can get grizzly to bring 13 threads online, still far from the several hundred that is the default maximum. I don't know yet why the thread pool does not grow as expected, I'm not very familiar with grizzly, but I've posted a message to the grizzly mailing list to see if anyone there has any input. /Jacob On Mon, Aug 9, 2010 at 11:03 AM, Anders Nawroth <and...@neotechnology.com>wrote: > Hi! > > > We were able to increase the heap size by removing the > > wrapper.java.initmemory and wrapper.java.maxmemory settings from > > wrapper.conf and instead used this: > > The Java Service Wrapper version used has a known bug not allowing more > than four digits in the maxmemory setting. Thanks for reporting the issue! > > /anders > > > > > wrapper.java.additional.1=-d64 > > > > wrapper.java.additional.2=-server > > > > wrapper.java.additional.3=-Dcom.sun.management.jmxremote > > > > wrapper.java.additional.4=-Xmx16144m > > > > wrapper.java.additional.5=-Xms16144m > > > > > > > > The rest server still seems to be capping itself at 5 concurrent > > transactions though despite the larger heap. When hit with the full load > of > > the client servers we observed that the both the > > PeakNumberOfConcurrentTransactions and NumberOfOpenTransactions > attributes > > in the Transactions section of JMX remain exactly at 5. Under lesser > load, > > the client servers rarely time out and the NumberOfOpenTransactions > hovers > > between 0 and 2. > > > > > > > > Is there a way to explicitly increase the maximum number of concurrent > > transactions? > > > > > > > > As a side note, we initially explored the heap size after reading this: > > “Having a larger heap space will mean that Neo4j can handle larger > > transactions and more concurrent transactions” on the Neo4j wiki ( > > http://wiki.neo4j.org/content/Configuration_Settings) > > > > > > > > Thanks, > > > > Brock > > _______________________________________________ > > Neo4j mailing list > > User@lists.neo4j.org > > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > -- Jacob Hansson Phone: +46 (0) 763503395 Twitter: @jakewins _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
