I am the first to admit I am not a PHP expert. I don’t have the same depth of PHP knowledge and experience than many others do. There has been a lot of discussion about PHPNG vs HHVM and which is faster. As I see it
- PHPNG is not here yet, so until then its interesting to watch but not going to change what I do today.
- HHVM is here today, but not guaranteed to be compatible across all extensions, and relying on it would tie you to a single vendor (Facebook) rather than a community.
Both are interesting. Both claim good gains with low effort. But if you are serious about getting a Magento site running faster, are they actually the most important question?
If I look at a large PHP application such as Magento, a lot of time seems to be taken as a part of the startup overheads. This includes getting the PHP code started (which is why op code caches etc help), but for an application like Magento there is also a lot of loading of configuration files after the code starts running that do not change between requests. For Magento 2 in particular there are class maps for auto-loaders, dependency injection configuration files, layout files, and so on.
I sometimes wonder if Magento 2 more clearly separated loading configuration files etc (and caching the results) from the processing of the current request (with dynamic data) whether more significant performance gains could be achieved than what PHPNG/HHVM offer. Sure, the code would have to be carefully written to make sure no “sensitive” data was accidentally cached around between requests. And you would have to watch memory usage more. But would it go faster?
I don’t know the answer – sounds like a bit of effort required to try it out. But looking around I see projects like ReactPHP that have a long running server that responds to multiple requests (so can cache data structures between requests). The article http://marcjschmidt.de/blog/2014/02/08/php-high-performance.html was particularly interesting. “As we can see, the react server with nginx as load balancer is over 15 times faster than old school PHP-FPM + APC”. I have no idea if Magento would achieve the same gain.
This is an interesting question to me. Is making PHP faster is actually the main way to improve performance and throughput of a large PHP based application? Or is it the web server model of starting a script from scratch per HTTP request that is the ultimate problem? The current model is certainly robust and easy to adopt, which is a real positive, but if you are serious about performance and scale is it enough? Or is it that if you want serious performance you need to think about a model where PHP code is kept running (in say an Actor based threading model) to avoid the startup overheads per request. The PHP code is there, pre-initialized, and waiting to process the next request.
Anyone got experience with this in PHP? Or does PHP leak memory so much (for example) that this approach is just not feasible in practice?
Alan Kent's Blog 
While I didn’t gather experience with ReactPHP and the like I’d suggest you get in touch with TechDivision (Magento Gold Partner).
TechDivision developed appserver.io, “an application server like JBoss from Java within PHP”: http://www.appserver.io/what-is-appserver-io/highlights.html They use it in production for at least one big Magento installation and it’s an interesting concept which too promises significant performance improvements.
Thanks! Looking at diagram it seems more about putting together an app server from standard components, so not about architecting applications differently for higher performance.
There were tweets from @maxbucknell where the suggestion if I paraphrase (and hopefully not messing up the intent) was thin down startup overheads and instead of changing web server model, go to a more queue based async model so you do less real time and more in the background. This then is a Magento architecture change, not a php level technology change.
A part of the introduction of the service layer to me is to start making this more feasible. This however may take a bit of time as the current APIs are closer to saving records and seeing results immediately. An async approach would require changing the API model around a bit I think to submit a request to do something, but doing it in background. So you don’t return the result of the operation, but rather a handle that you can use to check when the job is done. Interesting stuff.
If I remember correctly then there is more to it than just providing standard components.
First, it focuses on making multithreading a first class member and enabling software to much better use the threading capabilities available in PHP.
Second, there was (at least conceptual) working being done so that the PHP / Magento code isn’t run through from start to end on every request. Think of a typical Java / whatever application where the application is started once and has a running process which handles requests without having to bootstrap everything from the ground for every HTTP call.