Improving the Speed of PHP Web Scripts
PHP web scripts lose performance for a lot of reasons. The bottleneck can be in database queries, web page access or even slow algorithms. When performance drops, the user gets frustrated waiting for results. Less users mean less business, and your web site becomes unpopular.
The main reason for performance loss is bad software analysis and engineering. Web sites often are created and launched without thorough performance testing. Databases often are designed to accommodate less data than they actually do. Algorithms often are designed poorly and usually are not optimized for speed.
When you cannot redesign the entire web design so that it runs more quickly, you must improve its performance by serving static pages instead of interpreting PHP whenever there's a hit. Let's look at the ways to achieve this goal.
The first thing that you can do is preprocess those PHP scripts, or script parts, that take more time to execute. You can do it with the help of a PHP shell. Suppose you have a web script called index.php, and you want to preprocess it. Assuming that the PHP shell is called phpsh, the command line is:
phpsh -q /some_dir/index.php > /some_dir/index.html
The file index.html is now plain HTML and doesn't need any PHP processing. You can serve it right away to the web client. But what if the PHP script results change over time? You'd have to preprocess the script every time the results are different. The solution is to preprocess the PHP script periodically.
In Linux, the easiest way to execute a given process periodically is called crontab. The following crontab entry illustrates a preprocessing that would execute every 15 minutes:
*/15 * * * * root phpsh -q /some_dir/index.php > /some_dir/index.html
However, the chosen timing might not be enough to keep the information updated. Furthermore, some scripts are not accessed over long periods of time, while others are constantly accessed, making the use of this technique pointless. In this case, a script-based mechanism is needed.
This technique preprocesses scripts periodically, but only if they are accessed. It works much like a web proxy caching system. I will show two ways of implementing this functionality: output buffering and after-time processing.
Output buffering checks the cache file date and time and only processes the script if needed. The processing is done by buffering the output and saving it in the cache file before it is sent to the client.
In PHP you do this with the help of the ob_start() function. This function will turn output buffering on and send it to a callback function. There is another function to send the buffer back to the browser: ob_end_flush(). Let's take a look at an example:
<?php // include header file include("header.php"); ?> <?php // sleep for 10 seconds sleep(10); ?>
<?php // include footer file include("footer.php"); ?>Inside header.php, you'll find all the cache processing. It begins by checking whether the script needs caching by calling the needscache() function. This function can check the need for cache based on a time out or based on anything you like. For the purpose of this article, the checking is based on cache time out.
If the script needs caching, the ob cycle is started, and the script output is written into the cache file. If it doesn't need caching, the script output is read from the cache file and sent to the client's browser (see Listing 1).
The footer.php script simply closes the ob processing:
<?php ob_end_flush(); ?>
You can test this technique by calling the script many times before the cache times out. You'll notice that in the first call you'll have to wait ten seconds (this is because the script sleeps for ten seconds, for testing purposes), and in the following calls the output is immediate.
However, when the cache times out, you'll have to wait for the script to finish processing. Let's see how you can prevent this and give the user the illusion that the script is always fast.
After-view processing also checks the cache file date and time, but the processing is done after the file is served, solving the cache time out processing burden. This is done by caching the file after the script ends execution.
In PHP, you can do this by associating an arbitrary function with the script termination event through the register_shutdown_function(). The only file you'll have to change is header.php (see Listing 2).
I simply added the doaftercache() function that is called only after the script finishes. It then calls the script like a normal browser does and caches it. The only time you'll have to wait is when the script has never been cached before. Test it and you'll get the feeling that the script is very fast.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Interview with Patrick Volkerding
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide