3 ms·

No. Most of the large, healthy PHP-based sites I’ve worked on spend 5-20% of their average request time in the database. Which means PHP is chewing 80-95%. Whi

by jdub 12y ago

No. Most of the large, healthy PHP-based sites I’ve worked on spend 5-20% of their average request time in the database. Which means PHP is chewing 80-95%. Which makes PHP the slow bit. Not because PHP is bad: That’s a pretty reasonable figure for platforms based on Ruby, Python, PHP, etc. (Less so for Java and .NET.) It's a really good rule of thumb: If you’re spending more time during each request doing database work rather than PHP work, then you’ve got a problem that needs to be fixed. You’ve probably hit a database scalability limit, or tried to get the database to do something silly. (And hey, that’s easy to do with MySQL, which is fast primarily because it’s dumb.) (By the way: WordPress, out of the box, doesn't spend much time in the database at all.)

m0th87 12y ago
> If you’re spending more time during each request doing database work rather than PHP work, then you’ve got a problem that needs to be fixed. For most webapps, I/O typically should be the bottleneck. This holds especially true for wordpress, which has nothing computationally heavy to do, and is...rather liberal with the way it queries the database. Certainly the large installations I've managed spent most time doing I/O (either in the database or memcached.)
Rapzid 12y ago
I'm going to have to backup jdub on this. The "IO/database should be" classic wisdom has not really held up to my experience doing a stint providing managed support for LAMP(P as in PHP) servers at a hosting company. Most of the time there were performance issues it was PHP taking up the CPU's. We had a lot of success mitigating this for people with some proper varnish configs. Very rarely was the issue with the databases. I've had people not want to normalize data and create some generally disgusting tables and code because "joins bad"... On tables that will only ever have a few 10k records. If you have the proper indexes and queries in place, your database is just traversing btree's in memory and it will be blazing fast.
zapt02 12y ago
This is completely correct. On smaller sites, we're usually seeing 1% of total time spent in database, the rest being PHP. With larger sites, this increases a bit to around 5% because larger databases take longer to return queries.

by jdub 12y ago

m0th87 12y ago

> If you’re spending more time during each request doing database work rather than PHP work, then you’ve got a problem that needs to be fixed. For most webapps, I/O typically should be the bottleneck. This holds especially true for wordpress, which has nothing computationally heavy to do, and is...rather liberal with the way it queries the database. Certainly the large installations I've managed spent most time doing I/O (either in the database or memcached.)

Rapzid 12y ago

I'm going to have to backup jdub on this. The "IO/database should be" classic wisdom has not really held up to my experience doing a stint providing managed support for LAMP(P as in PHP) servers at a hosting company. Most of the time there were performance issues it was PHP taking up the CPU's. We had a lot of success mitigating this for people with some proper varnish configs. Very rarely was the issue with the databases. I've had people not want to normalize data and create some generally disgusting tables and code because "joins bad"... On tables that will only ever have a few 10k records. If you have the proper indexes and queries in place, your database is just traversing btree's in memory and it will be blazing fast.

zapt02 12y ago

This is completely correct. On smaller sites, we're usually seeing 1% of total time spent in database, the rest being PHP. With larger sites, this increases a bit to around 5% because larger databases take longer to return queries.