2014-10-24 0:01 GMT+04:00 Mark Thomas <ma...@apache.org>: > On 17/10/2014 17:17, Konstantin Kolinko wrote: >> 2014-10-13 23:27 GMT+04:00 <ma...@apache.org>: >>> Author: markt >>> Date: Mon Oct 13 19:27:37 2014 >>> New Revision: 1631520 >>> >>> URL: http://svn.apache.org/r1631520 >>> Log: >>> Cache the Encoder instances used to convert Strings to byte arrays in the >>> Connectors (e.g. when writing HTTP headers) to improve throughput. >> >> In this implementation I think the cache only plays when the same >> MessageBytes instance is re-used in subsequent requests. > > Correct. This happens often enough (especially for the HTTP headers) > that there was a measurable performance improvement. That doesn't mean > that there isn't scope for further improvement. > >> I think an alternative implementation using a thread-local cache will >> allow to reuse encoders between different MessageByte instances in the >> same request and will require less memory. > > I don't like the idea of a ThreadLocal cache as it has the potential to > expose data from one request to another. In shared hosting that could be > problematic. > > A global cache of encoders (keyed on charset) that can be used by > MessageBytes (and potentially elsewhere) and then returned (i.e. all > internal code so we can be sure there is no leakage across requests) > might work.
An encoder is configured up to the task (with onMalformedInput() etc.). A generic cache is... I think I found it: java.nio.charset.Charset.encode(String) java.nio.charset.Charset.encode(CharBuffer) The latter method uses thread-local cache (in Java 7). Some feeling of deja-vu is because of discussion of decoders that we had 3 years ago. See code in ByteChunk.toStringInternal() as a result of that. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
