I would also recommend that you gzip any static assets and use <a href="http://wiki.nginx.org/HttpGzipStaticModule" rel="nofollow">http://wiki.nginx.org/HttpGzipStaticModule</a> to serve these pre-gzipped files.<p>No point in re-compressing the same files over and over again. I normally gzip all static assets as part of the deployment process.
Some useful Nginx optimizations, but I've always found that the bottlenecks are far worse elsewhere. Nginx is a champ at serving static files, and I have it proxy all requests upstream to Apache (and use mod_wsgi because the majority of what I work with are Django apps). Optimizing the DB schema and queries have had the most positive performance increases by far, followed by Apache tweaks, and then finally Nginx config changes. But I really love the setup I use for how easy it is to get a Django app spun up.
If your app uses a database, you've got bigger problems than optimizing Nginx for high traffic loads.<p>That said, I absolutely love Nginx because it's so damn lightweight, and easy to setup and maintain.
<i>> The biggest optimization happened when you decided to use Nginx and ran that apt-get install...</i><p>I recommend against doing this on Ubuntu Lucid without first installing the unofficial nginx PPA, unless you want to get stuck with v0.7.65.
I think he's got a little math problem. Many browsers will open up to 4 connections (possibly more, if config tweaked) to overlap requests for content, so you might want to consider this when configuring your worker_connections.
too bad there's not so much said about optimizing latency, serving a lot of traffic is not that difficult, but getting the best latency to serve your files 50ms faster can make a big difference