Comments on: “Micro” Optimizations That Matter

By: Daniel

Daniel — Mon, 26 Oct 2009 15:33:28 +0000

Sage advice. Thanks for all the tips. I will definitely keep bookmark this one for future reference.

By: Brandon Savage

Brandon Savage — Mon, 19 Oct 2009 09:02:55 +0000

Unfortunately I’ve seen lots of developers leave errors in their apps. They don’t error trap well enough, or they don’t consider the possibilities and they end up with notices or errors. It happens more than one might think.

By: LP

LP — Mon, 19 Oct 2009 09:01:32 +0000

Ah, got it. Well, sure then, fixing errors is always a good practice, and I can’t imagine developer who allows himself not fixing continuous errors in his app.

By: Brandon Savage

Brandon Savage — Mon, 19 Oct 2009 08:34:25 +0000

You completely missed the point here. I never suggested getting rid of error logging. I suggested getting rid of as many errors as you possibly could so that they wouldn’t be logged. Not logging errors is dumb. But having known errors that you’re logging because you’re too lazy to fix them is even greater stupidity. Don’t do that.

By: LP

LP — Mon, 19 Oct 2009 08:28:29 +0000

I think eliminating error logging is bad advice. Sure, it adds some overhead, but security your app means much more then performance. You can’t be 100% sure that you’ve fixed all errors during development and testing, many errors show themselves only on real data, and browsing error log can be the only way to find them when your app is live.

By: Zyx

Zyx — Mon, 19 Oct 2009 07:00:02 +0000

I think it is worth pointing out that autoloader should be fast itself in order to get the performance boost. Basically, it must use the information stored in the class name to locate the file, and it should not perform any complex calculations on them. Another good thing is not to use include_paths, which are very slow if there are many paths (PHP must test all of them in the worst case) and the most frequently used are at the end.

By: cocowool

cocowool — Mon, 19 Oct 2009 03:22:24 +0000

if we use a host service from others, many optimizations have been down by the company, so i think we should focus on our architect, when we have the traffic more and more, it’s time to consider optimization

By: Tomaž Muraus

Tomaž Muraus — Sun, 18 Oct 2009 20:40:23 +0000

Most hosts use some kind of opcode caching system like APC or eAccelerator, but I don’t know any shared hosting which supports memcached.

Anyway, if you have a large and popular website and you are using some cheap shared hosting, wondering if your host supports memcached should be the least of your concern.

By: Jeremy Glover

Jeremy Glover — Sat, 17 Oct 2009 22:31:55 +0000

Great post, Brandon.

Do most web hosts support APC and memcached or do you have to go to more expensive hosts for those to be available?

While S3 isn’t technically a CDN, you can still get many benefits from using it as one. As was noted earlier, it offloads the request/response process from your sever, allowing it to work on more important things. Also, the quality of S3 is so high that its response times are typically way faster than most people’s severs, especially if you’re using a cheap host like me. Check out how much S3 helped my website: http://www.jeremyglover.com/blog/2009/03/16/speed-up-that-cheap-website-with-cheap-amazon-s3/

Thanks again for all the pointers!

By: Samuel Folkes

Samuel Folkes — Sat, 17 Oct 2009 02:52:00 +0000

Yet another excellent post Brandon. I’m glad you wrapped the word “Micro” in the title in quotes because when compared to some of the ‘optimization strategies’ I see floating around the web the optimizations you listed here a pretty huge. Just two points. The first is that in almost all my tests I have found autoloading to be faster than or at least as fast as multiple requires or includes using PHP 5.2+. The second is that I would add to your list that page load times can be significantly decreased if output compression is enabled, whether via output buffering (ob_start(‘ob_gzhandler’)) or php.ini (zlib.output_compression = On)

By: Brandon Savage

Brandon Savage — Sat, 17 Oct 2009 00:32:15 +0000

Point taken. You’re quite right. I think you can deliver content directly out of the S3 storage network but its not a CDN.

By: Jay

Jay — Fri, 16 Oct 2009 21:57:43 +0000

A small clarification: S3 is not a content-delivery network. It’s just file storage. Just hosting your files on S3 won’t speed things up much, if at all.

CloudFront is the name of Amazon’s CDN. It requires S3, but it’s a different product.

By: Gyorgy

Gyorgy — Fri, 16 Oct 2009 20:35:40 +0000

Thumbs up for this post!

By: Adam

Adam — Fri, 16 Oct 2009 16:27:00 +0000

@Matthew: I’ve read about those optimizations and IMHO that’s why in my test scenario autoload was as fast as require_once while loading all 1000 classes. It’s amazing how well it performs.

@Brandon and @Simon: I know the benefits of autoload – performance gain and ease-of-use.

My doubts are about APC opcode cache and autoloading. In this case code is loaded at runtime, on demand, so does opcode cache know how to deal with it? Maybe it does cache all code and use cache blocks (representing classes) when needed?

By: Oscar

Oscar — Fri, 16 Oct 2009 15:35:50 +0000

Related to “Determine What Data Doesn’t Need To Be Real-Time”, but more specifically I’d recommend you move any code that depends on a network call to a corn job. The classic example of this is using curl/include to get an RSS feed and parse it. This should be done outside the script that handles the http request. Store the results in cache/db and retrieve them quickly for display on your pages.