Hi,
Can someone please explain the reasoning behind the requirements for squiz stack v5 ?
I think squiz have taken the right path for postgres, redis, opcache, but I have questions about the web server and caching.
I'm still sitting on the fence in regards to php-fpm as I find that mod_php is faster than php-fpm in processing request and you don't have to spawn additional daemon.
If the caching server is configured properly and you have high static assets max-age then the webserver will be left to deal with predominantly dynamic request.
What is the main reason we are moving to nginx ? Is there a problem that cannot be solved using Apache ? How many user are actually having problem serving static assets ?
I have no doubt that nginx can do the job as I have use it outside of my work, however in enterprise environment we are limited to use pre-build binary package.
Caching is supported out of the box but to manage the cache ( ie clearing the cache) you either have to buy the commercial support, recompile nginx with ngx_cache_purge or recompile nginx with LUA then write a custom script to delete the cache from file system. How do we overcome this issue ?
Also, can someone please explain what is "Squiz Edge technology" and how do we use it ?
The move to nginx is definitely a carefully considered change, and one that we believe is going to allow us to build faster, better solutions for our clients in the future. Nginx combined with various modules (dubbed openresty) will give us some amazing capabilities in the future. We use openresty heavily in Squiz Edge (more on that below) and have been able to embed functionality into the web server that would not be possible with a traditional Apache based solution.
With Squiz Edge as the example, one of the features that we're able to provide customers (using an openresty core) is Edge Side Includes (see: http://en.wikipedia.org/wiki/Edge_Side_Includes).ESI gives us a whole new world of implementation driven functionality at the Edge servers, extending some of the page assembly logic out to the caching servers and taking that heavy lifting away from php and Matrix whilst also making the experience faster for end users. It's amazing stuff and we're finding new ways to leverage ESI every day.
I'm not exactly sure what your current architecture looks like so take this advice lightly, but you don't necessarily need to use nginx as the caching engine. We still do recommending using Squid to our customers that are not using Edge and existing cache purge functionality should remain in-tact. Customers with Squiz Edge don't need request caching at the application/web server, Edge is handling that for them.
php-fpm should give you a lower footprint on the server. If you're game - check out the php-fpm config options to see how you can get better bang for your buck, There's also some configuration options in nginx to specify things like the number of workers you want to use. Nginx itself is really good at serving static files, so anything under your __data directories you should find some improvements there.
Squiz Edge is our global caching network which allows our customers to have their site available in multiple regions, it enables ESI and also provides our customers with a seamless disaster recovery solution. If a customer's system goes down for whatever reason in one location, Squiz Edge keeps the site online whilst failing over to one of our DR locations.
There's a 1minute marketing clip here: http://vimeo.com/103414329.
Hope this helps
