On 11 May 2013, at 20:26, Reindl Harald <[email protected]> wrote:
> after the connection is established and in case of connect
> you have already passed the TCP transmissions and kernel
> settings like
>
> net.ipv4.tcp_fin_timeout = 5
> net.ipv4.tcp_retries1 = 5
> net.ipv4.tcp_syn_retries = 5
> net.ipv4.tcp_synack_retries = 5
The way I usually deal with this is three fold - and I think that it a) behoves
apache/traffic servr to allow admins to configure this in widely varying ways
while b) have somewhat sane middle of the road settings.
- Use *bsd/linux accept filters or similar just in front to
not kick off too much of the http stack without having the
client invest in sending a few decent bytes and a bit of
TCP stack state.
In practice, with mobile clients, I've found it hard to
be too strict. Many seconds may pass before a long haul
connection has its 'GET' sent.
Above tcp settings are appropriate for certain modern
internet sites in modernly wired countries - but would
not see them as universally good.
So not much we should do I guess - beyond a couple
of best practice hints covering 2 or 3 widely
different scenario's.
- Try to avoid too much code waking up to deal with the
GET, and subsequently, too much code from lingering
around after the entire reply is generated just to
'sent out' this reply byte by byte. Which often is as
simple as a small proxy in front.
Likewise - this is not universally good - as there are
plenty of situations where local skill & incident response
patterns would cause such an approach to make things
less (instead of more) reliable.
So again - we can just suggest some best pratice.
- Hand off (or kill) seriously lengthy things to a special
polling/async (i.e. single thread/process 'ab' select/poll
style with linked lists buffer/pointers) process. E.g.
using things like inter process file descriptor passing
or some N-Path thing at TCP level.
Which is again - just one of the many ways to approach
things. And again - lots of variants possible.
So am doubtful if this sort of knowledge should be part of the default.
Think that those settings should be fairly conservative - designed to work in a
wide range of settings.
Even if that means you can hog resources remotely with relative ease - as it is
hard to
know ahead of time if this is a enterprise-server sending large java generated
blobs to people on a local LAN or a small server doing short ajax-y replies to
mobile clients with 10's of seconds idleness in lots of parallel connections.
Just my 2 pence.
:-)
-- Dw.
smime.p7s
Description: S/MIME cryptographic signature
