• This is a high level overview.
• Most of the things that we do may or may not be applicable to your project.
• I'm a first time conference speaker, please go gentle.

• PHP Developer since 2001
• Zend Certified Engineer (PHP 5 & PHP 5.3)
• Worked for NationalGuard.com
• Work at Discovery Communications, Inc. (Discovery Channel)
• Work specifically on HowStuffWorks.com.
• You might know me from IRC/Twitter as mFacenet.

http://joind.in/3971

• Founded in 1998 by Marshall Brain.
• Covers various topics and describes "How They Work"
• Has won several awards.
• Offers various podcasts including "Stuff You Should Know"
• Bought by Discovery Communications in 2007.

Statistics:

• We serve over 4.5 Million Pages every day.
• We have 970,000 unique URLs serving approximately 442,000 pieces of content.

Our Stack

• Not how to micro-tune your application.
• Not how to scale to an unlimited amount of horizontal nodes.

These are foolish endeavors most of time (unless you are Facebook)

• Get the right mix of scalability, performance and minimization of yaks shorn per feature.

For us, Zend Framework is:

• A decent library that allows us to not have to write the system plumbing.
• Decently well performing.
• Flexible to our needs.
• Easily extensible so that we can override behavior.
• We've been using it since 0.1 and it's been in production for us since 0.7 so in some cases we've diverged greatly from the framework.

If you are not using opcode caching (APC, Wincache, Zend Optimizer+) you're missing out.

Heavy processing should be run in the background, there are several ways to do this here are some:

• Gearman.
• Beanstalkd.
• PCNTL extension on Unix.
• Cron Jobs.
• In house job queues (surprising how many places have these.)

• Zend Controller
• Zend FrontController
• Zend View
• Zend View Helper
• Zend Router (more on this shortly)
• Zend Dispatcher
• Zend Registry
• Zend Log
• Zend Mail
• Zend\Loader

• Everything but the ads.
• On article pages, we use facebook for the comments system.
• Our services, internal APIs, and AJAX providers are all using ZF.
• Our CLI scripts mostly use ZF as well.

• Zend Application - It's a bit heavy if you know exactly what you want.
• Zend Config - Parsing INI Files is slow and requires disk IO.
• Zend Form - We're better off writing forms by hand.
• Zend Db - We have our own modeling Layer, it's not great but it's better suited for what we wanted.

Matthew Turland wrote an interesting blog post about Zend Framework 1 Forms & the Plugin Loader which will aide with Forms in larger implementations, his post:

http://bit.ly/zfforms

• Probably the biggest change we've made to the architecture since I joined HowStuffWorks.com
• We use ZendLoader (from Zend Framework 2).
• Specifically we are using the Classmap Autoloader.
• With this autoloader we saw a 15%+ performance increase over using include/include_once.
• Was stable back in April (according to MWOP)

So why does this work?

• No longer searching include paths (stating for files is expensive).
• Direct include (no _onces) and not stats to check the file system.

I strongly strongly strongly strongly advise moving to the ZF2 psr0 and classmap autolaoders, there are some strong problems with the ZF1 Autoloader.

• It iterates through each include path to try to find a file matching what you're looking for.
• This is slow because it has to then stat the file system for every include path to see if the file exists.

Here's what the Zend Framework guide says on how to optimize the Include Path (if you absolutely have to use it)

• Use absolute paths.
• Reduce the number of paths you define.
• Define the library path as early as possible.
• Define the current directory last, or not at all.

• Tends to require files that may not actually be needed.

• Should be stripped out.

  find . -name '.php' -not -wholename '/Loader/Autoloader.php' -not -wholename '*/Application.php' -print0 | xargs -0 sed --regexp-extended --in-place 's/(require_once)/// 1/g'

• Moved Rewrite rules to Apache Configuration.
• We have a favicon.ico file in the root, you should too!
• Disabled overwrite (.htaccess.)
• Disabled Apache modules we're not using.

• Moved Configuration to a PHP file that's processed prior to PHP execution. (using auto prepend file)
• All Configuration is written in PHP and set to the $_SERVER superglobal (and subsequently cached in APC).
• Extended the Request object to act as a gateway to the $_SERVER superglobal and contain default values for common settings.

Problems with Zend Config

• Uses parse_ini_file or simplexml_load_file to process the configuration file. (Not Cacheable, stats the filesystem, etc)
• These have to tokenize the files, not absurdly slow but still additional time.
• This is done EVERY time you make a request.

We can do this better

• Create your configuration in a PHP array.
• Set via apache SetEnv.
• Set via preprocessed file (what we're doing for now.)
• At the very least cache your results from INI or XML

$config = require(APPCLIATION_PATH . '/configs/application.php');
$application = new Zend_Application(
    APPLICATION_ENV,
        $config
);

The File

<?php
    return array(
        'key' => 'value'
    );

--or--

<?php
    $config = array()
    if (APPLICATION_ENV == 'development')
    {
        $config['key'] = 'value';
    }
    return $config;

Replace apc_fetch/apc_store with memcache::get/memcached::set, wincache_ucache_add/wincache_ucache_get, etc.

$config = apc_fetch('my_config');
if (!(is_array($config)) {
  require_once 'Zend/Config/Ini.php';
$section = APPLICATION_ENV;
$filename = APPLICATION_PATH . '/configs/application.ini';
  $config = new Zend_Config_Ini($filename, $section);
  $config = $config->toArray();
  apc_store('my_config', $config, 600);
}

// Create application, bootstrap, and run
$application = new Zend_Application(
    APPLICATION_ENV,
    $config
)

• We completely replaced the Zend Router implementation with our own.
• Our system searches a MySQL table using b-tree indexes to figure out the route.

Why?

• The stock rewrite router iterates through every route until it finds the one it's looking for, by using MySQL we are querying in place using indexes.
  
• Allows us to process the 970,000 urls in our system, including adding new urls on the fly.

• When using MySQL or external services, you generally want to cache the return where you can.
• Shared Memory Caches are good for single server deployments, if you go larger Memcache or Redis is good.
• You can use Zend Cache, we didn't but mostly only because it wasn't a component at the time we started using it.

We use Memcache, some of the things we cache:

• Routes
• Database Returns
• PHP Sessions (we use Memcache as our Session Save Handler)

• Allows you to generate output and cache it.
• Works great for us, we have mostly static content and can invalidate content at will.
• Completely bypasses ZF, PHP, etc.
• Several providers in the space, Akamai is the one we use.
  
• Additional benefits include geographical distribution.

Just a quick summary:

• Choose what components you need, most are written for flexibility not performance.
• Use autoloading, strip the include and require statements everywhere.
• Use Opcode caching, you're a fool if you're not in production.
• If you use Zend Config, cache the results, using INI or XML means this isn't cached by default.
• Routing can be slow if you have many routes, try to make these explicit.
• Cache where possible, especially front end.
• Serve resources from a CDN.

Most Importantly

• Don't shoehorn things into Zend Framework, if it doesn't work for you don't force it.