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. As an aside, I rarely see Tomcat deployed on machines with more than 8 cores. Most folks I see go for horizontal scaling. > Although with NIO the executor count can remain lower than on java.io, > many webapps will still need a significant amount of them, so in > practice it is simply not possible to have any syncing (for example, > there's one needed sync in the APR connector for adding sockets back to > the poller, and it hurts a lot - essentially, the connector works well > enough only with a "small" thread pool). I haven't see any change either way in my tests so far. I can certainly increase the concurrency of the test client but on my machine that is just going to put more threads into a wait state. I'll confirm that with the profiler. > 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. There will nearly always be a test scenario that can make one implementation look good and another look bad and there are always going to be trade-offs. As long as Tomcat doesn't perform badly in what might be considered normal/typical/valid/etc usage scenarios then I'm going to be happy. Mark > > Rémy > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
