Performance

Performance work in PHP starts with measurement. Before changing anything, you need to know where time is actually being spent. Guessing at bottlenecks is how teams end up rewriting code that was never the problem while the real issue sits untouched in a database query or an autoloader configuration. The Performance Optimisation chapter in the Zend Framework Book and the PHP Performance Playbook guide both take this profiling-first approach.

Profile Before You Optimise

The single most important principle in performance work is to measure first. Tools like Xdebug’s profiler, Blackfire, and Tideways give you call graphs that show exactly which functions consume the most wall time and memory. Without this data, you are making changes based on assumptions, and assumptions about performance are frequently wrong.

In a typical Zend Framework 1 application, the dispatch loop, autoloading, and database queries tend to be the dominant costs. But the specific breakdown varies enormously between projects. An application that loads hundreds of classes on every request has a different profile from one that spends most of its time in a handful of complex SQL queries. Profiling tells you which one you are dealing with.

Opcode Caching

PHP is a compiled-at-runtime language. Every request, the PHP interpreter reads your source files, compiles them to opcodes, executes them, and discards the compiled result. Opcode caching stores the compiled opcodes in shared memory so that subsequent requests skip the compilation step entirely.

OPcache has been bundled with PHP since version 5.5 and is enabled by default in most production configurations. For Zend Framework applications with hundreds or thousands of class files, OPcache alone can cut response times significantly. The Performance chapter covers this alongside other caching strategies specific to ZF1.

PHP 7.4 introduced preloading, which takes OPcache further by loading a defined set of files into memory at server startup. Preloaded classes are available to every request without any file system access or compilation. This is particularly effective for framework code that is loaded on every request regardless of the route.

Caching Layers

Beyond opcode caching, PHP applications benefit from multiple caching layers:

Application-level caching stores computed results so they do not need to be recalculated on every request. Zend Framework 1 included Zend_Cache with backends for file, APC, Memcached, and others. In modern PHP, PSR-6 and PSR-16 provide standard caching interfaces that work across frameworks.

Query result caching stores the results of expensive database queries. This is especially useful for data that changes infrequently but is read on every page load, like navigation structures, configuration values, or category trees.

Full-page caching stores the entire rendered HTML output for a given URL. This bypasses PHP entirely for cached pages, serving the response directly from the web server or a reverse proxy. Varnish and Nginx’s built-in cache are common choices for this layer.

HTTP caching uses cache headers (Cache-Control, ETag, Last-Modified) to let browsers and CDNs store responses. For static assets and pages that do not change per-user, proper HTTP caching eliminates the request from reaching your server at all.

The glossary entry for Caching Strategy defines these concepts, and the PHP Performance Playbook covers each layer in practical detail.

Database Optimisation

For most PHP applications, the database is where performance problems live. Missing indexes, N+1 query patterns, unoptimised joins, and oversized result sets are common in codebases that grew organically over time. The EXPLAIN statement in MySQL and PostgreSQL shows you how the database plans to execute a query, which is the database equivalent of profiling your PHP code.

The Model chapter and Domain Model implementation chapter both deal with data access patterns. Choosing between eager and lazy loading, structuring queries to avoid unnecessary joins, and keeping the persistence layer clean all have direct performance implications.

Autoloading Efficiency

In Zend Framework 1, the default autoloader scanned the include path and mapped class names to file paths using the underscore convention. This worked, but it meant file system lookups on every new class load. The Performance chapter covers classmap generation as a way to replace path scanning with a direct lookup array.

Modern PHP uses Composer’s PSR-4 autoloader, which can generate an optimised classmap with composer dump-autoload --optimize. This is the equivalent technique for current projects and should be part of any production deployment process.

Frontend and Delivery

Server-side performance is only half the picture. Asset minification, image compression, HTTP/2, and content delivery networks all affect what the user actually experiences. The Design chapter touches on frontend asset integration in the context of Zend_View and Zend_Layout.

Glossary Terms

See PHP for language-level performance changes across versions, Apache for web server tuning, and Application Architecture for structural decisions that affect performance.