Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wordpress.com serves 70k requests/second using Nginx

highscalability.com

Post reply on HN
Print view View original

71–80 of 97 posts

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

#71

Post by nnq »

velodrome wrote: post #63
jacques_chester wrote: post #21

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…

"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...)

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

#72

Post by bad_user »

ck2 wrote: post #49
nisa wrote: 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 don't know how the caching plugin in WP works, however the most difficult part of caching is always cache invalidation, which is the reason why Memcache is better than an in-memory cache, even for a single server, because then you have the flexibility of invalidating cache entries from a background process that does not run on that server.

It's also great to have the flexibility of adding more servers in case of a huge spike, even if you are running on only one server. Like on Heroku, where you can just increase the number of dynos in realtime. Doing that without a central cache that every server can access can break your MySQL because each new server will have a cold cache.

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

#73

Post by vhf »

barsxl wrote: post #51
seldo wrote: post #43

Earlier quoted context omitted.

It's definitely not one load balancer, but nor is it 70krps distributed across 2000 servers. I also think having only one per datacenter would be a bit risky -- I'd have at least 2. It's very frustrating that the article doesn't make clear how many load balancers they run.

WordPress.com currently has 12 load balancers per data center. They are HA and used for different subsets of traffic.

Okay, so we can now do the "math" :

70 000 / (4 * 12 * 12) = 121.52 request per CPU

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

#74

Post by asithinketh »

jacques_chester wrote: post #21

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…

When I first read about Varnish it was framed as a "correct" implementation of what Squid was trying to do. It seems like people are using Varnish in situations where they would not otherwise be using Squid.

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

#75

Post by ocharles »

tsahyt wrote: post #65

This figure is not from a single instance though. When running a single instance of WP I've always found it to be fantastically slow. The greatness in the described stack really lies in Nginx. It's really not WordPress serving 70k requests here, it's some decent load balancing that achieves the effect. The title is somewhat misleading.

Yea, I was trying to find some information on exactly how many servers are responsible for content generation. If this is about 100 machines then yes, 70k/s is pretty damn impressive. If it's 1000 machines, then I'm a little less impressed.

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

#76

Post by rahul286 »

jacques_chester wrote: post #27
_hnwo wrote: post #25

Earlier quoted context omitted.

I'd be interested in seeing your 'fancy footwork' for the rewrite rules :)

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…

Thanks Jacques. Author of that updated config post on rtCamp.com here.

I really think Nginx in still underestimated by large. Most article handles rewrite in nginx based on their Apache knowledge.

Nginx's try_files is magical. So does maps{..} section.

Using Nginx map, you can server static files in WordPress-multisite without PHP (much better than X-SendFile or X-Accelredirection). On large wordpress-multisite network, this can really increase Nginx's capacity by multifold.

See - http://rtcamp.com/tutorials/nginx-maps-wordpress-multisite-s...

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

#77

Post by relix »

jacques_chester wrote: post #27
_hnwo wrote: post #25

Earlier quoted context omitted.

I'd be interested in seeing your 'fancy footwork' for the rewrite rules :)

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 to find alternatives for the if-statement, haven't looked into what you need really deeply.

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

#80

Post by ZoFreX »

jacques_chester wrote: post #60
mikescar wrote: post #58

Earlier quoted context omitted.

I'm interested to hear what versions of PHP and APC you used. In my experience, stable APC releases have been very stable, but beta APC can poop out pretty bad, even if the changelog doesn't indicate anything that might affect your application. I've used stable APC + PHP + Apache releases to do some large things, so not sure why APC is an utter bomb in 2012.

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

It's worth revisiting. We had huge problems with it when we tried it out in 2007, but I tried it again earlier this year and was pleasantly surprised - I got everything working, easily, and nothing broke. And I got that speed up.

My gut feeling tells me that your profiling is correct, however - any significant PHP application (that isn't written terribly inefficiently) will have its bottleneck in data access and not the parse/compile stage. There's very little point to speeding up by 250% a portion of your app that only accounts for 2% of execution time!

Post reply on HN