On 28 January 2016 15:35:35 GMT+00:00, Konstantin Kolinko <knst.koli...@gmail.com> wrote: >2016-01-28 17:53 GMT+03:00 Mark Thomas <ma...@apache.org>: >> On 28/01/2016 14:16, Konstantin Kolinko wrote: >>> 2016-01-28 17:04 GMT+03:00 <ma...@apache.org>: >>>> Author: markt >>>> Date: Thu Jan 28 14:04:00 2016 >>>> New Revision: 1727355 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=1727355&view=rev >>>> Log: >>>> Switch OutputBuffer to a local Map of C2BConvertors. Loading >testing with HTTP/2 and default Tomcat home page suggests an >improvement of a few percent in throughput. >>> >>> How much memory is wasted? >> >> I wouldn't call that memory 'wasted'. I'd call it 'used' to gain >> somewhere in the region of a 2% to 4% throughput increase. >> >>> Every connection (incl. keep-alive ones) will have its own map of >>> encoders? Encoders are not reused across different connections? >> >> Using the same load test as I used for the performance numbers, I see >a >> retained size of less than 1MB all of which is eligible for GC. There >> isn't much reuse in HTTP/2. >> >> If I switch to HTTP/1.1 and run the same test I end up with ~60 >> instances using ~16k. Scale that up to 2000 concurrent connections >and >> you get ~550k so I am not worried about memory use in this case. > >10000 -> 2,5 Mb. > >x up 100 different charsets available in JRE.
This is output, not input. >The cache has to be limited to some real value. I don't see the need for that on output. Even then 2.5MB of converters will be dwarfed by other usage. >E.g. 3, 4 (ISO-8859-1, UTF-8 + one-two else). > >With such low count it can be a list instead of a hashmap. (Though >maybe hashmap was improved in current java 8 and does not waste mush >memory in this case). Unnecessarily complex given the circumstances. >> I didn't measure the performance gain of this change for HTTP/1.1 but >> I'd expect there to be some benefit although not as much as HTTP/2 >> simply because HTTP/2 uses more concurrency for broadly the same >load. >> > >Where 2% - 4% comes from? There is a contention in SychronizedStack (a >class copied from Apache Commons Collections) ? Yes, it is the contention. This doesn't look like something copied from commons. It looks hand crafted although I haven't checked the history. > >(Same charset => same compartment in ConcurrentHashMap (bad as there >is no concurrently, but I think reading shall be fast there) => same >SychronizedStack instance (rather bad, as it has synchronized >methods)). > >Maybe use something else, like ConcurrentLinkedQueue ? Overkill. Mark > > >Best regards, >Konstantin Kolinko > >--------------------------------------------------------------------- >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
