Hello. 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.
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.
This topic is discussed many times on SO.
Why should you use a framework. Here are some discussions :
- Why you should be using a framework
- Should I use a PHP Framework? If so, which one? - Stackoverflow
- Why should I use an MVC framework for PHP? - Stackoverflow
Comparisons between some frameworks:
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).
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).
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.
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.
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:
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.
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.
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.
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.
Most of the framework are not a overhead for the site. Having more classes does NOT slow down the application. Zend Framework is used for very high traffic applications and if used correctly does NOT slow down at all. That can be difficult to understand, but its' true. PHP interpreter is very smart and the difference is question of milliseconds, especially when there is a optimizer extension of PHP (see XCache/APC, zend optimizer).
The real bottleneck of web applications is a bad design. For high-traffic application, use Cache for database data, memcache for frequent data and other techniques.
To increase the performance, cache the bootstrap:
<?php
require_once 'Zend/Application.php';
class My_Application extends Zend_Application
{
/**
* Flag used when determining if we should cache our configuration.
*/
protected $_cacheConfig = false;
/**
* Our default options which will use File caching
*/
protected $_cacheOptions = array(
'frontendType' => 'File',
'backendType' => 'File',
'frontendOptions' => array(),
'backendOptions' => array()
);
/**
* Constructor
*
* Initialize application. Potentially initializes include_paths, PHP
* settings, and bootstrap class.
*
* When $options is an array with a key of configFile, this will tell the
* class to cache the configuration using the default options or cacheOptions
* passed in.
*
* @param string $environment
* @param string|array|Zend_Config $options String path to configuration file, or array/Zend_Config of configuration options
* @throws Zend_Application_Exception When invalid options are provided
* @return void
*/
public function __construct($environment, $options = null)
{
if (is_array($options) && isset($options['configFile'])) {
$this->_cacheConfig = true;
// First, let's check to see if there are any cache options
if (isset($options['cacheOptions']))
$this->_cacheOptions =
array_merge($this->_cacheOptions, $options['cacheOptions']);
$options = $options['configFile'];
}
parent::__construct($environment, $options);
}
/**
* Load configuration file of options.
*
* Optionally will cache the configuration.
*
* @param string $file
* @throws Zend_Application_Exception When invalid configuration file is provided
* @return array
*/
protected function _loadConfig($file)
{
if (!$this->_cacheConfig)
return parent::_loadConfig($file);
require_once 'Zend/Cache.php';
$cache = Zend_Cache::factory(
$this->_cacheOptions['frontendType'],
$this->_cacheOptions['backendType'],
array_merge(array( // Frontend Default Options
'master_file' => $file,
'automatic_serialization' => true
), $this->_cacheOptions['frontendOptions']),
array_merge(array( // Backend Default Options
'cache_dir' => APPLICATION_PATH . '/data/cache'
), $this->_cacheOptions['backendOptions'])
);
$config = $cache->load('Zend_Application_Config');
if (!$config) {
$config = parent::_loadConfig($file);
$cache->save($config, 'Zend_Application_Config');
}
return $config;
}
}
Make sure you create the directory: application/data/cache
Change your index.php to:
<?php
// Define path to application directory
defined('APPLICATION_PATH')
|| define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/../application'));
// Define application environment
defined('APPLICATION_ENV')
|| define('APPLICATION_ENV', (getenv('APPLICATION_ENV') ? getenv('APPLICATION_ENV') : 'production'));
// Ensure library/ is on include_path
set_include_path(implode(PATH_SEPARATOR, array(
realpath(APPLICATION_PATH . '/../library'),
get_include_path(),
)));
/** My_Application */
require_once 'My/Application.php';
// Create application, bootstrap, and run
$application = new My_Application(
APPLICATION_ENV,
array(
'configFile' => APPLICATION_PATH . '/configs/application.ini'
)
);
$application->bootstrap()
->run();