I have always been a proponent of the 5 second cache for things like blog posts. After you hit Reddit, you can see 1000 requests a second for a few minutes. If you cache for 5 seconds, nothing is ever very far out of date, but you save yourself 5000 requests. Seems like a win-win.
(I'm also a big fan of Varnish. I tried it out this weekend on a site that basically serves an HTML file that says "hello world". Apache can do about 11,000 requests a second, but Varnish can serve 15,000 requests a second. Excellent!)
Chances are that you will need to do some serious kernel tuning before you will really run in to the limits of what varnish can do.
If you're using linux using IPV4 have a look at the following parameters in /proc/sys/net/ipv4:
tcp_tw_recycle
tcp_tw_reuse
Tuning those will help in allowing faster re-use of sockets in the TIME_WAIT state. This matters because at the defaults your sockets will linger for a long time before being allowed to be re-used (as per the RFC). Technically this is the correct behaviour but it can quickly become a bottle-neck.
Ulimit max open files per process:
ulimit -n 50000
The default is just 1,024, and that's not nearly enough to keep varnish working hard.
Those are the first things to look at, there are many more once you start to bottom out again, but this will get you started.
A good way to see if you've got your kernel tuned properly is when varnish starts to approach the limits of your hardware, I've seen it do well over 600Mbps on an otherwise unloaded box.
Why stop at 5 seconds? Unless you're updating that blog entry every 6 seconds, you're missing out on a bunch of good caching by regenerating it 12 times a minute.
How about cache it once at write-time, then again whenever you edit it?
Rather than repopulating the same cache entries every 5 seconds you could instead actively purge the Varnish cache entry when the content actually changes.
Now that I am remembering better, I actually hit the front page of Reddit and del.icio.us at the same time. Those both drive a surprising amount of traffic. (The article was "Git merging by example", now archived here: http://blog.jrock.us/posts/Git%20merging%20by%20example.pod)
I did not use varnish at the time, but I basically kept up with the load. My pages were cached with an in-memory cache in the app layer, which worked well enough, I guess. As blog.jrock.us mentions, I was unhappy with the design of my software, so I took it down. Two years later, I almost know what a good design is, and so I should have a blog again soon. But I digress :)
Comments
I have always been a proponent of the 5 second cache for things like blog posts. After you hit Reddit, you can see 1000 requests a second for a few minutes. If you cache for 5 seconds, nothing is ever very far out of date, but you save yourself 5000 requests. Seems like a win-win.
(I'm also a big fan of Varnish. I tried it out this weekend on a site that basically serves an HTML file that says "hello world". Apache can do about 11,000 requests a second, but Varnish can serve 15,000 requests a second. Excellent!)
Chances are that you will need to do some serious kernel tuning before you will really run in to the limits of what varnish can do.
If you're using linux using IPV4 have a look at the following parameters in /proc/sys/net/ipv4:
tcp_tw_recycle
tcp_tw_reuse
Tuning those will help in allowing faster re-use of sockets in the TIME_WAIT state. This matters because at the defaults your sockets will linger for a long time before being allowed to be re-used (as per the RFC). Technically this is the correct behaviour but it can quickly become a bottle-neck.
Ulimit max open files per process:
ulimit -n 50000
The default is just 1,024, and that's not nearly enough to keep varnish working hard.
Those are the first things to look at, there are many more once you start to bottom out again, but this will get you started.
A good way to see if you've got your kernel tuned properly is when varnish starts to approach the limits of your hardware, I've seen it do well over 600Mbps on an otherwise unloaded box.
Why stop at 5 seconds? Unless you're updating that blog entry every 6 seconds, you're missing out on a bunch of good caching by regenerating it 12 times a minute.
How about cache it once at write-time, then again whenever you edit it?
Rather than repopulating the same cache entries every 5 seconds you could instead actively purge the Varnish cache entry when the content actually changes.
You get 1000 requests a second from Reddit? Wow, it's a whole lot bigger than I thought.
Now that I am remembering better, I actually hit the front page of Reddit and del.icio.us at the same time. Those both drive a surprising amount of traffic. (The article was "Git merging by example", now archived here: http://blog.jrock.us/posts/Git%20merging%20by%20example.pod)
I did not use varnish at the time, but I basically kept up with the load. My pages were cached with an in-memory cache in the app layer, which worked well enough, I guess. As blog.jrock.us mentions, I was unhappy with the design of my software, so I took it down. Two years later, I almost know what a good design is, and so I should have a blog again soon. But I digress :)
Needs to prove it!