Im running php under fastcgi on IIS6 (don't have a choice in the matter) with Zend FW 1.9. I don't have apc or memcache installed though I do have full control of the server. Testing on ZendServer CE over the last few days (which does have APC along with Zend Optimizer) however didn't improve the results and I had to actually remove it due to issues getting it to work with MSSQL (again, out of my hands).

Another site (our current sites dev version) running on the exact same server although writtin in asp 2.0 results in....

I'm aware that PHP under fastCGI is going to take a performance hit and that ZendFW is going to add yet more overhead but this is the first time Iv'e bothered to benchmark any of my ZendFW sites and to be honest, this is ridiculous. this application will be expected to respond to 30,000+ hits / day, and I'm just not sure where to go from here.

Any ideas what could be done to speed up the boostrap process? Really quite desperate for some advice here as I'm about two months into this project and dropping zend at this stage is pretty well out of the question.

Share this post

Link to post

Share on other sites

Zend has a bad reputation for being slow. Sorry to hear you have done so much work already. I'd guess that you have more experience than most people who come here, so the chances of a miracle/answer are very low at best.

Share this post

Link to post

Share on other sites

So far you've profiled your application externally measuring its run entirety, how about you try running it through a debugger and profiling the application internals. Perhaps that path will lead you to your answer.

Share this post

Link to post

Share on other sites

One of the main reasons that Zend Framework is slow is the fact of using include_path. It is one of the worst solutions for including files, especially if the list of available paths is longer. This is what PHP does when it has to execute include('foo.php') file, having five paths in the list:

1. Check if the file exists under the first location (disk operation - slow!). If not, go to step 2.

2. Check if the file exists under the second location (another disk operation). If not, go to step 3.

3. Check if the file exists under the third location... and so on until it will find a file.

If the most commonly used paths are provided at the end of the list, your application wastes lots of time to search the files in different locations. Unfortunately, using include_paths is hard-coded in Zend Framework (many files are included manually), so the smarter autoloader will not help much. Remember that every single disk operation costs a lot, because the disk access is quite slow. You should try to minimize the number of them.

Actually, I'm against using include_paths in any form in a production software, but if you already have an application, there is little you can do...

Share this post

Link to post

Share on other sites

Usually include_paths are much longer. Anyway, it is still include_path, especially for the files from the second group. Why are you using it, if you have the new, smarter ZF autoloader? Try to configure it without include_path - it should help a bit.

I've noticed now that your code performs some disk operations twice. For example:

Now, APPLICATION_PATH is realpathed, but a couple of lines later you do:

require_once realpath(APPLICATION_PATH . '/bootstrap/Setup.php');

realpath() again on a path that is already absolute. And later, when configuring include_paths - another. These just two lines are not so critical, but I haven't seen the rest of your code. Maybe there are much more such unnecessary disk (and other stuff) calls in your application and the sum of them gives you a very bad exectution times?

Share this post

Link to post

Share on other sites

Yeah. I minimised the path as much as I could. This project needs nothing but the Zend framework and my own libraries (and extensions to ZF) contained within C:\Inetpub\sites\phpdev\application\library

I've noticed now that your code performs some disk operations twice. For example:

Now, APPLICATION_PATH is realpathed, but a couple of lines later you do:

require_once realpath(APPLICATION_PATH . '/bootstrap/Setup.php');

realpath() again on a path that is already absolute. And later, when configuring include_paths - another. These just two lines are not so critical, but I haven't seen the rest of your code. Maybe there are much more such unnecessary disk (and other stuff) calls in your application and the sum of them gives you a very bad exectution times?

I'll fix those up, but these are the only places that require and the like are called. I'm not sure what you mean by....

Anyway, it is still include_path, especially for the files from the second group. Why are you using it, if you have the new, smarter ZF autoloader? Try to configure it without include_path - it should help a bit

Surely the necessary libraries need to be on my path somewhere.

Share this post

Link to post

Share on other sites

This may sound stupid, but are you running an opcode cache like APC? Are you caching things using Zend_Cache? If yes, do you use the filesystem as backend, or something that stores it in memory like APC or memcached?

Share this post

Link to post

Share on other sites

To be honest, I had allot of trouble getting apc running within IIS. Never tried memcache.

As you can see however, even without actually getting to my application, just bootstraping acl via Zend_Application completely killed performance.

I have been granted an extension to have this application finished by Febuary, in doing so have decided that Zend simply isn't going to perform well enough to be relied upon and I am now part way through rolling my own (much more minimal) mvc. I really loved the framework but the numbers simply don't stack up.

Share this post

Link to post

Share on other sites

It sounds weird. The numbers I get for PHP Freaks are not even near the numbers you get, and that is for the entire application, not just the bootstrapping process. I'll try to profile our code some time and see where the bottlenecks are here.