Improving PHP Performance for Web Applications

php performance

Programmers love the latest version of PHP because it’s one of the faster scripting languages (check out our PHP 7 vs HHVM post), but maintaining optimal performance requires more than quickly executing code. The best tool for improving PHP performance isn’t any individual program; it’s knowing which problems to look for and how to address them. This guide will cover everything you need to know to ensure that your PHP applications always run smoothly.

A Brief History of PHP

PHP is a scripting language invented by Rasmus Lerdorf in 1995. Initially intended for the developer’s personal use, “PHP” was originally an acronym for “Personal Home Page.” However, as Lerdorf expanded its functionality, PHP came to stand for the recursive acronym “PHP: Hypertext Preprocessor.”

Over the past two decades, the PHP Development Team has overseen many advancements in PHP’s performance, most notably with the introduction of the Zend Engine in 1999. PHP 4, which was released in 2000, included an in-memory compiler and executor model that enabled PHP to be used for creating dynamic web applications. In 2015, PHP 7.0 was released with updates including improvements to the Zend Engine and an overall reduction in memory use. At the time of writing this article, the newest available version is PHP 7.1, which was announced in December of 2016. The PHP Classes website contains extensive details about all of the changes made between PHP 5 and PHP 7.1.

What Exactly is Good PHP Performance?

Performance and speed are not necessarily synonymous. Achieving optimal performance is often a balancing act that requires trade-offs between speed, accuracy, and scalability. For example, while building a web application, you may have to decide between prioritizing speed by writing a script that loads everything into memory up front or prioritizing scalability with a script that loads data in chunks.

Based on a representation from phplens, the image below depicts the theoretical trade-off between speed and scalability:

php speed scalability

The red line represents a script optimized for speed, and the blue line is a script that prioritizes scalability. When the number of simultaneous connections is low, the red line runs faster; however, as the number of users grows, the red line becomes slower. The blue line also slows down when traffic rises; however, the decline isn’t as drastic, so the script tuned for speed actually becomes slower than the script tuned for scalability after a certain threshold.

A real world analogy would be the comparison between a sprinter and a cross-country runner. Sprinters are much faster when running short races, but they tire out in longer competitions. Cross-country runners keep a slower but more consistent pace, which allows them to conserve energy and travel longer distances. The two athletes are better suited for different situations. Likewise, some scripts work better in different scenarios. Choosing the right one for your application will require careful consideration of your users. You may have to adjust scripts over time as your traffic increases.

When to Begin Optimizing PHP Code

Experienced programmers sometimes save the fine-tuning of code for the end of a project cycle. However, this is only advisable if you are certain of your PHP application’s performance parameters. A more sensible approach is to conduct tests during the development process; otherwise, you may find yourself rewriting large chunks of code to make your application function properly.

Before you start designing a PHP application, run benchmarks on your hardware and software to determine your performance parameters. This information can guide your coding by helping you weigh the risks and benefits of specific trade-offs. Be sure to use adequate test data, or else you could create code that doesn’t scale.

Tips for Optimizing PHP Scripts

Writing good code is the essential first step to creating PHP applications that are fast and stable. Following these best practices from the beginning will save time on troubleshooting later.

1. Take Advantage of Native PHP Functions

Wherever possible, try to take advantage of PHP’s native functions instead of writing your own functions to achieve the same outcome. Taking a little while to learn how to use PHP’s native functions will not only help you write code faster, but will also make it more efficient.

2. Use JSON Instead of XML

Speaking of which, native PHP functions such as json_encode( ) and json_decode( ) are incredibly fast, which is why using JSON is preferable to using XML. If you are committed to XML, be sure to parse it using regular expressions rather than DOM manipulation.

3. Cash in on Caching Techniques

Memcache is particularly useful for reducing your database load while bytecode caching engines like APC or OPcache are great for saving execution time when scripts get compiled.

4. Cut Out Unnecessary Calculations

When using the same value of a variable multiple times, calculate and assign the value at the beginning rather than performing calculations for every use.

5. Use isset( )

Compared to count( ), strlen( ) and sizeof( ), isset( ) is a faster and simpler way to determine if a value is greater than 0.

6. Cut Out Unnecessary Classes

If you don’t intend on using classes or methods multiple times, then you don’t really need them. If you must employ classes, be sure to use derived class methods as they are faster than methods in base classes.

7. Turn Off Debugging Notifications

