Optimize my performance

Question

I'm working on a project with Zend Framework 1.11, Doctrine 2, some Symfony 2 componenents and others tools & libraries.

I'm trying to optimize performance using Xdebug & Webgrind.

I've already found some bottlenecks like parsing Ini config, etc.. and cached that.

Now, I just realize that the autoloading is the most costly part of my application:

    Opl\Autoloader\ApcLoader->loadClass                    274   31.36   43.86
    Zend_Loader_PluginLoader->load                         150    4.80   12.29
    Zend_Loader_Autoloader->getClassAutoloaders            278    1.42    1.91
    Zend_Controller_Router_Route_Regex->_getMappedValues   291    1.29    1.35
    Doctrine\ORM\UnitOfWork->createEntity                   85    1.24    3.18

As you can see I'm not using the default Zend_Loader_Autoloader, I'm using Opl which is, as far I know, quicker than it, I'm using the classMapLoader with an APC cache but it still a bit slows compared to rest of the application.

How could I optimize that?

I've around 250 classes loaded, and it looks that only ~40 are slow, others show 0,00 as "Total call cost" but others are increasing from 0,08 to 0,57 on the require call.

By the way, since using the Opl autoloader, it looks that on my production environnement APC only opcode cache the file which are "manually required" not the ones which are called by the autoloader.

score 4 · Accepted Answer · answered Dec 19 '11 at 11:21

4

