Chapter 18 - Performance

If you expect your website will attract a crowd, performance and optimization issues should be a major factor during the development phase. Rest assured, performance has always been a chief concern among the core symfony developers.

While the advantages gained by accelerating the development process result in some overhead, the core symfony developers have always been cognizant of performance requirements. Accordingly, every class and every method have been closely inspected and optimized to be as fast as possible. The basic overhead, which you can measure by comparing the time to display a "hello, world" message with and without symfony, is minimal. As a result, the framework is scalable and reacts well to stress tests. And as the ultimate proof, some websites with extremely high traffic (that is, websites with millions of active subscribers and a lot of server-pressuring Ajax interactions) use symfony and are very satisfied with its performance. Check the list of websites developed with symfony in the wiki (http://trac.symfony-project.org/wiki/ApplicationsDevelopedWithSymfony) for names.

But, of course, high-traffic websites often have the means to expand the server farm and upgrade hardware as they see fit. If you don't have the resources to do this, or if you want to be sure the full power of the framework is always at your disposal, there are a few tweaks that you can use to further speed up your symfony application. This chapter lists some of the recommended performance optimizations at all levels of the framework and they are mostly for advanced users. Some of them were already mentioned throughout the previous chapters, but you will find it useful to have them all in one place.

Tweaking the Server

A well-optimized application should rely on a well-optimized server. You should know the basics of server performance to make sure there is no bottleneck outside symfony. Here are a few things to check to make sure that your server isn't unnecessarily slow.

Having magic_quotes_gpc turned on in the php.ini slows down an application, because it tells PHP to escape all quotes in request parameters, but symfony will systematically unescape them afterwards, and the only consequence will be a loss of time--and quotes-escaping problems on some platforms. Therefore, turn this setting off if you have access to the PHP configuration.

The more recent PHP release you use, the better. PHP 5.2 is faster than PHP 5.1, and PHP 5.1 is a lot faster than PHP 5.0. So make sure you upgrade your PHP version to benefit from the latest performance improvements.

The use of a PHP accelerator (such as APC, XCache, or eAccelerator) is almost compulsory for a production server, because it can make PHP run an average 50% faster, with no tradeoff. Make sure you install one of the accelerator extensions to feel the real speed of PHP.

On the other hand, make sure you deactivate any debug utility, such as the Xdebug or APD extension, in your production server.

Some symfony developers like to use syck, which is a YAML parser packaged as a PHP extension, as an alternative to the symfony internal parser. It is faster, but symfony's caching system already minimizes the overhead of YAML parsing, so the benefit is nonexistent in a production environment. You should also be aware that syck isn't completely mature yet, and that it may cause errors when you use it. However, if you are interested, install the extension (http://whytheluckystiff.net/syck/), and symfony will use it automatically.

Tweaking the Model

In symfony, the model layer has the reputation of being the slowest part. If benchmarks show that you have to optimize this layer, here are a few possible improvements.

Optimizing Propel Integration

Initializing the model layer (the core Propel classes) takes some time, because of the need to load a few classes and construct various objects. However, because of the way symfony integrates Propel, these initialization tasks occur only when an action actually needs the model--and as late as possible. The Propel classes will be initialized only when an object of your generated model is autoloaded. This means pages that don't use the model are not penalized by the model layer.

If your entire application doesn't require the use of the model layer, you can also save the initialization of the sfDatabaseManager by switching the whole layer off in your settings.yml:

all:
  .settings:
    use_database: off

The generated model classes (in lib/model/om/) are already optimized--they don't contain comments, and they benefit from the autoloading system. Relying on autoloading instead of manually including files means that classes are loaded only if it is really necessary. So in case one model class is not needed, having classes autoloaded will save execution time, while the alternative method of using include statements won't. As for the comments, they document the use of the generated methods but lengthen the model files--resulting in a minor overhead on slow disks. As the generated method names are pretty explicit, the comments are turned off by default.

These two enhancements are symfony-specific, but you can revert to the Propel defaults by changing two settings in your propel.ini file, as follows:

propel.builder.addIncludes = true   # Add include statements in generated classes
                                    # Instead of relying on the autoloading system
propel.builder.addComments = true   # Add comments to generated classes

Limiting the Number of Objects to Hydrate

When you use a method of a peer class to retrieve objects, your query goes through the hydrating process (creating and populating objects based on the rows of the result of the query). For instance, to retrieve all the rows of the article table with Propel, you usually do the following:

$articles = ArticlePeer::doSelect(new Criteria());

The resulting $articles variable is an array of objects of class Article. Each object has to be created and initialized, which takes time. This has one major consequence: Contrary to direct database queries, the speed of a Propel query is directly proportional to the number of results it returns. This means your model methods should be optimized to return only a given number of results. When you don't need all the results returned by a Criteria, you should limit it with the setLimit() and setOffset() methods. For instance, if you need only the rows 10 to 20 of a particular query, refine the Criteria as in Listing 18-1.

Listing 18-1 - Limiting the Number of Results Returned by a Criteria

$c = new Criteria();
$c->setOffset(10);  // Offset of the first record returned
$c->setLimit(10);   // Number of records returned
$articles = ArticlePeer::doSelect($c);

This can be automated by the use of a pager. The sfPropelPager object automatically handles the offset and the limit of a Propel query to hydrate only the objects required for a given page. Refer to the pager documentation for more information on this class.

Minimizing the Number of Queries with Joins

During application development, you should keep an eye on the number of database queries issued by each request. The web debug toolbar shows the number of queries for each page, and clicking the little database icon reveals the SQL code of these queries. If you see the number of queries rising abnormally, it is time to consider using a Join.

Before explaining the Join methods, let's review what happens when you loop over an array of objects and use a Propel getter to retrieve details about a related class, as in Listing 18-2. This example supposes that your schema describes an article table with a foreign key to an author table.

Listing 18-2 - Retrieving Details About a Related Class in a Loop

// In the action
$this->articles = ArticlePeer::doSelect(new Criteria());
 
// Database query issued by doSelect()
SELECT article.id, article.title, article.author_id, ...
FROM   article
 
// In the template
<ul>
<?php foreach ($articles as $article): ?>
  <li><?php echo $article->getTitle() ?>,
    written by <?php echo $article->getAuthor()->getName() ?></li>
<?php endforeach; ?>
</ul>

If the $articles array contains ten objects, the getAuthor() method will be called ten times, which in turn executes one database query each time it is called to hydrate one object of class Author, as in Listing 18-3.

Listing 18-3 - Foreign Key Getters Issue One Database Query

// In the template
$article->getAuthor()
 
// Database query issued by getAuthor()
SELECT author.id, author.name, ...
FROM   author
WHERE  author.id = ?                // ? is article.author_id

So the page of Listing 18-2 will require a total of 11 queries: the one necessary to build the array of Article objects, plus the 10 queries to build one Author object at a time. This is a lot of queries to display only a list of articles and their author.

If you were using plain SQL, you would know how to reduce the number of queries to only one by retrieving the columns of the article table and those of the author table in the same query. That's exactly what the doSelectJoinAuthor() method of the ArticlePeer class does. It issues a slightly more complex query than a simple doSelect() call, but the additional columns in the result set allow Propel to hydrate both Article objects and the related Author objects. The code of Listing 18-4 displays exactly the same result as Listing 18-2, but it requires only one database query to do so rather than 11 and therefore is faster.

Listing 18-4 - Retrieving Details About Articles and Their Author in the Same Query

// In the action
$this->articles = ArticlePeer::doSelectJoinAuthor(new Criteria());
 
// Database query issued by doSelectJoinAuthor()
SELECT article.id, article.title, article.author_id, ...
       author.id, author.name, ...
FROM   article, author
WHERE  article.author_id = author.id
 
// In the template (unchanged)
<ul>
<?php foreach ($articles as $article): ?>
  <li><?php echo $article->getTitle() ?>,
    written by <?php echo $article->getAuthor()->getName() ?></li>
<?php endforeach; ?>
</ul>

There is no difference in the result returned by a doSelect() call and a doSelectJoinXXX() method; they both return the same array of objects (of class Article in the example). The difference appears when a foreign key getter is used on these objects afterwards. In the case of doSelect(), it issues a query, and one object is hydrated with the result; in the case of doSelectJoinXXX(), the foreign object already exists and no query is required, and the process is much faster. So if you know that you will need related objects, call a doSelectJoinXXX() method to reduce the number of database queries--and improve the page performance.

The doSelectJoinAuthor() method is automatically generated when you call a propel-build-model because of the relationship between the article and author tables. If there were other foreign keys in the article table structure--for instance, to a category table--the generated BaseArticlePeer class would have other Join methods, as shown in Listing 18-5.

Listing 18-5 - Example of Available doSelect Methods for an ArticlePeer Class

// Retrieve Article objects
doSelect()
 
// Retrieve Article objects and hydrate related Author objects
doSelectJoinAuthor()
 
// Retrieve Article objects and hydrate related Category objects
doSelectJoinCategory()
 
// Retrieve Article objects and hydrate related objects except Author
doSelectJoinAllExceptAuthor()
 
// Synonym of
doSelectJoinAll()

The peer classes also contain Join methods for doCount(). The classes with an i18n counterpart (see Chapter 13) provide a doSelectWithI18n() method, which behaves the same as Join methods but for i18n objects. To discover the available Join methods in your model classes, you should inspect the generated peer classes in lib/model/om/. If you don't find the Join method needed for your query (for instance, there is no automatically generated Join method for many-to-many relationships), you can build it yourself and extend your model.

Avoid Using Temporary Arrays

When using Propel, objects are already hydrated, so there is no need to prepare a temporary array for the template. Developers not used to ORMs usually fall into this trap. They want to prepare an array of strings or integers, whereas the template can rely directly on an existing array of objects. For instance, imagine that a template displays the list of all the titles of the articles present in the database. A developer who doesn't use OOP would probably write code similar to what is shown in Listing 18-6.

Listing 18-6 - Preparing an Array in the Action Is Useless If You Already Have One

// In the action
$articles = ArticlePeer::doSelect(new Criteria());
$titles = array();
foreach ($articles as $article)
{
  $titles[] = $article->getTitle();
}
$this->titles = $titles;
 
// In the template
<ul>
<?php foreach ($titles as $title): ?>
  <li><?php echo $title ?></li>
<?php endforeach; ?>
</ul>

The problem with this code is that the hydrating is already done by the doSelect() call (which takes time), making the $titles array superfluous, since you can write the same code as in Listing 18-7. So the time spent to build the $titles array could be gained to improve the application performance.

Listing 18-7 - Using an Array of Objects Exempts You from Creating a Temporary Array

// In the action
$this->articles = ArticlePeer::doSelect(new Criteria());
 
// In the template
<ul>
<?php foreach ($articles as $article): ?>
  <li><?php echo $article->getTitle() ?></li>
<?php endforeach; ?>
</ul>

If you feel that you really need to prepare a temporary array because some processing is necessary on objects, the right way to do so is to create a new method in your model class that directly returns this array. For instance, if you need an array of article titles and the number of comments for each article, the action and the template should look like Listing 18-8.

Listing 18-8 - Using a Custom Method to Prepare a Temporary Array

// In the action
$this->articles = ArticlePeer::getArticleTitlesWithNbComments();
 
// In the template
<ul>
<?php foreach ($articles as $article): ?>
  <li><?php echo $article[0] ?> (<?php echo $article[1] ?> comments)</li>
<?php endforeach; ?>
</ul>

It's up to you to build a fast-processing getArticleTitlesWithNbComments() method in the model--for instance, by bypassing the whole object-relational mapping and database abstraction layers.

Bypassing the ORM

When you don't really need objects but only a few columns from various tables, as in the previous example, you can create specific methods in your model that bypass completely the ORM layer. You can directly call the database with Creole, for instance, and return a custom-built array. Listing 18-9 illustrates this idea.

Listing 18-9 - Using Direct Creole Access for Optimized Model Methods, in lib/model/ArticlePeer.php

class ArticlePeer extends BaseArticlePeer
{
  public static function getArticleTitlesWithNbComments()
  {
    $connection = Propel::getConnection();
    $query = 'SELECT %s as title, COUNT(%s) AS nb FROM %s LEFT JOIN %s ON %s = %sGROUP BY %s';
    $query = sprintf($query,
      ArticlePeer::TITLE, CommentPeer::ID,
      ArticlePeer::TABLE_NAME, CommentPeer::TABLE_NAME,
      ArticlePeer::ID, CommentPeer::ARTICLE_ID,
      ArticlePeer::ID
    );
    $statement = $connection->prepareStatement($query);
    $resultset = $statement->executeQuery();
    $results = array();
    while ($resultset->next())
    {
      $results[] = array($resultset->getString('title'), $resultset->getInt('nb'));
    }
 
    return $results;
  }
}

When you start building these sorts of methods, you may end up writing one custom method for each action, and lose the benefit of the layer separation--not to mention the fact that you lose database-independence.

Speeding Up the Database

There are many database-specific optimization techniques that can be applied regardless of whether you're using symfony. This section briefly outlines the most common database optimization strategies, but a good knowledge of database engines and administration is required to get the most out of your model layer.

Table queries are often based on non-primary key columns. To improve the speed of such queries, you should define indexes in your database schema. To add a single column index, add the index: true property to the column definition, as in Listing 18-10.

Listing 18-10 - Adding a Single Column Index, in config/schema.yml

propel:
  article:
    id:
    author_id:
    title: { type: varchar(100), index: true }

You can use the alternative index: unique syntax to define a unique index instead of a classic one. You can also define multiple column indices in schema.yml (refer to Chapter 8 for more details about the indexing syntax). You should strongly consider doing this, because it is often a good way to speed up a complex query.

After adding an index to a schema, you should do the same in the database itself, either by issuing an ADD INDEX query directly in the database or by calling the propel-build-all command (which will not only rebuild the table structure, but also erase all the existing data).

Unless specified otherwise, each request uses a single database connection in symfony, and the connection is closed at the end of the request. You can enable persistent database connections to use a pool of database connections that remain open between queries, by setting persistent: true in the databases.yml file, as shown in Listing 18-11.

Listing 18-11 - Enabling Persistent Database Connection Support, in config/databases.yml

prod:
  propel:
    class:          sfPropelDatabase
    param:
      persistent:   true
      dsn:          mysql://login:passwd@localhost/blog

This may or may not improve the overall database performance, depending on numerous factors. The documentation on the subject is abundant on the Internet. Make sure you benchmark your application performance before and after changing this setting to validate its interest.

Tweaking the View

According to how you design and implement the view layer, you may notice small slowdowns or speedups. This section describes the alternatives and their tradeoffs.

Using the Fastest Code Fragment

If you don't use the caching system, you have to be aware that an include_component() is slightly slower than an include_partial(), which itself is slightly slower than a simple PHP include. This is because symfony instantiates a view to include a partial and an object of class sfComponent to include a component, which collectively add some minor overhead beyond what's required to include the file.

However, this overhead is insignificant, unless you include a lot of partials or components in a template. This may happen in lists or tables, and every time you call an include_partial() helper inside a foreach statement. When you notice that a large number of partial or component inclusions have a significant impact on your performance, you may consider caching (see Chapter 12), and if caching is not an option, then switch to simple include statements.

As for slots and component slots, the difference in performance is perceptible. The process time necessary to set and include a slot is negligible--it is equivalent to a variable instantiation. But component slots rely on a view configuration, and they require a few objects to be initiated to work. However, component slots can be cached independently from the calling templates, while slots are always cached within the template that includes them.

Speeding Up the Routing Process

As explained in Chapter 9, every call to a link helper in a template asks the routing system to process an internal URI into an external URL. This is done by finding a match between the URI and the patterns of the routing.yml file. Symfony does it quite simply: It tries to match the first rule with the given URI, and if it doesn't work, it tries with the following, and so on. As every test involves regular expressions, this is quite time consuming.

There is a simple workaround: Use the rule name instead of the module/action couple. This will tell symfony which rule to use, and the routing system won't lose time trying to match all previous rules.

In concrete terms, consider the following routing rule, defined in your routing.yml file:

article_by_id:
  url:          /article/:id
  param:        { module: article, action: read }

Then instead of outputting a hyperlink this way:

<?php echo link_to('my article', 'article/read?id='.$article->getId()) ?>

you should use the fastest version:

<?php echo link_to('my article', '@article_by_id?id='.$article->getId()) ?>

The difference starts being noticeable when a page includes a few dozen routed hyperlinks.

Skipping the Template

Usually, a response is composed of a set of headers and content. But some responses don't need content. For instance, some Ajax interactions need only a few pieces of data from the server in order to feed a JavaScript program that will update different parts of the page. For this kind of short response, a set of headers alone is faster to transmit. As discussed in Chapter 11, an action can return only a JSON header. Listing 18-12 reproduces an example from Chapter 11.

Listing 18-12 - Example Action Returning a JSON Header

public function executeRefresh()
{
  $output = '{"title":"My basic letter","name":"Mr Brown"}';
  $this->getResponse()->setHttpHeader("X-JSON", '('.$output.')');
 
  return sfView::HEADER_ONLY;
}

This skips the template and the layout, and the response can be sent at once. As it contains only headers, it is more lightweight and will take less time to transmit to the user.

Chapter 6 explained another way to skip the template by returning content text directly from the action. This breaks the MVC separation, but it can increase the responsiveness of an action greatly. Check Listing 18-13 for an example.

Listing 18-13 - Example Action Returning Content Text Directly

public function executeFastAction()
{
  return $this->renderText("<html><body>Hello, World!</body></html>");
}

Restricting the Default Helpers

The standard helper groups (Partial, Cache, and Form) are loaded for every request. If you are sure that you won't use some of them, removing a helper group from the list of standard ones will save you the parsing of the helper file. In particular, the Form helper group, although included by default, is quite heavy and slows down pages with no forms just because of its size. So it might be a good idea to edit the standard_helpers setting in the settings.yml file to remove it:

all:
  .settings:
    standard_helpers: [Partial, Cache]    # Form is removed

The tradeoff is that you must declare the Form helper group on each template using it with use_helper('Form').

Compressing the Response

Symfony compresses the response before sending it to the user. This feature is based on the PHP zlib module. You can save a little CPU time for each request by deactivating it in the settings.yml file:

all:
  .settings:
    compressed: off

Be aware that the CPU gain will be balanced by the bandwidth loss, so the performance won't increase in all configurations with this change.

Tweaking the Cache

Chapter 12 already described how to cache parts of a response or all of it. The response cache results in a major performance improvement, and it should be one of your first optimization considerations. If you want to make the most out of the cache system, read further, for this section unveils a few tricks you might not have thought of.

Clearing Selective Parts of the Cache

During application development, you have to clear the cache in various situations:

• When you create a new class: Adding a class to an autoloading directory (one of the project's lib/ folders) is not enough to have symfony find it automatically. You must clear the autoloading configuration cache so that symfony browses again all the directories of the autoload.yml file and references the location of autoloadable classes--including the new ones.
• When you change the configuration in production: The configuration is parsed only during the first request in production. Further requests use the cached version instead. So a change in the configuration in the production environment (or any environment where SF_DEBUG is turned off) doesn't take effect until you clear the cached version of the file.
• When you modify a template in an environment where the template cache is enabled: The valid cached templates are always used instead of existing templates in production, so a template change is ignored until the template cache is cleared or outdated.
• When you update an application with the sync command: This case usually covers the three previous modifications.

The problem with clearing the whole cache is that the next request will take quite long to process, because the configuration cache needs to be regenerated. Besides, the templates that were not modified will be cleared from the cache as well, losing the benefit of previous requests.

That means it's a good idea to clear only the cache files that really need to be regenerated. Use the options of the clear-cache task to define a subset of cache files to clear, as demonstrated in Listing 18-14.

Listing 18-14 - Clearing Only Selective Parts of the Cache

// Clear only the cache of the myapp application
> symfony clear-cache myapp

// Clear only the HTML cache of the myapp application
> symfony clear-cache myapp template

// Clear only the configuration cache of the myapp application
> symfony clear-cache myapp config

You can also remove files by hand in the cache/ directory, or clear template cache files selectively from the action with the $cacheManager->remove() method, as described in Chapter 12.

All these techniques will minimize the negative performance impact of any of the changes listed previously.

Generating Cached Pages

When you deploy a new application to production, the template cache is empty. You must wait for users to visit a page once for this page to be put in the cache. In critical deployments, the overhead of page processing is not acceptable, and the benefits of caching must be available as soon as the first request is issued.

The solution is to automatically browse the pages of your application in the staging environment (where the configuration is similar to the one in production) to have the template cache generated, then to transfer the application with the cache to production.

To browse the pages automatically, one option is to create a shell script that looks through a list of external URLs with a browser (curl for instance). But there is a better and faster solution: a symfony batch using the sfBrowser object, already discussed in Chapter 15. That's an internal browser written in PHP (and used by sfTestBrowser for functional tests). It takes an external URL and returns a response, but the interesting thing is that it triggers the template cache just like a regular browser. As it only initializes symfony once and doesn't pass by the HTTP transport layer, this method is a lot faster.

Listing 18-15 shows an example batch script used to generate template cache files in a staging environment. Launch it by calling php batch/generate_cache.php.

Listing 18-15 - Generating the Template Cache, in batch/generate_cache.php

<?php
 
define('SF_ROOT_DIR',    realpath(dirname(__FILE__).'/..'));
define('SF_APP',         'myapp');
define('SF_ENVIRONMENT', 'staging');
define('SF_DEBUG',       false);
 
require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');
 
// Array of URLs to browse
$uris = array(
  '/foo/index',
  '/foo/bar/id/1',
  '/foo/bar/id/2',
  ...
);
 
$b = new sfBrowser();
foreach ($uris as $uri)
{
  $b->get($uri);
}

Using a Database Storage System for Caching

The default storage system for the template cache in symfony is the file system: Fragments of HTML or serialized response objects are stored under the cache/ directory of a project. Symfony proposes an alternative way to store cache: a SQLite database. Such a database is a simple file that PHP natively knows how to query very efficiently.

To tell symfony to use SQLite storage instead of file system storage for the template cache, open the factories.yml file and edit the view_cache entry as follows:

view_cache:
  class: sfSQLiteCache
  param:
    database: %SF_TEMPLATE_CACHE_DIR%/cache.db

The benefits of using SQLite storage for the template cache are faster read and write operations when the number of cache elements is important. If your application makes heavy use of caching, the template cache files end up scattered in a deep file structure; in this case, switching to SQLite storage will increase performance. In addition, clearing the cache on file system storage may require a lot of files to be removed from the disk; this operation may last a few seconds, during which your application is unavailable. With a SQLite storage system, the cache clearing process results in a single file operation: the deletion of the SQLite database file. Whatever the number of cache elements currently stored, the operation is instantaneous.

Bypassing Symfony

Perhaps the best way to speed symfony up is to bypass it completely . . . this is said only partly in jest. Some pages don't change and don't need to be reprocessed by the framework at each request. The template cache is already here to speed up the delivery of such pages, but it still relies on symfony.

A couple of tricks described in Chapter 12 allow you to bypass symfony completely for some pages. The first one involves the use of HTTP 1.1 headers for asking the proxies and client browsers to cache the page themselves, so that they don't request it again the next time the page is needed. The second one is the super fast cache (automated by the sfSuperCachePlugin plug-in), which consists of storing a copy of the response in the web/ directory and modifying the rewriting rules so that Apache first looks for a cached version before handing a request to symfony.

Both these methods are very effective, and even if they only apply to static pages, they will take the burden of handling these pages off from symfony, and the server will then be fully available to deal with complex requests.

Caching the Result of a Function Call

If a function doesn't rely on context-sensitive values nor on randomness, calling it twice with the same parameters should return the same result. That means the second call could very well be avoided if the result had been stored the first time. That's exactly what the sfFunctionCache class does. This class has a call() method, which expects a callable and a set of parameters. When called, this method creates an md5 hash with all its arguments and looks in the cache directory for a file named by this hash. If such a file is found, the function returns the result stored in the file. If not, the sfFunctionCache executes the function, stores the result in the cache, and returns it. So the second execution of Listing 18-16 will be faster than the first one.

Listing 18-16 - Caching the Result of a Function

$function_cache_dir = sfConfig::get('sf_cache_dir').'/function';
$fc = new sfFunctionCache($function_cache_dir);
$result1 = $fc->call('cos', M_PI);
$result2 = $fc->call('preg_replace', '/\s\s+/', ' ', $input);

The sfFunctionCache constructor expects an absolute directory path as argument (the directory must exist prior to the object instantiation). The first argument of the call() method must be a callable, so it can be a function name, an array of a class name and static method name, or an array of an object name and public method name. As for the other arguments of the call() method, you can include as many as you need--they are all handed to the callable.

This object is especially useful for CPU-intensive functions, because the file I/O overhead exceeds the time required to process a simple function. It relies on the sfFileCache class, which is the component also used by the symfony template cache engine. Refer to the API documentation for more details.

Caching Data in the Server

PHP accelerators provide special functions to store data in memory so that you can reuse it across requests. The problem is that they all have a different syntax, and each has its own specific way of performing this task. Symfony provides a class called sfProcessCache, which abstracts all these differences and works with whatever accelerator you are using. See its syntax in Listing 18-17.

Listing 18-17 - Syntax of the sfProcessCache Methods

// Storing data in the process cache
sfProcessCache::set($name, $value, $lifetime);
 
// Retrieving data
$value = sfProcessCache::get($name);
 
// Checking if a piece of data exists in the process cache
$value_exists = sfProcessCache::has($name);
 
// Clear the process cache
sfProcessCache::clear();

The set() method returns false if the caching didn't work. The cached value can be anything (a string, an array, an object); the sfProcessCache class will deal with the serialization. The get() method returns null if the required variable doesn't exist in the cache.

The methods of the sfProcessCache class work even if no accelerator is installed. Therefore, there is no risk in trying to retrieve data from the process cache, as long as you provide a fallback value. For instance, Listing 18-18 shows how to retrieve a configuration setting in the process cache.

Listing 18-18 - Using the Process Cache Safely

if (sfProcessCache::has('myapp_parameters'))
{
  $params = sfProcessCache::get('myapp_parameters');
}
else
{
  $params = retrieve_parameters();
}

Deactivating the Unused Features

The default symfony configuration activates the most common features of a web application. However, if you happen to not need all of them, you should deactivate them to save the time their initialization takes on each request.

For instance, if your application doesn't use the session mechanism, or if you want to start the session handling by hand, you should turn the auto_start setting to false in the storage key of the factories.yml file, as in Listing 18-19.

Listing 18-19 - Turning Sessions Off, in myapp/config/factories.yml

all:
  storage:
    class: sfSessionStorage
    param:
      auto_start: false

The same applies for the database (as explained in the "Tweaking the Model" section earlier in this chapter) and output escaping feature (see Chapter 7). If your application makes no use of them, deactivate them for a small performance gain, this time in the settings.yml file (see Listing 18-20).

Listing 18-20 - Turning Features Off, in myapp/config/settings.yml

all:
  .settings:
    use_database:      off    # Database and model features
    escaping_strategy: off    # Output escaping feature

As for the security and the flash attribute features (see Chapter 6), you can deactivate them in the filters.yml file, as shown in Listing 18-21.

Listing 18-21 - Turning Features Off, in myapp/config/filters.yml

rendering: ~
web_debug: ~
security:
  enabled: off

# generally, you will want to insert your own filters here

cache:     ~
common:    ~
flash:
  enabled: off

execution: ~

Some features are useful only in development, so you should not activate them in production. This is already the case by default, since the production environment in symfony is really optimized for performance. Among the performance-impacting development features, the SF_DEBUG mode is the most severe. As for the symfony logs, the feature is also turned off in production by default.

You may wonder how to get information about failed requests in production if logging is disabled, and argue that problems arise not only in development. Fortunately, symfony can use the sfErrorLoggerPlugin plug-in, which runs in the background in production and logs the details of 404 and 500 errors in a database. It is much faster than the file logging feature, because the plug-in methods are called only when a request fails, while the logging mechanism, once turned on, adds a nonnegligible overhead whatever the level. Check the installation instructions and manual at http://www.symfony-project.com/wiki/sfErrorLoggerPlugin.

Optimizing Your Code

It's also possible to speed up your application by optimizing the code itself. This section offers some insight regarding how to do that.

Core Compilation

Loading ten files requires more I/O operations than loading one long file, especially on slow disks. Loading a very long file requires more resources than loading a smaller file--especially if a large share of the file content is of no use for the PHP parser, which is the case for comments.

So merging a large number of files and stripping out the comments they contain is an operation that improves performance. Symfony already does that optimization; it's called the core compilation. At the beginning of the first request (or after the cache is cleared), a symfony application concatenates all the core framework classes (sfActions, sfRequest, sfView, and so on) into one file, optimizes the file size by removing comments and double blanks, and saves it in the cache, in a file called config_core_compile.yml.php. Each subsequent request only loads this single optimized file instead of the 30 files that compose it.

If your application has classes that must always be loaded, and especially if they are big classes with lots of comments, it may be beneficial to add them to the core compile file. To do so, just add a core_compile.yml file in your application config/ directory, and list in it the classes that you want to add, as in Listing 18-22.

Listing 18-22 - Adding Your Classes to the Core Compile File, in myapp/config/core_compile.yml

- %SF_ROOT_DIR%/lib/myClass.class.php
- %SF_ROOT_DIR%/apps/myapp/lib/myToolkit.class.php
- %SF_ROOT_DIR%/plugins/myPlugin/lib/myPluginCore.class.php
...

The sfOptimizer Plug-In

Symfony also offers another optimization tool, called sfOptimizer. It applies various optimization strategies to the symfony and application code, which may further speed up the execution.

The symfony code counts many tests that rely on configuration parameters--and your application may also do so. For instance, if you take a look at the symfony classes, you will often see a test on the value of the sf_logging_enabled parameter before a call to the sfLogger object:

if (sfConfig::get('sf_logging_enabled'))
{
   $this->getContext()->getLogger()->info('Been there');
}

Even if the sfConfig registry is very well optimized, the number of calls to its get() method during the processing of each request is important--and it counts in the final performance. One of the sfOptimizer optimization strategies is to replace configuration constants by their value--as long as these constants are not subject to change at runtime. That's the case, for instance, with the sf_logging_enabled parameter; when it is defined as false, the sfOptimizer transforms the previous code into the following:

if (0)
{
   $this->getContext()->getLogger()->info('Been there');
}

And that's not all, because an evident test like the preceding one also gets optimized to an empty string.

To apply the optimizations, you must first install the plug-in from http://trac.symfony-project.org/wiki/sfOptimizerPlugin and then call the optimize task, specifying an application and an environment:

> symfony optimize myapp prod

If you want to apply other optimization strategies to your code, the sfOptimizer plug-in might be a good starting place.

Summary

Symfony is already a very optimized framework and is able to handle high-traffic websites without a problem. But if you really need to optimize your application's performance, tweaking the configuration (whether the server configuration, the PHP configuration, or the application settings) will gain you a small boost. You should also follow good practices to write efficient model methods; and since the database is often a bottleneck in web applications, this point should require all your attention. Templates can also benefit from a few tricks, but the best boost will always come from caching. Finally, don't hesitate to look at existing plug-ins, since some of them provide innovative techniques to further speed up the delivery of web pages (sfSuperCache, sfOptimizer).