views:

85

answers:

4

I have zlib and Zend Optimizer enabled on my server.

I have read about the

zlib.output_compression

directive. Are there any caveats with turning this directive on in my server?

+1  A: 

Learn profiling.
Then optimize bottlenecks.

Col. Shrapnel
+5  A: 

First you should determine what the bottleneck is (or will probably be under load).
With turning on (transparent) compression you trade cpu resources for data (network) throughput. So, you have to think about: Is my data (highly) compressible? Is the time it takes to transfer the data to the client a bottleneck? How much cpu resources can I spent for the compression? What other resources does my script use (e.g. memory consumption, database connections, ...)? Which resource will become the bottleneck under (heavy) load? When, where and for how long will one instance of the script block another instance? And so on and on.

You might also be interested in tools like YSlow, profilers like the one built into xdebug, the apache benchmarking tools, (code) caches like apc ...and many more.

VolkerK
To sum it up nicely, which resource is the problem for you? CPU or bandwidth? Its much cheaper to add additional computing power over bandwidth so from a management perspective its in your best interests to add more computing power to handle the additional burden of compressing files to save on bandwidth.
Jarrod
+2  A: 

The single most effective thing you can do to speed up PHP code is run an opcode cache.

Zend Optimizer+ is one example. The older Zend Optimizer (without the "+") was a code optimizer, not an opcode cache, and it could actually slow down PHP code if you didn't use an opcode cache.

After you do that, then comes a lot of hard work to test for bottlenecks (as other people have mentioned). You'll need to refactor your code carefully to mitigate the bottlenecks. Most performance experts say that performance problems are caused by poor application architecture more than individual lines of code.

Caching content that you'll need to show multiple times is also a common solution for improving performance. But deciding what content to cache, and for how long, is another area where you need to do testing and experimentation and exercise judgment.

Consider that the bottleneck might not be in your PHP code at all. It could be that your database doesn't have the right indexes. Finding the right indexes given the queries you need to run is also meticulous work and involves testing.

Also frequently your bottleneck can be in the client. Even if your PHP code runs quickly on the server, the page could load inefficiently in the browser, creating a perception of poor performance.

IMHO, all web designers and developers should make Steve Souders books and blogs required reading.

This also relates to the zlib configuration you were asking about, and client performance measurement tools like YSlow and Google PageSpeed.

Bill Karwin
A: 

Output compression is THE way to go. Set the compression level to 1, since it gives the greatest saving/CPU overhead ratio. The default level is 6 in a 1-9 scale, which may be inefficient by slowing things down for some extra bytes.

galambalazs