If refactoring your code is not an option (drop Zend Framework, Drop Doctrine, Drop ...) I would first optimize in buying better hardware. That will automatically optimize your code, because the context of the code is just shifted (this is not exactly optimizing the code, as the code won't change).

If that is not an option consider to create yourself a build system that can pre-process your codebase and create a non-development version of it to cut the loading process. This requires the analysis which files are needed always and you compile them all into a loader-optimized format which could be single file and/or static class loader maps.

However it's known that Zend needs to load a lot into memory always. Even using a PHP cache like APC might already bring you something (consider to pre-compile with the earlier noted build script and optimize the parts highlighted by your metrics).

If your application structure allows it, there is another possibility, too: Keep your whole application in memory between requests. That can be done with a PHP webserver. That done, the code only needs to get loaded once the server starts and will never needed to load again. This only works with your own application if it supports multiple requests. A good encapsulated application especially with the request logic can be adopted quite easily for that. An existing solution is appserver-in-php. You will be amazed how much the speed increases compared to the benefits you already gained from APC.

Maybe this was helpful. Any additional, more concrete suggestions are hard to make as it's not possible to see your code in action nor to have detailed metrics on it. You've just passed a fragment on what's going behind the scenes so it's hard to tell you more concretely.

answered Dec 19 '11 at 11:21

hakre

193,403
52
435
836

thanks your great answer, in fact my problem is I migrated from old fashioned application with ZF1.7 and Zend_Db and its transaction rate (given by siege) returns something like 30/40/s where mine is only 10, however I made a lot of optimization like queries optimization that reduces globally the request time but I'm a bit disapointed to have such rate. For sure buying new hardware is a solution, and it will be but I don't want it either to be THE solution. When looking at the autoloader, it looks like Doctrine requires more file than Zend Framework itself. – Trent Dec 19 '11 at 13:10
Consider if your really need an ORM in your application. If you don't, drop doctrine and just use the *table data gateway* or *row data gateway* zend library offers. Or just stick to your own db abstraction with the PHP native mysql driver in PDO. If database is your bottleneck, bring your code and the database closer together for shorter paths. This might reduce some comfort options the ORM offers, but you will be much faster and code your own comfort by creating your own function to fetch and push data to the mysql storage. – hakre Dec 19 '11 at 13:18
1

I like the suggestion to drop all kinds of stuff (i.e. lighten up). I don't care for the suggestion "buying better hardware. That will automatically optimize your code". That's like saying if the jockey's too fat, get a faster horse. The hard-working engineers at chip vendors do amazing work to give us ever faster hardware. I wonder if they know that programmers are relying on that, rather than getting the fat out of their code? – Mike Dunlavey Dec 19 '11 at 14:20
@MikeDunlavey: Thank you for sharing your opinion about scaling with hardware. I think it can be valid under circumstances so I actually mentioned it, but it's only one suggestion out of multiple. Until today it's not really governed by law how much we can bring down earth resources, so right now, if you still can get more power, get it. When this ends, programmers are needed to change the mess again, so it's a perfect job-machine to produce fat code today and then to un-fat it in 10 years or so. Same applies for hardware designers. ;) – hakre Dec 19 '11 at 14:27
1

@Mike Oh but KIWI (kill it with iron) works great for lots of companies. So great in fact that those companies use it every year or so! They certainly wouldn't use it that often if it didn't work? ;) Although I think it's warranted in some cases if you've already optimized ith the usual tricks and would have to rewrite large parts of the code for further optimizations - one only has so many engineers after all and there's always more to do than we can :) – Voo Dec 19 '11 at 14:39
@Voo: OK, you made me laugh (KIWI). You're right, of course. I would just wish to see performance tuning taken a little more seriously. Thanks. – Mike Dunlavey Dec 19 '11 at 15:06
@hakre: "perfect job-machine to produce fat code today and then to un-fat it in 10 years or so". Groan. Some of us could be the ones trying to do the un-fatting. I'm fortunate enough to be at the same employer for over 10 years. The downside is I have to spend a large fraction of time un-fatting old apps. (I like that word.) It's a recipe for hard-boiling profanity. Maybe we coders should have a little sympathy for our brethren and sistren down the road :) – Mike Dunlavey Dec 19 '11 at 15:13
@MikeDunlavey: Well there is some truth in every joke, right? Naturally we always write sparse code as programmers so our apps never grow more than the fat they need to have for running. A well balanced kilobyte code/run ratio. [Ravioli instead of spaghetti code](http://pages.cs.brandeis.edu/~dkw/C-humor/pasta.txt). – hakre Dec 19 '11 at 15:17
@hakre: That is cute, "ravioli code". It used to be called "macaroni code". For better or worse, I survived the black hole of MIT AI Lab, which squeezes the "common wisdom" out of one and looks for cosmic objectives. For me, the minor result was applying information theory to subjects like performance and maintainability. Like when you say we always write sparse code, I say "If Only We Did". But that's a lengthy chat. – Mike Dunlavey Dec 19 '11 at 16:00
Well, I do really Doctrine. Why? Because all the work done was with Doctrine in perspective, Doctrine is not "slow" at execution, but slow down the global execution time by loading a lot of file, I've benchmarked at double speed with APC enabled but it's still not enough. – Trent Dec 19 '11 at 17:36
Sure, then this isn't an option. You didn't wrote which Doctrine 2 version you're using, the manual has some hints: **2.0:** [Performance](http://www.doctrine-project.org/docs/orm/2.0/en/reference/improving-performance.html) / [Caching](http://www.doctrine-project.org/docs/orm/2.0/en/reference/caching.html) **2.1:** [Performance](http://www.doctrine-project.org/docs/orm/2.1/en/reference/improving-performance.html) / [Caching](http://www.doctrine-project.org/docs/orm/2.1/en/reference/caching.html) – hakre Dec 19 '11 at 18:10
Well I know those page, but my performance problem with doctrine are not related to db queries which pretty ok but with the high number of file loaded I actually enabled apc cache for query parser result and it's going better but still... – Trent Dec 20 '11 at 19:14
To me it looks like micro-optimization. – Micromega Jun 17 '12 at 06:02

score 3 · Answer 2 · edited May 23 '17 at 12:27

I'm trying to optimize performance using Xdebug & Webgrind

OK, since you're in a position of seriously needing better performance, you might be open to a less than popular, but demonstrably effective, way to do it.

It works with any language, as long as there's a debugger that can be paused, like Xdebug.

Here it is described in a nutshell. Here's one demonstration of its effectiveness. I can link you many more.

You might find it a little intellectually wrenching. As in

You're finding "bottlenecks" as times associated with routines. The most valuable speedup opportunities often do not manifest that way. They are activities that you could easily describe when you see them, but they are diffuse. They do not concentrate significant time in any particular routine or line of code, so profilers don't see them.
The biggest speedup opportunities may not be at all easy to fix. They may require a re-think of how the program is organized. If you find something you can easily fix, that's great. Go ahead and do it. If it is not so easily fixed, but will still save a lot of time, if you need to save that time, then you've gotta do it, like it or not.

Good luck.

score 1 · Answer 3 · answered Dec 19 '11 at 13:04

I don't like what hakre is suggesting. First off I would look if I can drop the Webserver. If so a good alternative is nginx or lighttpd. Compared to the Apache they are from this century and also the configuration is a lot easier. About the autoloading I don't really know but if the class files a really big did you tried to install a ram disk or use a php compressor? In my experience a PHP compressor can significantly fasten the execution time (i.e. parsing time).

score 0 · Answer 4 · answered Jul 07 '12 at 14:28

I have not too much experience but once I have had such problem. I have checked my include paths and resort them in the order of maximum used library paths. and I have got almost 30% boost. I think it is already known by you but have posted any way ....... :)

Optimize my performance

4 Answers4

Linked