On 18/11/2010 12:45, Remy Maucherat wrote: > On Wed, 2010-11-17 at 18:06 +0000, ma...@apache.org wrote: >> Author: markt >> Date: Wed Nov 17 18:06:20 2010 >> New Revision: 1036150 >> >> URL: http://svn.apache.org/viewvc?rev=1036150&view=rev >> Log: >> Add recent performance improvements to changelog > > Ok. > > So we have two queues that can essentially grow up to the thread count, > right ?.
Correct. In the highly unlikely event that every single thread in the container was trying to create a session at the same time and every thread was at the point where it needed a MessageDigest (or every thread needed a Random or an InputStream). The chances of that happening are practically non-existent. And even if it did, it isn't a big deal. > You have chosen to not use thread locals though (they would > most likely perform better, at the cost of more memory). I rejected thread locals because they are harder to clean up and could lead to memory leaks. The queues will be handled by GC. > Any testing ? What do you think the benchmark class is for? The new implementation performs significantly better than the old one to the point where the time spent in session creation is in the noise. Could the performance of the session manager be improved? Almost certainly. Do I think that the most performance benefit will be obtained by optimising the session manager (rather than some other part of the processing chain)? No. > Another question: is it safe on all platforms to concurrently read > uramdom from a single process ? I suppose it is probably safe, but do we > know for sure ? I'll follow-up on Jean-Frederic's post on that. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
