动态wordpress安装,nginx,清漆,memcached,混合......的理想设置

TL:DR - Put simply, would you give up any sort of "dynamic" content/functions to get the massive performance gains varnish provides, let alone how would varnish handle something like using LiveFyre (commenting system hosted off-site)?


I'm looking to build a scalable stack that can serve ~500k/unique views/m (Wordpress) and while I can run varnish from a separate server that nginx is on with a separate mysql server and happily serve that I don't think it's the best route for us.

We don't need SSL and I haven't dabbled with SPDY (needs SSL of course) so let's go with not needing SSL for now...

I'm currently using nginx+mod_pagespeed+APC with mysql on a separate server and sure any caching would be a boost but I don't want to be back to working on scaling 6 months from now either.

I'd like for dynamic content to function (things like adding certain values to a DB row on article view, etc) which simply won't work with varnish, at least not the way I've used varnish. I know you can do ESIs and such and essentially just have varnish cache the header/footer leaving it let php/mysql process the body but don't know if the extra layer of varnish would even be worth it at that point.

So realistically, on a dynamic (widgets essentially, but also comments, which are served via LiveFyre) Wordpress install what would your preferred stack consist of? I don't want to say money isn't an issue but without saying "2 Hex Cores running nginx, 1 with varnish, 2 for memcache, 3 for mysql"... what would you go with?

I'm unsure if memcached would even be a solution for us (quite frankly, don't know the internals of how Wordpress would distinguish if it should pull from cache "sure pull the article from cache, but still need to insert values in the DB PER article view") or not.

First, don't worry about LiveFyre, because the people behind LiveFyre have already though about how to architect their solution. It is none of your concern because the performance of LiveFyre will depend on how good the connection between the visitor and LiveFyre's servers; and has nothing to do with anything on your end.

I'm looking to build a scalable stack that can serve ~500k/unique views/m (Wordpress) and while I can run varnish from a separate server that nginx is on with a separate mysql server and happily serve that I don't think it's the best route for us.

Why not?

I'm currently using nginx+mod_pagespeed+APC with mysql on a separate server and sure any caching would be a boost but I don't want to be back to working on scaling 6 months from now either.

That's okay, if you don't expect your visitor count to change in 6 months. In other words, scaling by definition is change. You need to work at it as the use demands of your applications change. You will need to revisit your architecture and layout.

I'd like for dynamic content to function (things like adding certain values to a DB row on article view, etc) which simply won't work with varnish, at least not the way I've used varnish. I know you can do ESIs and such and essentially just have varnish cache the header/footer leaving it let php/mysql process the body but don't know if the extra layer of varnish would even be worth it at that point.

Varnish is a cache; and by definition you cache things that don't change - which is generally your static content. So to figure out if varnish is a good use case for you, you need to analyze your application to see:

  1. Which queries are being used the most, and are they time sensitive. In other words, do you need to calculate the visitor count on each request, or is it okay if its calculated once a day.

  2. Find out what content doesn't change and this is a prime candidate for caching.

You will also need to monitor your cache's performance. If your miss rate is going up, it means there are things you need to cache but arent; you would also need to monitor it for stale content (but there are plugins to handle this for you).

So realistically, on a dynamic (widgets essentially, but also comments, which are served via LiveFyre) Wordpress install what would your preferred stack consist of? I don't want to say money isn't an issue but without saying "2 Hex Cores running nginx, 1 with varnish, 2 for memcache, 3 for mysql"... what would you go with?

No one can answer this because everyone's installation has a different use profile and as mentioned; this changes over time.

My perferred stack, for example:

  1. nginx
  2. redis
  3. postgresql
  4. S3
  5. memcache
  6. mongodb

Someone else will come around and give you another suggestion.

I'm unsure if memcached would even be a solution for us (quite frankly, don't know the internals of how Wordpress would distinguish if it should pull from cache "sure pull the article from cache, but still need to insert values in the DB PER article view") or not.

This is where plugins come in.