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.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to