Live data from Hacker News

Wordpress.com serves 70k requests/second using Nginx

highscalability.com

81–90 of 97 posts

Re: Wordpress.com serves 70k requests/second using Nginx

#81
post #77

Earlier quoted context omitted.

Edit: actually, it looks like this doesn't work the way I think it does ... looks like nginx has changed enough between 0.7 and 1.0 that my original config doesn't work as correctly as it used to. Edit 2: Actually I think WP Supercache is the one that changed. Edit 3: This config looks more up-to-date than mine -- http://rtcamp.com/tutorials/nginx-wordpressmultisite-subdoma... I particularly liked how they used the t…

Googling is about the worst way to set up an nginx server configuration! The only tutorials and helpful snippets out there are riddled with bad practices. Here's a list of "pitfalls" that are commonly used and really shouldn't: http://wiki.nginx.org/Pitfalls I notice that you're using a lot of "if" statements. I hope you've read this http://wiki.nginx.org/IfIsEvil . I understand that in this case it might be harder t…

+1 to avoiding if. Tryfiles is amazing!

Re: Wordpress.com serves 70k requests/second using Nginx

#82
post #49
post #20

Earlier quoted context omitted.

Wordpress is only reasonable fast if you use APC, memcached and the MySQL query cache. I never liked the caching plugins. If you use nginx just use the fastcgi_cache module and make cookies part of the cache key or omit the caching of pages where the login cookie is set.

APC+mysql cache (not just query but keycache too) is a must, but memcached is pointless unless you have a multi-server website (on a single server APC shared memory is way faster than memcached). All logged out users should be served a completely cached static page that bypasses PHP entirely, it's way faster than even an opcode cache and way less load. WP-Super-Cache can serve static pages to logged out users and mak…

I've did some experiments - and yes APC is a little bit faster (1-5ms per page rendering) when used as key-value store in comparision to memcached via unix socket. However I had always problems with cache fragmentation and a resulting slowdown. If you use Apache mod_fcgid the PHP processes are beeing shot down and started at random and APC is is not shared acress them. With nginx and PHP-FPM is is not so true anymore. I've had the impression memcached is more solid.

For static caching I use nginx with fastcgi_cache. This makes WP-Supercache obsolete. I bybass the cache for requests containing certain cookies, so that logged in users always receive fresh pages.

Another big Wordpress performance sink is locales. If you have a blog in a non-english language consider using a language-caching plugin. Wordpress uses a PHP gettext implementation that is quite slow. 20% speedup if you cache the generated locales.

But it's a shame to spend days or months on tuning Wordpress, what is essentially just a blog engine.

Re: Wordpress.com serves 70k requests/second using Nginx

#83
post #54
post #38

Earlier quoted context omitted.

I have uptime of weeks with APC opcode cache without problems on very heavy loaded servers. You can also run a script to watch for PHP/APC segfaults and just restart the the cache. I cannot imagine running PHP without an opcode cache, you are losing a speedup of 300% to 500%

The majority of our transient bugs on WordPress.com are probably related to APC opcode issues. We try to catch them and handle it gracefully, but it isn't always so easy.

I'd be interested to read on your blog about what APC problems you've encountered - we have many wp installs with APC and the only problem is it will segfault once in a blue moon but we can automatically restart when that happens.

Re: Wordpress.com serves 70k requests/second using Nginx

#84
post #57

Earlier quoted context omitted.

The problem was not that lighty gave a 500 error for transient unavailability. It's that it got stuck in 500. I would have to log in every week or so and restart it when this happened.

In case you're wondering whatever happened to this bug, it's still happening! I installed the latest release of Lighttpd a few weeks ago and it happened on one of our sites. So amazing to see the same bug still kicking after 3-4 years..

I have this bug/feature as well, switched to nginx as a result.

Re: Wordpress.com serves 70k requests/second using Nginx

#85
post #67

Earlier quoted context omitted.

My point is that loading, parsing and interpreting PHP is rarely the bottleneck in Wordpress. In terms of microbenchmarks, opcode caches look spectacular. In terms of the larger stack, given the way Wordpress works? Meh, a few percent. It might be worth it for a big site to shave a few dozen servers off the bill. But the overhead imposed by flakiness is not worth my time.

