We're looking for a PHP framework to work with in future and are currently testing out things with Symfony 2. For this, we've redesigned our API and implemented it as a bundle in Symfony. It turned out that Symfony seems to be very slow - actually far slower than our old (not even well-designed) system.
We tried to optimise the performance by caching the byte code (using APC for this). While we've noticed a huge improvement in performance (before: about 3 seconds to load the API; after: 0.6 seconds in average (still 0.5 seconds slower than our old system without APC)), we're kind of excited - but still not really pleased with the high loading time of such an easy task like getting one result out of an almost empty database.
I don't know, but I could imagine this is due to Symfony autoloading all classes, even when not needed for a specific bundle.
Now, before we deep-six Symfony, we'd like to look out for further optimisations, possibly a way to exclude unneeded components in a specific bundle, as I personally think this would make a big difference.
I'd be thankful for any ideas on how to further improve the performance, experience reports with using Symfony or anything else that could be helpful for us on the lookout for a framework.
Edit:
Some information about the testing environment:
Operating system: Ubuntu 12.04.4 LTS (GNU/Linux 3.8.0-38-generic x86_64)
Apache version: Apache/2.2.22 (Ubuntu)
PHP version: 5.3.10-1ubuntu3.13
Considerable PHP extensions: apc
Also, all tests are done on a local copy of our system, so possible network issues can be excluded.
These points can optimise your application performance:
Upgrade PHP. The performance gain between PHP 5.3 and PHP 5.4 is very high. PHP 5.5 would be even better, but it's not supported by all distributions, like Debian 7.
NGINX is faster than Apache and the configuration is easier.
Using PHP-FPM with NGINX is a good combination. You can also run your PHP with HHVM which is in average 2x faster than PHP-FPM, provided you replace Symfony/Assetic with Grunt. Caution: HHVM requires more precaution and testing before deploying safely. You can follow these two articles (in French): JoliCode and Big Brains Company
PHP APC extension is deprecated. I think that XCache, Memcached or Redis are better, and they're also most supported at the moment. For PHP >= 5.5, APCu can be used as a replacement for APC.
Additionally, you can read a few articles which talk about Symfony2 optimisation and provide Twig benchmarks.
PHP articles:
Script high-performance in French
Comparison of PHP 5.3 and PHP 5.6 performance in French
Check this article to apprehend the PHP optimisation in French
Google's recommendations for optimising PHP applications in English
10 best pratices to optimise PHP in English
Symfony2 and Twig articles:
Symfony documentation gives a few tips how to build a performant application in English
Template optimisation in French
Twig include optimisation in French
Use #Cache annotation requests in English
Symfony2: Good practices in French
Limit the usage of unnecessary bundles
Symfony2 Twig performance optimisation in English
If you don't want to use the Twig Engine, you can disable it in French
Caching in Symfony from it's Cookbook - really impressive!
Others optimisations:
Maybe you can use an updated version of Ubuntu.
Personally, I prefer using Debian which is also popular for servers because it's very stable.
Using a cache proxy like Varnish can be a finishing touch.
Varnish requires a developer's implication and maybe a formation. Using NGINX FastCGI Cache to limit FastCGI requests to HHVM, FPM or PHP-NG can resolve speed response.
Did you look this blog post ? http://symfony.com/blog/push-it-to-the-limits-symfony2-for-high-performance-needs
According to your information, i can advise you to try php 5.5 or 5.6 and NGINX with PHP-FPM, it can 40% faster or more.
You can try approach suggested in this article: http://stfalcon.com/en/blog/post/performance-symfony2-doctrine2-orm
The author suggests to:
Download all necessary connections
Update multiple entities by request
Get data as an associative array
Use reference proxies
Don't forget to use Symfony profiler toolbar
The code described is availiable on github: https://github.com/lensky84/performance
Related
i need to maximize performance in a zend framework 2 + doctrine 3 project , the application is slow so i've woked in enabling the memcache for some queries , i've also enabled the cache for the config files ... but the application stills slow so searching in the net i found some articles talking about performing zf2 project and mentioning apc as a way to make the application not so slow , so i've installed apc, but i can't find a way to configure how to enable apc in zend framework 2?
APC is a PHP extension, it's not something you need to enable within individual applications unless you're using it for userland caching as well (which I assume you are not, since you mentioned memcache). You can check if it's working by firing up a phpinfo page and seeing if you have an APC section.
If you have PHP 5.5 or above, you don't need (and shouldn't use) APC, as PHP comes with its own (better) opcache.
I'd suggest you benchmark your application using something like XDebug to find out what is causing the slowness. This should give you a better idea what you need to improve.
I have installed the Skeleton application of ZF2 (from official GitHub repo), and the first page I see takes 400-700ms to load (default "Welcome to Zend Framework 2" page, with no database connections and without handling anything).
In raw PHP (without frameworks) It'll take a few ms. to load.
Could You explain, what caused such a big delays?
I'm new to ZF, and now deciding, to use or not to use it.
Zend Framework is a heavy php framework which uses a lot of php files. Because php is evaluted on the spot it takes a lot of time every request to evaluate these files. You should use a Opcode cache like apc and many others or if you're using php 5.5 Opcache that is built -in. An Opcode cache makes a copy of these evaluated files and stores these in memory. This gives a huge speed bonus.
Another thing that might be the problem is that if you run this ZF2 application with apache on windows it is much slower then apache on linux
It's hard to know whether this is good or bad without any info on the server you're running this test on. You also implied that this was a stock ZF2 skeleton app, but your screenshot shows what I think is the ZF2 developer toolbar, an add-on module.
I just tested a fresh checkout of the skeleton app on my (admittedly decent spec) dev machine and it loads in 30 ms (PHP 5.5). I would expect to be able to improve that with some simple production-type optimizations (classmap, config caching, superluminal etc.).
Edit: I thought I'd see what I could get this down to with some quick tweaks. I also installed the developer toolbar just to be sure this wasn't slowing things down too much. Result:
Would it make sense to switch to HipHop instead of XCache?
Is HipHop ready for primetime or should we wait several months before implementing it?
Edit: we are interesting in testing the configuration on a server running vBulletin.
Let me clear up a misconception you might have about Hiphop and Xcache. XCache works by adding Opcode caching to ZEND's PHP implementation (like APC and friends), while Facebook's HipHop allows for PHP code to be transformed into C++ code and then compiled using g++. It's not possible to run XCache with HipHop as HipHop doesn't depend on Zend interpreter (and doesn't even use php opcodes as it's compiled to bytecode after transformed to C++).
Now to answer your question, HipHop is being used live to host a large amount of Facebook's traffic. Facebook wouldn't release this project if it wasn't near stable, but since it is very new I would still exercise caution. HipHop is not just a patch to the old Zend Interpreter, it is a completely different way to run the PHP code and will probably have a few bugs in it.
One thing that Facebook did to ensure that Hiphop was working before they switched to it was they were able to setup very rigorous unit tests of each possible request on their site. That way if the output from Hiphop was different from the normal Zend PHP, they would go back and debug some more until everything "worked for them". Just because it "works" on Facebook code base doesn't prove that it'll work for yours. If you do decide to switch to HipHop, make sure to test it well.
EDIT:
HHVM (new VM version of HPHP) can now eval and create_function. They should be the same for all/most meaningful reasons.
There are a few things that aren't compatible with HipHop. They removed the eval and create_function functions. They also only support PHP 5.2.x for now, but they are plan to add support for 5.3 "soon".
I like the idea of HipHop, so don't get me wrong here, but there is something to remember: HipHop is not for everyone. From Sebastian Bergmann:
it is not a solution for a problem faced by 99.9% of the PHP deployments out there
Unless you have Facebook proportion traffic and your bottleneck is CPU or memory usage, you're not likely to see much of a benefit (as compared to xcache, apc, etc). Database and file system access are still going to be your killers.
I'm fairly confident that vbulletin 3.x will not work with HipHop. VB 3's plugin system consists of nearly 2000 eval statements sprinkled throughout the code, and eval is not supported by hiphop.
That's probably only the tip of the iceberg, when it comes to getting vbulletin to compile.
A friend has recommended that I install php APC, claiming it will help php run faster and use less memory
sounds promising but I'm a little nervous about adding it to my VPS server
I have one small app that I've built using codeigniter, and several sites that use the popular slideshowpro photo gallery software
could install this break any of the back end code on my sites?
I'm no high tech server guy, but should I give this a try?
Depends entirely on your situation.
Is your site unresponsive or slow at the moment? Is this definitely due to the PHP scripts and not any other data sources such as a database or remote API?
If you answered yes to the above, then installing one of the many PHP accelerators out there would be a good shout. As for using less memory, that's largely dependent on your apache/lightppd/nginx config and php.ini variables.
Most PHP accelerators work by converting the (to be) interpreted PHP code into opcode. This is then stored in memory (RAM) for fast access. If you haven't already implemented file-based caching in CodeIgniter then the benefits of installing a PHP accelerator would be noticeable. If you haven't, then I suggest you do that first before moving straight over to (wasting?) spending time trying to install APC manually.
If your site is currently performing well and you're not too confident in your *nix skills then I suggest you try implementing CodeIgniter caching first rather than try messing with what is an already working VPS.
My personal preference is PHP eAccelerator.
Should installing a PHP cache engine not improve your site's performance then I suggest you look at what other factors influence your application. As stated above, these could be: database or API to name a few.
Hope this helps.
APC is basically a cache engine that stores your compiled php scripts on a temp location on your server. Meaning that these do not have to be interpreted every time someone calls your sccript. It is a PHP extension can can safely be turned ON or OFF and it does not affect your actual code. So... do not fear!
When a php script is processed, there is a compilation phase, where php converts the source code of the php files into "opcodes". APC simply caches the result of this compilation phase, so it should be safe to turn on.
That said, when making such changes to production code it is always wise to run a regression test to ensure no new issues have been introduced.
Does anybody have experience working with PHP accelerators such as MMCache or Zend Accelerator? I'd like to know if using either of these makes PHP comparable to faster web-technologies. Also, are there trade offs for using these?
Note that Zend Optimizer and MMCache (or similar applications) are totally different things. While Zend Optimizer tries to optimize the program opcode MMCache will cache the scripts in memory and reuse the precompiled code.
I did some benchmarks some time ago and you can find the results in my blog (in German though). The basic results:
Zend Optimizer alone didn't help at all. Actually my scripts were slower than without optimizer.
When it comes to caches:
* fastest: eAccelerator
* XCache
* APC
And: You DO want to install a opcode cache!
For example:
alt text http://blogs.interdose.com/dominik/wp-content/uploads/2008/04/opcode_wordpress.png
This is the duration it took to call the wordpress homepage 10.000 times.
Edit: BTW, eAccelerator contains an optimizer itself.
MMCache has been deprecated. I recommend either http://pecl.php.net/package/APC or http://xcache.lighttpd.net/, both of which also give you variable storage (like Memcache).
Both are interesting and will provide speed boost since they compile source code into binary representation which is then executed by the PHP engine.
Any huge web site running with PHP (Facebook for example) is running some sort of opcode cache system like MMCache.
The problem is that they are not very easy to set up depending on your system.
Depending on how much of your PHP code is actually executed and how long that execution takes they can be a really big win. It certainly isn't going to hurt, but the gain you see will very much depend on where your time is currently spent.
btw mmcache has been rolled into a different project now, I forget the name but Google will tell you.
I use APC on my production servers and it works pretty well out of the box. Compile it and add it to PHP and there isn't much tweaking left to do for it. I check it every once in a while just to review stats but since I use MVC a lot all of the main files (routers, controllers, etc) rarely change on a day-to-day basis so that code stays compiled and runs pretty efficiently.
currently we use apc, free and was just a simple plug and play on our live servers. Provided a huge performance increase for our site, especially as the project size increased. I also have the apc.stat disabled so it doesn't check if the code has been updated, so whenever we need to update the code on the live site we restart apache.
I use APC, and can attest that it can dramatically reduce the CPU and I/O load on an app server if you maintain a high cache-hit rate. It not only saves you from having to compile, it can save you from having to read the php files from disk at all. (i.e. the bytecodes are served directly from main memory, so it's super fast) It lowers the speed to render a single page, and increases the requests per second your server can handle.
If you use RedHat or CentOS, installing APC is super simple:
yum install php-devel httpd-devel php-pear
pecl install apc
echo "extension=apc.so" > /etc/php.d/apc.ini
# if you're using SELinux:
chcon "system_u:object_r:textrel_shlib_t" /usr/lib/php/modules/apc.so
/etc/init.d/httpd restart
You asked about downsides. The only downside is that it requires some memory. The default on APC is 30MB, but it can be adjusted, and the cost of a little bit of memory more than pays for itself with the increased speed and response rate.
BlaM's testing included all the DB calls made by WordPress. When you're making fewer DB calls, you'll see the performance gain of opcode caches be even more dramatic.
I used Zend Accelerator a little back in the day (2004-ish). It certainly gave some significant performance wins on code it could work with, but unfortunately the system I was using was designed to quite often dynamically load code and then eval it, which Zend Accelerator couldn't do much with at the time (and I'd guess still can't).
On the down side, we certainly saw some caching issues (where the code would be changes, but the compiled version sync with the change for one reason or another). I imagine those problems have likely been ironed out by now.
Anyway, I don't have any hard comparison numbers, and certainly didn't write the same system in different environments for comparison, but for the vast majority of systems, PHP isn't going to kill you performance wise.
Have you checked out Phalanger? It compiles PHP to .NET code. Here are some benchmarks which show that it can dramatically improve performance.