Alerts that draw your attention to errors come in handy during the coding process, but they become just one more process that slows you down after launch. Disable such notifications before going live.

8. Close Database Connections

Un-setting variables and closing database connections in your code will save precious memory.

9. Limit Your Database Hits

Making queries aggregate can reduce the number of hits to your database, which will make things run faster.

10. Use the Strongest Str Functions

While str_replace is faster than preg_replace, the strtr function is four times faster than str_replace.

11. Stick With Single Quotes

When possible, use single quotes rather than double quotes. Double quotes check for variables, which can drag down performance.

12. Try Three Equal Signs

Since “= = =” only checks for a closed range, it is faster than using “= =” for comparisons.

Types of Bottlenecks That Affect PHP Performance

Tinkering with your scripts can certainly be beneficial. However, there are also issues that have nothing to do with code which can also hinder PHP performance. This is why developers need a thorough understanding of their server’s subsystems to identify and address bottlenecks. Below are areas you should check if you’re having performance issues.

1. The Network

One obvious source of bottlenecks are networks. Depending on your current network’s capacity, it may lack the power to handle the amount of data being transmitted.

2. The CPU

Transmitting plain HTML pages across a network doesn’t drain your CPU, but PHP applications do. Depending on your requirements, you may at least a server with multiple processors to process your PHP code efficiently.

3. Shared Memory

A lack of shared memory can disrupt inter-process communication, which can lead to lagging performance.

4. The Filesystem

Your filesystem can become fragmented over time. A file cache that uses RAM can speed up disk access so long as there’s enough memory.

5. Process Management

Make sure your server isn’t overburdened with unnecessary processes. Remove any unused networking protocols, antivirus scanners, mail servers and hardware drivers. Running PHP in multi-threaded mode can also result in better response times.

6. Other Servers

If your application depends on outside servers, a bottleneck on the other server can slow you down. There’s not much you can do in such scenarios, but you can make alterations on your side to mitigate deficiencies on the other end.

More Tips for Improving PHP Performance

1. Take Advantage of OPCache

Since PHP is interpreted into executable code extemporaneously, programmers don’t have to pause to compile code every time they make a small change. Unfortunately, recompiling identical code every time it runs on your website slows performance, which is why opcode cache, or OPCache is very useful.

OPCache is an extension that saves compiled code into memory. Therefore,
the next time the code executes, PHP will check timestamps and file sizes to determine if the source file has been altered. If it has not, the cached code will run.

The image below shows the difference in execution time and memory usage between a PHP application running with no cache, OPcache, and eAccelerator (another PHP caching tool).

opcache

Source: Prestashop

2. Identify Database Delays

As discussed above, performance problems are not always caused by code. Most bottlenecks occur when your application must access resources. Since the data access layer of a PHP application can account for up to 90 percent of execution time, one of the first steps you should take is to look at all instances of database access in your codebase.

Make sure slow SQL logs are turned on to help you identify and address slow SQL queries, and then query the queries to assess their efficiency. If you discover that too many queries are being made, or if you find that the same queries are being made several times during a single execution, you can make adjustments that boost your application’s performance by cutting down on database access time.

3. Clean Up Your Filesystem

Skim your filesystem for inefficiencies, and make sure the filesystem isn’t being used for session storage. Most importantly, keep an eye out for code that can trigger a file stat such as file_exists(), filesize() or filetime(). Leaving any of these functions in a loop can lead to performance issues.

4. Carefully Monitor Your APIs

Most web applications that depend upon external resources leverage remote APIs. Although remote APIs are out of your control, there are actions you can take to mitigate problems stemming from API performance. For example, you can cache API output or make API calls in the background. Establish reasonable timeouts for API requests and, if possible, be prepared to display output without an API response.

5. Profile Your PHP

Using OPcache and managing your external resources should be enough to make most applications run smoothly; however, if you find your needs increasing, it might be time to profile your PHP. A full PHP code profile can be time-consuming, but it can supply you with in-depth information about your application’s performance. Thankfully, there are a handful of open source programs for profiling your PHP code such as Xdebug.

The Importance of Monitoring PHP Performance

Your web application may be running fine at one minute, but a sudden barrage of traffic can cause your application to crash if you’re unprepared. Of course, making changes always requires time, effort and money, and it can be difficult to tell if the investment is worth it. The best way to make informed decisions is to continually collect data.