I've never heard of anyone not get incredible speedups with APC. We're talking 250%+. Every (large) production PHP deployment I've seen, disabling APC would make everything fall over. They would need 3-4x as much capacity.

I think the big point here is that on a Wordpress site, most hits don't actually get as far as PHP -- most of the time, pages can be served statically from wp-supercache or similar.

Re: Wordpress.com serves 70k requests/second using Nginx

#86
post #69

Earlier quoted context omitted.

We're talking ... late 2007 here. I must confess that I didn't keep an engineering diary.

really? that might have been worth mentioning in all your other comments trashing opcode caching. that was 5 years ago .

No kidding. There really aren't "three major opcode caches" anymore, APC won out years ago and is now tightly integrated with PHP compiles and as a module available in any package manager.

Re: Wordpress.com serves 70k requests/second using Nginx

#87
post #71

Earlier quoted context omitted.

"One thing that always surprises me is seeing configurations where Nginx is merely a proxy or load balancer into a bunch of Apache instances. Are you nuts? Stop doing that. Just use Nginx and FastCGI -- thank me later." Problem is - you can't flush the output buffer.

Isn't there a known fix for this for like a year or so? ( http://www.justincarmony.com/blog/2011/01/24/php-nginx-and-o... )

It is only a 1k chunk. This sucks for chat-type applications (Also, in that example, you can't use gzip. If I use a nginx+apache setup, I can do output flushing and gzip. I hope nginx fixes this issue.

*This affects php/fcgi.

Re: Wordpress.com serves 70k requests/second using Nginx

#88

I've been administering Wordpress blogs for almost a decade now; hosting for ... 5? 6 years? I'm not sure any more. Anyhow. I started with Apache. Apache probably works fine if you load the mpm-oh-you-didnt-know-about-mpm-so-sorry module. My next stop was lighttpd. A fine piece of software, with a persistent bug that caused it to drop into a 500 state if FastCGI instances were ever unavailable. So now I'm on Nginx. A…

I don't use varnish because the whole philosophy is to let the OS select what to cache in memory, and ... well I already do that.

I don't follow how you already do that. Do you mean the OS disk cache?

Re: Wordpress.com serves 70k requests/second using Nginx

#89
post #88

I've been administering Wordpress blogs for almost a decade now; hosting for ... 5? 6 years? I'm not sure any more. Anyhow. I started with Apache. Apache probably works fine if you load the mpm-oh-you-didnt-know-about-mpm-so-sorry module. My next stop was lighttpd. A fine piece of software, with a persistent bug that caused it to drop into a 500 state if FastCGI instances were ever unavailable. So now I'm on Nginx. A…

I don't use varnish because the whole philosophy is to let the OS select what to cache in memory, and ... well I already do that. I don't follow how you already do that. Do you mean the OS disk cache?

Varnish caches the rendered html and stores it in disk for os to cache like mongodb with mmap.

Wordpress super cache plugin generates .html files from the pages and saves it in the disk for the os to cache.

Re: Wordpress.com serves 70k requests/second using Nginx

#90
post #88

Earlier quoted context omitted.

I don't use varnish because the whole philosophy is to let the OS select what to cache in memory, and ... well I already do that. I don't follow how you already do that. Do you mean the OS disk cache?

Varnish caches the rendered html and stores it in disk for os to cache like mongodb with mmap. Wordpress super cache plugin generates .html files from the pages and saves it in the disk for the os to cache.

This is what I meant.

Varnish leaves it to the OS to decide what pages to keep in RAM and which to leave on disk; essentially to avoid the double-buffering problem and because the OS has a larger view of the total machine's requirements.

But with wp-supercache I already have that approximate architecture. Files are on-disk, Nginx selects them, the OS notices that some files are frequently accessed and silently caches them in RAM. Everyone wins.

And I don't need to add ESI directives to my themes to get Varnish to handle frequently-updated material correctly.

Post reply on HN