On 24/09/2012 16:04, Mark Thomas wrote: > On 24/09/2012 13:19, Remy Maucherat wrote: >> On Sun, 2012-09-23 at 12:35 +0100, Mark Thomas wrote: >>> ab -c 4 -k -n 1000000 http://localhost:8080/test-1k.txt >> >> The concurrency of the test is very low, there will be only 4 threads >> used with that test, which means decent sync performance. > > Once you increase the number of threads beyond the number of cores in > the machine you aren't going to see much different as most of the > threads will be waiting rather than doing any real work. > > I have been testing on an 8 core machine and SyncronizedStack is > consistently faster than ConcurrentLinkedQueue for any number of threads > from 1 to 40. > > As I mentioned yesterday, I want to do some testing on a machine with > more cores. I have a much better connection to people.a.o (with 48 > cores) today so I plan to do some more testing with people. I'll report > back when I have some results.
And the results are in [1]. Short version : SynchronizedStack wins by a mile. The test case [2] was a Java 6, standalone version of the test case currently in trunk. As the number of threads increase, the differential between the two increases. There is also a marked difference in CPU usage. For SynchronizedStack with 64 threads CPU usage (measured with top) was around 7%. For ConcurrentLinkedQueue it was around 99%. The differential in performance seems to level off at SynchronizedStack being 10x faster than ConcurrentLinkedQueue for this particular use case. >> So adding caches like this is likely not a good idea. > > The evidence so far says the opposite. I'm happy to keep looking for > more evidence. Given the above and the way that the stack is used (the time in the sync block represents a very small percentage of the overall request processing time) I think the likelihood of getting anywhere near 64 concurrent threads is very low even with several thousand concurrent requests. Even if the concurrency does get this high, I am now confident that SynchronizedStack will perform better. In the absence of a test case that demonstrates that - for the way it is used - SynchronizedStack is slower than ConcurrentLinkedQueue then I intend to keep the recent changes. I would add that ConcurrentLinkedQueue has a lot of functionality we don't need in this particular case. The performance gain is simply from implementing a focused class that does one thing very well. It is by no means a replacement for ConcurrentLinkedQueue. Mark [1] http://people.apache.org/~markt/random/SynchronizedStack.java [2] http://people.apache.org/~markt/random/SynchronizedStack-results.txt --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
