Comments on: Scaling Up: Reducing Drag, Increasing Lift

By: Matthew Weier O'Phinney

Matthew Weier O'Phinney — Wed, 25 Feb 2009 13:28:41 +0000

@1stvamp I should have mentioned that when I mentioned usage of autoloaders. Zend Framework’s Zend_Loader::loadClass() actually uses include() internally (after first checking against class_exists()), so when used within an autoloader, it’s doing exactly what you suggest — and that’s what I was benchmarking.

By: Wesley Mason

Wesley Mason — Wed, 25 Feb 2009 12:06:42 +0000

@weierophinney: Opcode caches such as APC and Xcache have trouble caching opcodes called using require_once and include_once due to the architecture of the Zend engine and the way it handles these, so even when using a cache it can be more optimal to avoid the extra IO of a *_once function call.
One way I get around this is by emulating the use of _once within an spl_autoloader class, which just calls require instead.

By: Brandon Savage

Brandon Savage — Tue, 24 Feb 2009 16:47:51 +0000

Thanks Eli. You’ll note that I modified the article somewhat to reflect your statements, and I know you’re right about some of them. I do agree with Matthew Weier O’Phinney, though, relating to require_once, and I think that good planning can help with these things.

Thank you both for your comments. I welcome the discussion.

By: Matthew Weier O'Phinney

Matthew Weier O'Phinney — Tue, 24 Feb 2009 16:42:11 +0000

require_once calls are expensive — but when you use an opcode cache and PHP >= 5.2.0, the impact becomes trivial. PHP 5.2.0 adds a realpath cache, which greatly speeds up the lookups and reduces the number of hits to the filesystem. Even if you’re loading dozens or hundreds of files, under APC or Zend Accelerator, the performance impact is greatly mitigated.

Another tip: strip the require_once calls and use autoloading. I did this when profiling Zend Framework, and the performance impact was dramatic. If you have a good autoload strategy and use an opcode cache, I often saw performance increases of 4-10x.

By: Eli White

Eli White — Tue, 24 Feb 2009 15:59:19 +0000

Overall, a decent writeup; however, I disagree on some of the points. The SQL code you first present for example, is IMO the more scalable code (if perhaps not more performant). It is my experience that doing many smaller compact & direct queries allows you to scale better. They can be farmed out to multiple DBs, they have a greater chance of hitting a DB cache, they are easier for you to cache yourself, they create less DB load overall by requiring less ‘complicated work’ of the DB, etc.

Secondly, you state that if you are going to include a number of files, that you should turn APC off because it’s not helping you. Again, I disagree. Sure if you happen to include a dozen (or hundreds) of separate PHP files, you are requiring some stat commands to happen, and if using require_once, then a hash lookup. But those are so minor when compared to recompiling each file over and over again. Trying to avoid those stat/hash things is a good concept, but is a real fine-tune performance measure. And can harm your code maintainability in the process as you attempt to clump files together.

Finally, you have a very nice section on concurrency, something that many people overlook. (Also Slave Lag is often overlooked and can be seen as related to concurrency). However, having code designed for concurrency has nothing to do with scalability (nor performance)