| Date | Commit message (Collapse) |
|---|
|
In my testing, only dropped clients over Unix domain sockets or
loopback TCP were detected with this option. Since many
nginx+unicorn combinations run on the same host, this is not a
problem.
Furthermore, tcp_nodelay:true appears to work over loopback,
so remove the requirement for tcp_nodelay:false.
|
|
This patch checks incoming connections and avoids calling the application
if the connection has been closed.
It works by sending the beginning of the HTTP response before calling
the application to see if the socket can successfully be written to.
By enabling this feature users can avoid wasting application rendering
time only to find the connection is closed when attempting to write, and
throwing out the result.
When a client disconnects while being queued or processed, Nginx will log
HTTP response 499 but the application will log a 200.
Enabling this feature will minimize the time window during which the problem
can arise.
The feature is disabled by default and can be enabled by adding
'check_client_connection true' to the unicorn config.
[ew: After testing this change, Tom Burns wrote:
So we just finished the US Black Friday / Cyber Monday weekend running
unicorn forked with the last version of the patch I had sent you. It
worked splendidly and helped us handle huge flash sales without
increased response time over the weekend.
Whereas in previous flash traffic scenarios we would see the number of
HTTP 499 responses grow past the number of real HTTP 200 responses,
over the weekend we saw no growth in 499s during flash sales.
Unexpectedly the patch also helped us ward off a DoS attack where the
attackers were disconnecting immediately after making a request.
ref: <CAK4qKG3rkfVYLyeqEqQyuNEh_nZ8yw0X_cwTxJfJ+TOU+y8F+w@mail.gmail.com>
]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
|
|
Ruby 2.0.0dev is the future and includes a CoW-friendly GC,
so we shall encourage folks to give Ruby 2.0.0dev a spin.
|
|
|
|
Sending the same signal faster than the receiver can process
means signals can get lost.
|
|
While second nature to myself, stderr_path may be an
overlooked configuration parameter for some users. Also,
add a minimal sample configuration file that is shorter
and hopefully less intimidating to new users.
|
|
These should help make things easier for folks unfamiliar
with nginx setups.
|