Question

Before you answer this I have never developed anything popular enough to attain high server loads. Treat me as (sigh) an alien that has just landed on the planet, albeit one that knows PHP and a few optimisation techniques.

---

I’m developing a tool in PHP that could attain quite a lot of users, if it works out right. However while I’m fully capable of developing the program I’m pretty much clueless when it comes to making something that can deal with huge traffic. So here’s a few questions on it (feel free to turn this question into a resource thread as well).

Databases

At the moment I plan to use the MySQLi features in PHP5. However how should I setup the databases in relation to users and content? Do I actually need multiple databases? At the moment everything’s jumbled into one database – although I’ve been considering spreading user data to one, actual content to another and finally core site content (template masters etc.) to another. My reasoning behind this is that sending queries to different databases will ease up the load on them as one database = 3 load sources. Also would this still be effective if they were all on the same server?

Caching

I have a template system that is used to build the pages and swap out variables. Master templates are stored in the database and each time a template is called its cached copy (a html document) is called. At the moment I have two types of variable in these templates – a static var and a dynamic var. Static vars are usually things like page names, the name of the site – things that don’t change often; dynamic vars are things that change on each page load.

My question on this:

Say I have comments on different articles. Which is a better solution: store the simple comment template and render comments (from a DB call) each time the page is loaded or store a cached copy of the comments page as a html page – each time a comment is added/edited/deleted the page is recached.

Finally

Does anyone have any tips/pointers for running a high load site on PHP. I’m pretty sure it’s a workable language to use – Facebook and Yahoo! give it great precedence – but are there any experiences I should watch out for?

Answer 1

No two sites are alike. You really need to get a tool like jmeter and benchmark to see where your problem points will be. You can spend a lot of time guessing and improving, but you won’t see real results until you measure and compare your changes.

For example, for many years, the MySQL query cache was the solution to all of our performance problems. If your site was slow, MySQL experts suggested turning the query cache on. It turns out that if you have a high write load, the cache is actually crippling. If you turned it on without testing, you’d never know.

And don’t forget that you are never done scaling. A site that handles 10req/s will need changes to support 1000req/s. And if you’re lucking enough to need to support 10,000req/s, your architecture will probably look completely different as well.

Databases

• Don’t use MySQLi — PDO is the ‘modern’ OO database access layer. The most important feature to use is placeholders in your queries. It’s smart enough to use server side prepares and other optimizations for you as well.
• You probably don’t want to break your database up at this point. If you do find that one database isn’t cutting, there are several techniques to scale up, depending on your app. Replicating to additional servers typically works well if you have more reads than writes. Sharding is a technique to split your data over many machines.

Caching

• You probably don’t want to cache in your database. The database is typically your bottleneck, so adding more IO’s to it is typically a bad thing. There are several PHP caches out there that accomplish similar things like APC and Zend.
• Measure your system with caching on and off. I bet your cache is heavier than serving the pages straight.
• If it takes a long time to build your comments and article data from the db, integrate memcache into your system. You can cache the query results and store them in a memcached instance. It’s important to remember that retrieving the data from memcache must be faster than assembling it from the database to see any benefit.
• If your articles aren’t dynamic, or you have simple dynamic changes after it’s generated, consider writing out html or php to the disk. You could have an index.php page that looks on disk for the article, if it’s there, it streams it to the client. If it isn’t, it generates the article, writes it to the disk and sends it to the client. Deleting files from the disk would cause pages to be re-written. If a comment is added to an article, delete the cached copy — it would be regenerated.