Using Zend Framework for highload projects

问题:

Zend Framework is a good framework but not very fast. Can you tell whether it's worth using Zend Framework for highload projects, for example, for email marketing service that can inlude about ten or houndred thousand of users? Is it possible to achive acceptable performance using Zend Framework? Has anybody such an expirience? Thank you very much.

回答1:

For what I have seen, the definitive defense of Zend Framework performance and recommendations for performance optimization comes from Padraic Brady at:

PHP Framework Benchmarks: Entertaining But Ultimately Useless

In particular, note his four recommendations for performance optimization:

1. Don't use Zend_Application. While Zend_App is great for creating consistent complex bootstraps within a standardised structure, it doesn't come without a significant performance hit to baseline performance. A more direct bootstrap (typical of ZF until Zend_App arrived) is far faster and can also be done without configuration files.

2. Skip using the ViewRenderer plugin. Without the ViewRenderer, you need to manually configure Zend_View and add render() calls to Controllers. This is actually very simple to do and is fairly fast - fast was never really part of the ViewRenderer's genetics.

3. Use autoloading. Strip require_once calls from the framework library so unneeded files are ignored. Replace uses of Zend_Loader_Autoloader with a not-so-crazy autoloader function. In fact, pray Zend_Loader is never used - it does a lot of file ops that, to date, have never been explained to me as having any value.

4. Preload everything (Symfony 2 Preview does!). It buys you some performance cookies and equalises the speed baseline. Using a simple preload script is not that hard.

回答2:

We've used ZF in a lot of high traffic sites, and we've had no issues so far. We did have to jump through a few low-hanging hoops, though.

Some suggestions:

• use Zend_Queue to help with batch mailing
• use Zend_Cache whenever possible
• Use plugin loader cache
• Strip require_once calls in favor of autoloading
• Get rid of components you don't want. (as suggested, you would not need MVC stack for CLI / mail)
• We chose Sphinx in favor of Zend_Search_Lucene (enormous performance gain)

The bottom line for us has been this: development time is much, much more expensive than hardware. The flexiblity and higher re-use of code completely trumps any minor performance losses we had to deal with. For the most part, the performance overhead was very fixed.

回答3:

You ask:

Is it possible to achive acceptable performance using Zend Framework? Has anybody such an expirience?

Yes, I have experience with a site with millions of users. But you do need to use techniques to deal with the high load. Caching etc...

A CDN can help a lot. Look into developing with the cloud. Amazon might be a pain to get started with but it helps you scale if need be.

I guess what I'm saying is, the Framework may cost you a bit of performance, but helps make maintenance possible and building it faster (once you get over the learning curve). Then you you have to evaluate what needs to be done to improve performance (although it helps a lot to plan for what will be obvious problems, right from the get go).

回答4:

I know of several companies that use ZF in high-performance/high-load scenarios. I don't know which ones I can state and which ones I can't, but some of them are media companies who have to handle popular TV shows. Others handle live sporting events. Others are multi-billion dollar companies who need to serve their internal organizations. So, ZF is being used by plenty of companies who run pretty high-load sites. One of our case studies is Fox Interactive (http://framework.zend.com/about/casestudies) and I know of several other customers who use it for high-performance websites.

Zend Framework MVC, out of the box, will be quite fast. My blog comes back in about 100ms without caching and there's a fair amount of stuff that happens on my front page. I could probably drop that down to 50ms with some internal caching (Full page caching could drop it down to single digit ms, but then it's not touching ZF).

回答5:

Seconding Joe's answer. I've also seen ZF deployed on a few sites handling millions of requests and have yet to encounter a problem. When dealing with that amount of traffic it's a good idea to use other strategies beyond your framework, including but not limited to caching and the use of a CDN.

I've found most frameworks will call or create many class instances per request which I think is what causes people to say that framework X is slow without having any real world experience with it. Any hit you take there can be easily mitigated by using an accelerator and caching.

If you already have a team of devs you've hired, I'd suggest using what they feel most comfortable with and have the most experience with. Best case they'll be able to tune their code for that framework.

回答6:

A lot of the framework, any framework really, is used for building and managing the project development but the resulting project is 'just' php, html, css etc. the same as any other php web site. So what evidence do you have, that's real timing against other framework and non-framework built sites not anecdotal evidence, that a Zend project site is slow.

Edit -- answers to below -- I don't think the structure that the framework uses will hurt performance. It may be more a question of PHP being acceptable and then how much 'overhead' is added with the site design and the optimisation of loading say JavaScript's etc. I would imagine that using the Yui guidelines of minifying JavaScript and CSS and loading them in the correct order and making sure the PHP code is efficient will help. You can also use other standard things such as DB Caching and Zend Accelerator will speed things up. One thing to be careful of would be the DB connection. The use of an ORM layer might have an impact.

However back to the original question about the framework i think it is similar to asking if using Eclipse or Textmate has an effect on the speed of the resulting site.