Largest Project? Performance? Multi-Server?

[tsdtsdtsd]

Hi,

sorry for the not so awesome topic headline.

I would like to know how well processwire performs on a huge site with high traffic. I'm speaking of sites with 50-100k+ articles and dozens of millions page impressions per month.

I have the feeling that processwire could perform not that bad if the hardware is well scaled and with proper caching. But i think the backend user could get usability problems with that amount of articles and pages.

So, whats the biggest known site made with processwire? Any numbers available?

Also I would like to know if anybody has experiance with multi-server setups. Lets say one DB-Server, one for the backend, several frontend servers and a nginx loadbalancer.

As long as you don't use sessions features it should be doable with processwire i think.

Thanks

[ryan]

It's possible that there is some site out there using ProcessWire with hundreds of thousands of pages, but if there is, I don't know about it yet. I haven't gone above ~50k pages myself, though I don't think it would be a problem to scale as large as you need it to. It's not like an odometer on a car where there is a max upper limit and the higher you get, the more you are taxing the system. Whether your site has 100 pages or 100k pages, ProcessWire itself isn't dealing with any more data at a given time (only MySQL is). Scale should not affect the performance of the admin UI either. I actually think that the admin lends itself very well to large scale, and the larger scale you go, the more you'll appreciate some of the ways it does things. That's what it was originally designed for after all.

As scale increases, you just have to be more careful about how you develop things. You need to be conscious of calls like $page->children and be sure you are placing limits on quantity of results returned from such functions, i.e. $page->children('limit=50'); More about that here.

When dealing with high traffic, you need to consider caching at various levels. Know when to use template caching and markup caching. Optimize some situations with autojoin fields. You might also investigate FieldtypeCache to potentially reduce page load times and increase the speed of multi-field text searches. Make sure your PHP is running with an opcode cache like eAccelerator or APC.

I'm also working on an htaccess/rewrite cache for ProcessWire (like WordPress W3C Supercache), but it's not done yet. The advantage of this will be that you can direct some pages to be delivered directly from the markup file (via some complex rewrite rules), bypassing PHP, MySQL and ProcessWire completely.

I don't have anything to add about multi-server setups, but interested in hearing if anyone else has experimented here.

[Michael Fillier]

In regards to your htaccess/rewrite for improving performance, Drupal has a module called boost (http://drupal.org/project/boost) that has been used on really large sites. It seems to be in line with what you are talking about and maybe you will find something in there that will help you with PW.

[SiNNuT]

Probably the 'easiest' and most effective way to deal with high traffic websites is using a caching HTTP reverse proxy, such as Varnish cache or squid cache. It sits in front of your web-stack and caches and serves cached versions to your visitors, greatly reducing server load.

See for example http://highscalability.com/blog/2011/2/28/a-practical-guide-to-varnish-why-varnish-matters.html

Of course, this doesn't apply to cheap shared hosting.