Hi Joakim,
Thanks lot for your reply and explanations, it inspired me lot.
One thing still worry me, even if we can control the whole work chain
(client -> network -> server), may still need to be careful to change
header size, in Jetty there are some other "size limits" like bellow which
may also need to be changed accordingly.
config._headerCacheSize
config._outputBufferSize;
config._outputAggregationSize;
And some "size limits" seems does not support configuration (only can
change by code API), like in ConnectionFactory
int _inputbufferSize = 8192;
public HttpConnectionFactory()
{
this(new HttpConfiguration());
setInputBufferSize(16384);
}
It may not easy to tune these numbers even if know the business use cases,
I believe there will be lot of try-compare-try steps.
Not sure webtide or intalio have some best practices to benchmark and
regression these kind of modification, any suggestion is really appreciated.
For memory calculation in previous mail, here is what I got from Jetty doc:
*"The HttpConfiguration
<http://download.eclipse.org/jetty/stable-9/apidocs/org/eclipse/jetty/server/HttpConfiguration.html>
class holds the configuration for HTTPChannel
<http://download.eclipse.org/jetty/stable-9/apidocs/org/eclipse/jetty/server/HttpChannel.html>s,
which you can create 1:1 with each HTTP connection or 1:n on a multiplexed
SPDY connection. **Thus a HTTPConfiguration object is injected into both
the HTTP and SPDY connection factories. "*
The HttpConfiguration may only need one instance, and can be injected into
connection factories, which can be shared.
I am still wondering, what if 10k connection concurrently happened, for the
header content, one connection(map to channel) eventually will have its own
header copy, hence times with the connection count. But not sure my
understanding is right.
Jetty do have good memory footprint with data structure like Trie and
ByteBufferPool (both have various implementation like ArrayTrie, TreeTrie,
ArrayByteBufferPool, MapByteBufferPool), it may NOT exact multiply header
length with the connection count. Within one site, pages may have similar
headers which also can save some memory.
thanks
Huaping Gu
On Thu, Apr 30, 2015 at 7:04 PM, Joakim Erdfelt <[email protected]> wrote:
> The defaults of 8KB are based on experience with various browsers, http
> clients, (networking) hardware, proxies, etc ...
>
> While it is possible to increase those values, you run a high risk of
> suddenly experiencing failures in your various clients to reach Jetty, let
> alone Jetty being in a position to even process the request. The failures
> can occur on the server side load balancer, intermediate networking
> hardware, transparent proxies on network providers, client side proxies,
> faults in client libraries, differences in client libraries, mobile
> networking differences, etc...
>
> We generally only recommend increasing those values for environments where
> you control the entire chain (client -> network -> server) and can validate
> all pieces of the chain to ensure that it will work sanely.
>
> There is also a number of vulnerabilities present in large HTTP headers
> related to Hashmap collisions which allow an arbitrarily small number of
> users and clients to DDOS the CPU and memory of the machine with relatively
> few requests. This is another reason the 8KB maximum has settle into
> common use across the industry.
>
> As for memory calculations, there is no 1::1 relationship of memory use to
> connection count.
> The memory comes from preallocated BufferPools and are reused as-needed.
> It would be difficult to have all 10k connections each having a buffer of
> their own at the exact same time.
> As for a calculation or a rule of thumb on how your memory will behave,
> that's impossible to prescribe without knowing your application and client
> access behavior intimately first.
>
>
>
> --
> Joakim Erdfelt <[email protected]>
> webtide.com <http://www.webtide.com/> - intalio.com/jetty
> Expert advice, services and support from from the Jetty & CometD experts
> eclipse.org/jetty - cometd.org
>
> On Thu, Apr 30, 2015 at 5:38 PM, Huaping Gu <[email protected]> wrote:
>
>> Hi Jetty users,
>> Any one has best practice on Jetty HTP Header size limit setting?
>>
>> For Jetty, the header size can be configured in HttpConfiguration,
>> default like bellow (8k bytes):
>>
>>
>> private int _requestHeaderSize=8*1024;
>> private int _responseHeaderSize=8*1024;
>> For some reason, we need to increase the header size (it is arguable why
>> need such a big header? It is because of some special cookie). The concern
>> is header is attache to HTTPChannel which is 1:1 to connection or 1:n to
>> SPDY connection (from Jetty Doc). If we have 10k connections, every 8k
>> header size increase will introduce 80M memory usage (should more if
>> calculated with JVM data structure overhead). 80M seems not too big in
>> modern box. Are there anyone here ever did this kind of testing on Jetty,
>> or benchmark? What is the optimal header size and any concern factors we
>> need to take care? Throughput (traffic, volume), latency?
>> thanks
>> Huaping Gu
>>
>>
>>
>>
>> _______________________________________________
>> jetty-users mailing list
>> [email protected]
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>
>
>
> _______________________________________________
> jetty-users mailing list
> [email protected]
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
_______________________________________________
jetty-users mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
