Better ways to improve php application performance

June 25th, 2009

Google recently released a document on how to improve PHP performance here. Most of the tips listed here will not help you improve performance by any significant amount. The following is a list of things that you can do that will improve the performance of your web apps significantly.

1) object code caching

Each time a request comes to your server for a php script, it has to go through the compiler and then execute the object code. If this is cached, the 1st step is skipped and you end up with a faster and more responsive script.

There are many object code caching packages available on the Internet:

A) Ioncube: http://www.ioncube.com/

B) Zend Encoder: http://www.zend.com/products/zend_safeguard

2) Template systems

Template systems provide a different type of caching. Content caching. Template systems work well in a situation where there is static data on one or many of your pages that doesn’t have to be reloaded. Caching systems also provide a separation of code and html, which will not only improve completion time of the overall project, but make it easier for future improvments. Most template systems for php are available for free:

A) Smarty Templates: http://smarty.php.net/

B) Pear Templates: http://pear.php.net/package/html_template_it/redirected

C) PHP savant: http://phpsavant.com/yawiki/

3) Distributed object caching systems

The most widely used system of this type is memcached (http://www.danga.com/memcached/).

This type of system makes your overall site faster by caching the majority of your database data into a large memory pool.

more on memcached:

Danga Interactive developed memcached to enhance the speed of LiveJournal.com, a site which was already doing 20 million+ dynamic page views per day for 1 million users with a bunch of webservers and a bunch of database servers. memcached dropped the database load to almost nothing, yielding faster page load times for users, better resource utilization, and faster access to the databases on a memcache miss.”

4) PHP variables that can be set

variables_order = ‘GPC’
register_argc_argv = ‘Off’
register_globals = ‘Off’ (this is a good idea to keep off for security purposes as well)
always_populate_raw_post_data = ‘Off’
magic_quotes_gpc = ‘Off’

Disable Error Logging. This is a good idea to keep on when you are developing your scripts, but it has been known to decrease overall performance.

Use IP addresses, rather than host names to access your database. Although this is sometimes not possible, you will get a slight boost in lookup speed if the IP address is used to access your database rather than its hostname.

5) Output Compression

Almost all browsers these days support something called gzip compression. Gzip compression can decrease the overall size of your output by up to 80%, but with a tradeoff: cpu usage will go up by around 10%. The benefit of using this compression type is the fact that not only will your bandwidth be decreased, but your pages will load faster.

enabling it in php (add the following lines to php.ini):

zlib.output_compression = On
zlib.output_compression_level = (level) (where level is 1-9. Youy may want to try different values to see what is best for your system).

if you are using apache, you can also enable the mod_gzip module. It is highly configurable, with the ability to modify output based on MIME types, files, or browser settings.

6) Other things that may help

when using a database, only retrieve the data that you are actually going to use. This may sound like a no-brainer, but I have often times worked on projects where the original programmer used (select * from mytable) when they could have used (select fieldIneed from mytable).

index database tables whenever possible

Learn more about this Here



11 Comments »

  1. On #2 - Some over those over kill. Look for BF_Template class if you need something really simple.

    Something I do get ~12% faster performance is all my while loops are changed to do…while()
    EX:
    $sql = ‘…’;
    $qry = mysql_query($sql);

    while($row = mysql_fetch_assoc($qry))
    {

    }

    I change it to:
    $sql = ‘…’;
    $qry = mysql_query($sql);
    $cnt = mysql_num_rows($qry);

    if($cnt >0)
    {
    do
    {
    $row = mysql_fetch_assoc($qry);

    –$cnt;
    }while($cnt > 0);
    }

    Comment by ellisgl — June 25, 2009 @ 1:50 pm

  2. #2 - Well… except in most template systems let you add in php code, and if they are using curly braces for their delimiters they will force you to hack in other code just to get around the limitations of the template system, ruining any benefits that you might have gained. (I’m looking at you `Smarty`…)

    Comment by SeanJA — June 26, 2009 @ 4:49 pm

  3. [...] here: Better ways to improve php performance | A blend of programming and seo Share and [...]

    Pingback by Better ways to improve php performance | A blend of programming and seo — June 27, 2009 @ 4:29 am

  4. I’m glad someone picked Google up about this. I was thinking their tips were almost all bogus when I read them too.

    Comment by Chris Graham — June 27, 2009 @ 6:10 am

  5. Did you take lessons from Google?

    IONCube and Zend Encoder are not op-code caches. They’re used to protect your code and have nothing to do with speeding it up.

    I would of mentioned APC, eAccellerator and xCache

    Comment by Mathew — June 27, 2009 @ 3:44 pm

  6. @matthew:

    take a look at this article: http://itst.net/654-php-on-fire-three-opcode-caches-compared

    Ion Cube may not offer actual opcode optimization, but zend encoder does (~128% performance increase).

    I have tried both eAccellerator and xCache, and they have major stability issues in a production environment.

    Comment by Justin (rawseo) — June 27, 2009 @ 4:01 pm

  7. And yet you link to Turck MMCache, which hasn’t seen an update in almost six years.

    Comment by Dixon — June 28, 2009 @ 6:38 am

  8. Wish there was an explanation for why do/while is faster than while.

    Wish I could do “SELECT * EXCEPT(`modified_date`, `amenities`,`client_id`) FROM mytable”
    Because most of the time I do need the other 20+fields and future projects using most of the same code often call for the addition/removal of some fields and that would mean going back and editing the field select list in lots of places.

    The google group thread on this just continues my years-long confusion about a few other things.
    http://groups.google.com/group/make-the-web-faster/browse_thread/thread/ddfbe82dd80408cc

    Is output buffering going to speed things up once and for all. I need a definitive answer on this from a reliable source or my boss will continue to forbid me from using ob_ functions. (He says it slows things down based on a comment he saw in php.ini.)

    And if someone happens to have an unbelievably good article about why you shouldn’t do [? extract($_GET); extract($_POST); ?] at the start of every script I would be forever grateful. I’ve been trying for 3 years to convince him but that page on php.net about why register_globals is bad has had no effect on him.

    Comment by pseudocoder — June 29, 2009 @ 9:12 am

  9. Being (relatively) new to PHP I’m confused by contradictory advice I’ve seen regarding using single vs double quotes for PHP strings.

    Early on in my PHP experience I’d read in several places that double quotes were more expensive because PHP always parsed them looking for vars that had to be defereferenced and converted to string content even if there were no embedded vars in the double-quoted string. They went on to say that PHP never parsed single-quoted strings for embedded vars, so using double quotes when there were no embedded vars was making PHP waste a lot of time parsing those strings for no reason.

    Is there *any* truth behind this thinking or have I been the victim of cyber-legend?

    TL

    Comment by Thomas Lukasik — July 2, 2009 @ 12:53 pm

  10. @thomas:

    check out this site:

    http://phpbench.com/

    From the tests there, it looks like single quotes are slightly faster.

    Comment by Justin (rawseo) — July 2, 2009 @ 10:53 pm

  11. @pseudocoder:

    If you are having trouble explaining why register_globals is a bad thing, you can always explain that the new versions of php (version 6) will be completely removing this feature and that it’s a good idea to stop relying on it.

    Comment by Justin (rawseo) — July 2, 2009 @ 11:14 pm

RSS feed for comments on this post. TrackBack URL

Leave a comment