On 24/10/2014 08:32, Mark Thomas wrote: > On 24/10/2014 00:40, Konstantin Kolinko wrote: >> 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... > > There was an unstated assumption that all the places using the cache > would be happy with the same Encoder configuration. > >> 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. > > I don't remember that discussion at all. > > I'll re-read that discussion, take a look at the implementation and see > what the performance impact of switching to that approach is.
I saw no measurable performance impact so I have applied this approach. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
