This document discusses various techniques for optimizing PHP application performance, including network optimization using load balancers, database scaling using replication and caching, application optimization using profiling and caching, and server optimization using clustering. It recommends using tools like Xdebug and Zend Server's code tracing and profiling to identify bottlenecks and optimize applications. The overall message is that a holistic approach considering the network, databases, applications and servers is needed to achieve high performance PHP applications.
Public facing, router – then into network. LB cand do natting.
Examples of hardware appliances Coyote point, Barraccuda
Talk about load balancer redundancy – no SPF
10X less sytem calls with and without O+. Most of the system calls that are gone are fstat and lstat, which are both file ops.
We could get even better results by not checking file timestamps.
One point to talk about here is Drupal bencchmark O+ v/s APC
We released Zend Server and Zend Server Community Edition in April this year
Products written from scratch based on our very extensive experience with Platform technologies
Full integrated stack, native installer, ZF and Studio integration, software updates, all new UI, …
Both editions have been very well received by users (love performance boost, ease of use, deployment)
Great fit to our partners – we’re working with Varien/Magento, KnowledgeTree, MCS, …
Next step will round up web app server offering to support high availability and scalability – more on this in the next few months
Infobright is one of the exhibitors here at ZendCon.
ZF – remember opcode caching?
Desing in modular way
Application performance optimization – question to always ask yourself: 1- what am I gaining? 2- would it be cheaper to throw hardware at the problem? 3- how do I prove it. -> if gaining 2X by optimizing but cost is 3X what it would cost to buy a server and gain 1.5 or 1.8 times, decision is relatively easy. Cost v/s gain.
ORM is going to return results in any way it knows -> up to you to optimize
Trade-offs of performance v/s code readability and “pretty” architecture. Cf. Martin fowler on Enterprise architecture design patterns.
What I mean here is that you need to start thinking about what the app is going to be used for at the early planning stage, because that will define certain design decisions you make.
If low traffic, I can send 100-200 queries to db per page, they’re really fast. I can therefore use a readable code because at the code level I’m just using my most basic objects to perform CRUD. But if high traffic app, then I need to start thinking, do I really want 100-200 queries to the DB per page, or should I, instead, try to optimize this by designing special objects that perform CRUD specific to this context?
A Zend Consultant’s secret weapon: Code tracing. -> DEMO
Know the hardware:
If I know the HW I’m writing for, if for example I’m writing a read/write heavy app, and I know that disks are particularly slow, I’ll emphathize caching.
That’s valid advice for caching too by the way. If a piece of code takes 3 seconds to execute (some kind of recursive menu build), and it takes a few minutes to add caching to it, if the menu does not change often, why bother spending hours rewriting?... Better to just add caching.
Performance optimization in general is an art, not a science. Like good application design.
EXPLAIN is your friend. Using the power of an in application query profiler combined with EXPLAIN, you can tune your SQL statements to the dot.
Demo: ZFA app (wiki) with the use of Zend_Db_Profiler
Add indexes where needed, if a query is too intensive on the server, try to take some of the logic out of the query, split it into multiple subqueries and do some heavy lifting in PHP instead of the database.
If you are given time, try to optimize before caching. I know I said before that if caching is easier, then go with that, but as with everything, if it’s too easy, you cache and cache, and before you knmow it, well you’re running memcached on a 40 Gb RAM server that holds a copy of your databse and you’ve written a whole architecture/layer to keep your cache in sync with DB.
It’s all about balance, and that comes with experience.
Explain vmstat output
Important because in an ideal world, 3 limits would be hit together. But if you know what you app’s usage patterns are, then you know where to optimize, and you know what the specs to your next server are!