Post mortem of a failed HackerNews launch

Re:Post mortem of a failed HackerNews launch by jacquesm on Thursday November 29, 2012 @11:42AM (#4848615)

Don't bother reducing keepalive, just disable it altogether. Unless you have a very specific use case it is more trouble than it is worth.

[ Parent | on HN ]

Re:Post mortem of a failed HackerNews launch by ck2 on Thursday November 29, 2012 @11:48AM (#4848646)

A small keepalive helps prevent browsers from trying to open too many connections and reuse existing ones more efficiently from what I have seen. Nginx handles connections more efficiently than apache so it doesn't hurt. But even Apache can benefit from a couple seconds of keepalive to get less thrashing.

You can use the optional second part the keepalive_timeout setting in nginx to send timeout hints to modern browsers, ie.

   keepalive_timeout 10 10;

Some servers like litespeed have the easy ability to do keepalive for static content (ie. a series of images) and then connection close for dynamic. This behavior can be emulated by nginx with the right configuration.

[ Parent | on HN ]

Re:Post mortem of a failed HackerNews launch by zorlem on Thursday November 29, 2012 @11:53AM (#4848675)

> Don't bother reducing keepalive, just disable it altogether. Unless you have a very specific use case it is more trouble than it is worth.

Bad idea. This way you're actively increasing the latency of your site. This way, for each asset that has to be fetched you're forcing the client to open a new connection, which can add more than 150 ms of delay per item (thanks to the three way TCP handshake).

What I would suggest is setting the KeepAlive timeout to a value that could handle each individual page-load. This way all the page elements will have a chance to use the connections that has been already opened.

[ Parent | on HN ]

Re:Post mortem of a failed HackerNews launch by Erwin on Thursday November 29, 2012 @04:00PM (#4850240)

With threaded Apache (mpm_worker), I have a huge keepalive set.

It's great for an ajax-heavy site, especially when it's all behind SSL. Using a CustomLog I log total request time, from connection time to the request has been served (conditional log when the request is handled by the backend) and I can see it's halved since I could use the threaded Apache.

Currently I have 100 threads per Apache process, and ~20 of them handling 2000 idle connections. I'm sure this can be tweaked some more.

Apaches manages SSL etc. and just proxies to my application servers.

There's also an event-based Apache module which I haven't tried.

[ Parent | on HN ]

Re:Post mortem of a failed HackerNews launch by thaumaturgy on Thursday November 29, 2012 @05:17PM (#4850606)

Actually, I've tested this. You get 10ms of extra delay per request, not 150.

There might be some magic value at which KeepAlive will be helpful during non-peak periods without crippling the server during peak periods, but for a well-engineered site, the extra 10ms delay per request shouldn't be a big enough deal to warrant risking a full-on site outage later on.

Also, this has already been discussed to death on HN: http://www.hnsearch.com/search#request/all&q=keepalive&#...

[ Parent | on HN ]

Re:Post mortem of a failed HackerNews launch by prodigal_erik on Thursday November 29, 2012 @09:19PM (#4851510)

Light travels less than two thousand miles in 10 ms, and TCP requires three one-way trips before starting the first request on a new connection. Anybody more than 620 miles away (about half a time zone) is guaranteed to have a higher ping time than that.

[ Parent | on HN ]

Re:Post mortem of a failed HackerNews launch by thaumaturgy on Friday November 30, 2012 @02:06AM (#4852207)

You're absolutely right, I didn't think about that. However, I did perform the test(s) from Sacramento, CA to a server in Newark, New Jersey -- a distance of 2,810 miles according to Google.

I was fairly careful with the test(s), and the 10ms difference seemed to be consistent. So that's odd. I need to investigate that further.

[ Parent | on HN ]