PHP performance monitoring software can help you immediately measure the effects of any changes you make. Of course, knowing what to measure is equally important. Speed and memory usage are considered the best indicators of performance because they impact page load times, which are critical to web applications.

While data collection is important, you should turn off your monitoring system when you don’t need it because an influx of logs can slow things down. Of course, such logs give you valuable information about how to improve performance, so you should periodically monitor during peak traffic periods.

The Future of PHP Performance

The evolution of PHP is ongoing. The newest feature currently in the works for PHP 8 is Just-In-Time compilation, or JIT, which will allow for the creation of even faster web applications. As the rate of technological advancements increases, so do users’ expectations. Therefore, developers must always keep one eye on the coming changes.

When building web applications, remember that what works today might not work next year. You may have to make adjustments to maintain consistent PHP performance. Focusing on the big picture during the entire development process is the best strategy for building PHP apps and websites that work for the masses.

Related Articles

Improving PHP Performance for Web Applications was last modified: March 23rd, 2017 by Cody Arsenault
  • Taylor Liesnham

    Interesting point with the isset() function, I didn’t know that. Really looking forward to PHP8!

  • Greg Jorgensen

    The isset() function does not test for a 0 value, an empty string, or an empty array. It can’t replace strlen() or count(). $foo = 0; isset($foo) is true. $foo = “”; isset($foo) is true. $foo = []; isset($foo) is true. isset() tests if a variable is set (i.e. defined) or not, it doesn’t check the value or contents. Maybe you are thinking of empty().

    Parsing XML with regular expressions is a terrible idea. It will only work for the most trivial XML schema.

    The single quote vs. double quote thing is a myth. There’s no real-world difference. See https://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html for example.

    strtr() is not “four times faster” than str_replace(). It depends on the strings, and the two functions don’t do the same thing. See http://stackoverflow.com/questions/7620549/php-strtr-vs-str-replace-benchmarking

    Some of your advice are what’s called micro-optimizations. Things like single or double quotes, or strtr() vs. str_replace() or using === are unlikely to create measurable differences in performance or speed. Focusing on stuff like that means you’re likely to miss out on the big performance hogs, like poorly-designed database, bad SQL queries, calculations and I/O operations inside loops, etc.

    • JK22

      The single quote thing isn’t a myth..you just don’t see the difference in simple use cases..while single quoted strings are printed directly, double quoted strings are processed for variables..you can see a difference in templating languages or long texts with lots of parameters..still the difference is small but it is there..and actually it is a best practice yo use single quotes :)

      • Greg Jorgensen

        Well, it’s been timed many times, and no significant difference, unless you are writing PHP to process hundreds of millions of strings. In which case, choose a faster language.

        Very unlikely that single- vs. double-quotes would ever make a difference in an actual application. PHP is a templating language, why add another layer? Get rid of that kind of stuff to get a performance boost. This kind of “best practice” focuses on things that aren’t going to matter. The big performance gains come from better algorithms and data structures.

        • JK22

          Not using a templating language is kind of insane nowadays..if you are not writing an API of course..it will be cached anyway..but yes..the difference will not matter..it is just that its there, its not a myth..it is just not significant..but it never hurts to follow best practices anyway

          • Greg Jorgensen

            You haven’t addressed the big problem in your article: the misinformation about isset() and the advice to parse XML with regular expressions.

            PHP *is* a templating language, with variable substitution, control structures, etc. That’s by design. Why add another layer of templating, another pseudo-language to parse for every request, another interface to make copies of variables for? The cost of that is orders of magnitude higher than single vs. double quotes, and is not a “best practice’ according to the inventor of PHP.

            Your analogy is not apt. If I give you a dollar every day eventually you have 10,000 dollars. But if I clear out your bank account every three days you will never get 10,000 dollars. PHP code runs for the duration of a single HTTP request/response, so the effects of these micro-optimizations are drowned out by the network overhead and the act of re-creating and re-interpreting code and things like class structures and templates, for every request. It’s not a best practice to add pointless overhead like frameworks and templates to a request/response architecture.

    • Ordained Bychrist

      It won’t work u can use is_null(), to test such

    • While I agree with most of your reply, isset is indeed faster if you check for the first “element” `isset($str[0])` will be faster than `0 < strlen($str)`, … and so on. But it's a micro-optimization, so not really worth it.

      • I agree. I think the algorithm/implementation (like delay in database query execution e.g) is more valuable for discussion.

Share This