necro

Correct. The reverse proxy pulls from the fast, local network apache, and then passed the data to the slow clients. Apace is connected for a shorter time. Basically you're trying minimize the time a "memory expensive" process like apache is open per client.

No, I'm not referring to this parameter in the write up. ipv4.tcp_slow_start_after_idle, which is on by default on most distros, applies to keepalive connections. This causes your keepalive connection to return to slow start after TCP_TIMEOUT_INIT which is 3 seconds. Not probably want you want or expect. For example, if you have keepalives of say 10s, you'd expect that a request after say 5s would have it's congestion window fully open from previous requests, but the default behaviour is to go back to slow start, and close your congestion window back down. So you want to tune this to off on your image servers and other keepalive systems.

The tuning which I talk about is to actually increase the default initial congestion window size. The result being an advantage for non-keepalive connections and keepalives. There is no sysctl parameter that will allow for this control. This behaviour is hardcoded into the tcp stack, and hence requires direct modification and a recompiled kernel.

I agree. Over here we do 70m (high write ratio) pages per month on 1 server handling all apache/php/mysql. Hardware is really fast these days if you tune it to any degree.

Heck, if we're showing off, here is how we do it...pretty graphs and all. http://www.pinkbike.com/news/pinkbike-speed-efficiency.html

Here is a pic of the transaction client side. The RTT is about 50ms. This is an intitial, non keep alive, request.

http://www.pinkbike.com/photo/4632455/

Notice that after the connection and the http request, in 1RTT you basically receive 10 segments at flight time (right after each other) This means the server is not waiting for you to ack. You see the acks in this picture (but note the times as they are sent but dont arrive till rtt at the server)

With out altering slow start the server would wait to receive and ACK before sending more segments.

There are 2 factors at play here... 1. slow start 2. window size Does not matter what the window size advertised, as slow start normally start at 2 segments. So in this case the client window is something huge. The advertised 5880 is the server receive window which also grows.

The motivation for it was to increase real world performance so the research, conclusion and implementation were guided by this fact. This was done on a real site with considerable traffic 50 to 100 php pages/second. This has been in production on the site for at least a year.

So in the real world, if a user click on a link to your site, the time to complete the load of the full html page (lets say a 22k page) is reduced to a single RTT instead or 4 RTT. To test that it's doing the correct thing you can verify with a packet analyzer or you can even see the results on something like firebug. Even if you consider RTT times of 50ms to 100ms it is still considerable difference to have the page complete the load in 100ms vs 400ms. Especially if you have script at the bottom of your page (say google analytics and such) this means that these requests start that much sooner, the page completed rendering sooner, etc.

In addition to the faster loading time there is another benefit to this.

In a busy server your best friend is the ability to process connection quickly. If you have to have a connection open for 4RTT vs 1RTT that starts to make a difference. Implementing this you release the process and connection to TIMEWAIT right away instead of tying up a valuable php process.

We've been increasing slow start on the server for a while now. (recomiple the linux kernel needed) We increase the initial 2 packet limit to 16. We do this ONLY for our html page in order to get it to the client faster.

Imagine a 22K page.... (1.5K frames, double every rtt)

after 1 RTT : 3K (2 frames * 1.5k per frame)

after 2 RTT : 3K+6K = 9K

after 3 RTT : 3K+6K+12K = 21K

after 4 RTT : 3K+6K+12K+24K = 45K

So for a client to get a 22K html page it requires 4RTT...if you think of 200ms for a RTT thats 800ms to get the page. Lame... increase your slow start from 2 frames to 16 so in the first RTT we send up to a 24K page in one shot.

This is useful for non-keepalive connections. For keep alive you may think that it remains open for the whole keep alive time but that's not normally true. The parameter that controls how long your window stays open is a configurable parameter called.... net.ipv4.tcp_slow_start_after_idle which is on by default. This causes your keepalive connection to return to slow start after TCP_TIMEOUT_INIT which is 3 seconds. Not probably want you want or expect. So if you are using keepalives for you image server and you want that first image to load faster...set net.ipv4.tcp_slow_start_after_idle = 0 to disable this

7Gbits/s saturated over a month is 2,247 TB

http://www.google.com/search?hl=en&q=7Gb%2Fs+in+TB%2Fmon...

So at your €15/TB i would be €33,705 / month

Also €15/TB seems low as prices around the US are $0.10/GB so $100/TB which would equate to around $200k/month

Of course when you are pushing that much data you're going to want to pay per Mbit/s and with bandwidth as low as $3/Mbit we get around $21,000/month

What is probably happening here is that this guy has 7 dedicate servers at about $150 each per month that have a gigabit connection with say a couple of TB data allowance for each server and he's just saying that he has a capacity of 7Gb/s. The chat client is probably peer to peer so the video bandwidth for him is not that critical.

The way to create the jobs needed in the US, is to take them away from someone else. The real problem is that technology (communication, transport, accessibility of buyers) has leveled the playing field for billions of foreign workers to compete in the US market. This means that if your job is to assemble widgets by hand, you better be ready to have the same kind of pay and living conditions and income as a billion foreign workers. That was the past, but now we keep arming the foreign countries with progressively higher level jobs by shipping the howto there. Years ago you would get your product electronics assembled in a box offshore. Now, you not only have the electronics made there, but also the ICs, and even much of the basic design work is done offshore.

So if this guy has a start up that creates a competitive technological vector away from the foreign countries' abilities, it's most positively the RIGHT way to create jobs. Do not count on the large companies doing this. Their way of creating efficiency and reducing economic drag is to ship the jobs off shore so their stock holders are happy (most of which are probably foreign anyways so they dont give a rats what effect this has in the long run).

The more technology and the progressively higher ability jobs you ship offshore, the higher and smarter jobs you need to have left in country.

It's simple...if a few billion people offshore can do the same job as you, and there is absolutely no transportation or communication barriers to have that job done offshore vs. in the US, guess what...it's done by the person that does it for less. If those jobs are assemblers, designers, engineers, you pretty fast run out of things all the American folks can do that others can't.

Though I agree that most single sites wont benefit from this. We have a single site serving 100 pages/sec and php is not even close to becoming a bottleneck.

The other application where this may be helpful is the cloud. In a system like this you have 100s or 1000s of sites on a single machine that may reach the combined traffic where this optimization can come into play.

After reading the article it is clear to me that perhaps the best treatment for depression would be a start up. The symptoms fall right in line with a startup lifestyle: ability and need to continuously work on problems dividing them smaller and smaller, eating disorders and weight loss or gain, isolation and not spending time with friends and loved ones, etc. I'm not depressed but my startup lifestyle sure has me living with the symptoms.