Poul-Henning Kamp

It's not the same - you have to compile Nginx with mod_wsgi support. It's not as simple as doing an "apt-get install nginx" and it may compile with your version, or it may not compile.

Also, read this: http://blog.dscpl.com.au/2009/05/blocking-requests-and-nginx-version-of.html

mod_wsgi is an interesting example. Surely it has the wrong architecture for Nginx and something better could surely be written. But mod_wsgi for Apache simply kicks ass, being a server that manages everything for you with low overhead and good performance caracteristics. No need for supervisord or any of that crap.

Some people go as far as recommending running Nginx in front of Apache, with all the overhead that brings, just for mod_wsgi (although the same could be said about mod_php).

That's the thing about Apache - it's so mature and has so much traction that you can find quality plugins for anything and everything, being an all you can eat buffet.

But then if you're going to put Nginx in front of Apache, why go with Nginx instead of Varnish: http://www.varnish-cache.org/ -- which is designed from the ground-up to function as a high-performance proxy cache (the Nginx plugin for proxy caching sucks donkey balls IMHO)

What I'm trying to say here is that Nginx is very far from a one-size-fits-all. It's awesome for at least one website I've got written in Ruby on Rails and I'm using it in combination with Passenger (Ruby's mod_wsgi).

But for all my other use-cases, I'm starting with Apache…

Moving memory management into the OS often makes sense, because the OS has the big cross-application picture, knows the system-wide memory pressure, and most importantly, already manages the memory of applications, by swapping between RAM and disk.

For the same reason, OS X and Android Linux both have systems for OS managed caches, and AFAIK Firefox already uses these: https://bugzilla.mozilla.org/show_bug.cgi?id=748598

The status on mainline Linux is a bit more nebulous (seems Android's ashmem has been upstreamed, but it's not directly usable on GNU/Linux systems?), and other efforts have stranded: https://lwn.net/Articles/602650/

For some more thoughts about memory management on OS level vs. application level, I can recommend this "random outburst" from the designer of the Varnish HTTP cache: https://www.varnish-cache.org/docs/trunk/phk/notes.html

"Varnish allocate[s] some virtual memory, it tells the operating system to back this memory with space from a disk file. When it needs to send the object to a client, it simply refers to that piece of virtual memory and leaves the rest to the kernel.

If/when the kernel decides it needs to use RAM for something else, the page will get written to the backing file and the RAM page reused elsewhere.

When Varnish next time refers to the virtual memory, the operating system will find a RAM page, possibly freeing one, and read the contents in from the backing file.

And that's it. "

https://www.varnish-cache.org/trac/wiki/ArchitectNotes

I'll try and hold back the snark but I find it interesting that after attacking '1975 programming' and Squid's deficiencies, here we are 8 years later and maybe the kernel doesn't know best.

You need to read the documentation on this and understand it:

https://www.varnish-cache.org/docs/4.0/whats-new/index.html

Otherwise you should just be using a popular file from around the web. Take a look at the Varnish Utilities Directory:

https://www.varnish-cache.org/utilities

There you can find two of the best resources for ready to go VCL (for now Varnish 3 only):

https://github.com/slashsBin/nuCache

https://github.com/mattiasgeniar/varnish-3.0-configuration-templates

I am sure that if you ask nicely, the project members of these efforts might just give you a hand and upgrade to VCL 4.0 syntax a usable Wordpress template. Be willing to test and contribute back with whatever you can though.

Needs (2023)

That services layer reminds be of a big, fancy, distributed Varnish Cache... they don't mention caching and they chose the word coalesce so I assume it doesn't do much actual caching. But made me think of Varnish's "grace mode" and it's use to prevent the thundering herd problem (which is where I first heard of 'request coalescing') https://varnish-cache.org/docs/6.1/users-guide/vcl-grace.html#grace-mode

Also love to see consistent hashing come up again and again. It's a great piece of duct tape that has proven useful in many similar situations. If you know where something should be then you know where everything is gonna come look for it!

You can not accurately estimate how much network traffic will be generated. There is nothing from stopping it from becoming immediately viral. Sites have had hundreds of thousands of visitors increases daily. Be prepared. Host the static on s3 etc... Engineer for it.

Varnish: https://www.varnish-cache.org/
A decent primer.

Failover database servers? Auto scaling on amazon?

A Fortune 500 is a big deal. Don't worry. This is a good kind problem to be having. Regardless, the exposure will continue and be referenceable which is great for your site.