PHP: Programming for Performance

This is a sticky topic.
  • Time
  • Show
Clear All
new posts
  • Buddha
    Senior Member
    • Mar 2004
    • 825

    PHP: Programming for Performance

    Getting the most out of PHP doesn't take much but like every thing in life practice makes perfect.

    What are the bottlenecks when it comes to programming?

    hard drive

    ... from worse to best. How do these apply to a PHP script? Well first you need to understand how PHP works. PHP is an interpreted language. PHP only delivers one page at a time. You really need to understand those last two statements to design PHP applications that perform well. It's much different from designing compiled applications where all the piece work together. PHP only see one page at a time, everything that doesn't contribute to producing that page is reducing performance.

    1. Server gets a file requests. ( network )
    2. Server passes request to PHP. ( memory, cpu )
    3. PHP reads script. ( hard drive )
    4. PHP converts script to bytecode. ( memory, cpu )
    5. PHP reads any included files, repeat 3-5 as needed. ( hard drive )
    6. Script may accesses database. ( hard drive, memory, cpu and maybe network if on separate server )
    7. Script may accesses remote data. ( network )
    8. PHP/Server send page as response. ( network )

    What are some of the specifics things that can increase performance?

    Reduce the number of files included. For example if your using templates combine those templates into one file. They will eventually be combined anyway, correct? This doesn't mean you have to use just one template file just mean compiling them into one. You could even write a program to do the compile as necessary. Program for the page, not the application.

    Reduce the size of those includes. Your production script does not need comments or white space. Run your scripts through PHP using the "-w" flag this will strip the comments and white space. If your including 30 "common" function on each page but only using one or two on each page. You need to do something about that, because they're not common to each page.

    Reduce the size of database queries. Database queries can be even worse than included files. Especially poorly written queries. Every time you use one of theses "*" in a query, ask yourself if your going to use all that data? If the answer is no, then insert only the field you'll need. There no excuse for laziness. Use LIKE (and regular expressions) sparingly in database queries. If your using LIKE to perform searches this isn't a good idea. The database will INDEX everything. Write a search program with the appropriate database structures and index only what is needed.

    Reduce the number of database queries. Basically, you need to decide what is static and what is dynamic. If the title and article on page are not going to change then they don't need to be queried every time the page renders. However the user comments, may change and should be queried every time the page renders. This maybe hard to do but it could have the biggest benefits to scalibility. When site grows to need more than one server your database may no longer be local. When that happens, your now faced with a new bottleneck - the network - every query better be absolutely necessary.

    Programming is more than just writing code, it's a process. No matter what methodology you follow the process is always the same. Design, develop and maintain. Don't skip the design stage just because you want to start coding. Some of the biggest mistakes are made in the design stage. Design mistake can't be fixed in the maintenance stage.

    With PHP, KISS ( Keep It Simple Silly ) is mandatory.
    "Whatcha mean I shouldn't be rude to my clients?! If you want polite then there will be a substantial fee increase." - Buddha
  • -Oz-
    Senior Member
    • Mar 2004
    • 545

    Excellent, I've made this a sticky.
    Dan Blomberg


    • Camo.Fish
      • Jul 2008
      • 42

      I have found, on DIS servers anyway, that the only thing that will slow down my pages are large media files and communicating with other servers. I can't stand linking to images on other servers because 99.8% of the time it drastically effects my page load times.

      Of course, you could get into some nasty looping/performance issues if you are writing PHP code with no idea what you are doing... but hopefully if that were the case you would not be putting it into production mode!

      For instance, in my custom mysql_query() I log every query to the database with an insert query, so in essence every call is a two-fer. It does not affect the performance of my DIS sites in any way if I comment it out, even under heavy traffic and I have been using this technique for over four years. My page load times on DIS are generally 0.14-0.52 seconds and that is my client timer, not the server timer. It does, however, provide some really nice data for studying errors, anomalies, unethical usage, and hacking attempts.

      And yet again, the multiple file loading... that may have been true once upon a very long time ago, but you could load hundreds of files without noticing a performance hit. PHP even has an autoloader function for loading class files and such... which I don't use because I wrote my own years before they added that. A loooong time ago, I felt that way (like 8 years or so) and I finally got over it when my Dreamweaver sites that loaded from two or three files and a couple small images were delivered about 3x slower than my first attempts at a multi-file PHP templating system that loaded about 20 files with slightly larger images.

      And another of course... the whole reason that I hand-code PHP is to be speedy and efficient. If I wanted it to be easy and slow, I'd use M$ or Dreamweaver or some other garbage.

      Besides, I think that a lot of what was said in the first post is offset by the fact that half of it probably happens in RAM? ie; RAM Disk?

      I am not saying that one should ignore the possible ramifications for each and every decision one makes with regards to queries and file calls, but I think that perhaps the issue that this sticky address are not really what should have been addressed. Looping structures, remote content loads, image sizes... things like that are more likely to effect performance.

      One thing that will certainly slow your pages down is using a lot of drop boxes for countries, etc... all that extra HTML will slow you down. Although, I did recently write an admin module that is noticeably slower.. it is not because it uses a lot of files, but because it actually reads multiple directory contents for each row of a table and there is some recursive SQL as well. In other words, it is not the general process of loading multiple files that takes a long time (esp since we're prolly on ext3), but manually manipulating the content of directories will. And, in other words, I need to recode it.

      I notice now this is a rather stale post.. anyone care to enlighten us on most efficient file and string functions? Ie;, regex != php->fast. :>
      Last edited by Camo.Fish; 09-09-2008, 02:59 PM.