Client side optimization in PHP. PHP optimization is the main feature of professional code. "Crooked" use of databases

The topic of this article is the fact that using FastCGI in PHP does not speed up the loading time of PHP code compared to, for example, mod_php.

Most traditional Web programming languages ​​(Perl, Ruby, Python, etc.) support writing scripts that work in the so-called “FastCGI mode”. Moreover, Ruby on Rails, for example, cannot be used at all in CGI mode, because it spends tens of seconds connecting all its numerous libraries.

Below I will talk about a method that allows, in some cases, to speed up the loading of voluminous PHP code by more than 20 times, without side effects or significant inconvenience. But first, let's talk about the basics...

What is FastCGI?

First, let's talk about what is called the “classic” FastCGI, which is used in C, Perl, Ruby, etc. In PHP, FastCGI has its own characteristics, we will look at them a little later. Now we are talking about non-PHP.

FastCGI works like this: the script is loaded into memory, runs some heavy initialization code (for example, including large libraries), and then enters a loop processing incoming HTTP requests. The same script process processes several various requests one after another, which differs from working in CGI mode, when a separate process is created for each request, “dying” after processing is completed. Usually, after processing N requests, the FastCGI script ends so that the server restarts it again in a “clean sandbox”.

To speed up processing, of course, not one script process starts, but several at once, so that each subsequent request does not wait for the previous one to be processed. Both the number of simultaneously launched processes and the number of sequential requests per process can be set in the server configuration.

Old scripts written with CGI in mind need to be modified so that they can work in a FastCGI environment (applies to using FastCGI in C, Perl, etc.; no modification is needed in PHP, but this has its drawbacks, see below) . Indeed, before, the script started each time “from scratch,” but now it has to deal with the “garbage” that was left over from the previous request. If previously a CGI script in Perl looked like

useSomeHeavyLibrary; print "Hello, world!\n";

then after modification for FastCGI it becomes like something like

useSomeHeavyLibrary; while ($request = get_fastcgi_request()) ( print "Hello, world!\n"; )

This results in savings in response speed: after all, every time a request arrives, the script does not need to execute “heavy” library initialization code (sometimes taking tens of seconds).

FastCGI has a significant drawback: a new request begins to be processed not in a “clean” environment, but in the one that remains “from last time”. If a script has memory leaks, they gradually accumulate until it crashes. The same applies to resources that they forgot to release ( open files, database connections, etc.). There is one more drawback: if the script code has changed, you have to somehow inform the FastCGI server about this so that it “kills” all its processes and starts again.

Actually, the “initiate once, process many requests” technique works not only in FastCGI. Any server written in the same language as the script running under it uses it implicitly. For example, the Mongrel server is written entirely in Ruby precisely in order to quickly run Ruby On Rails under it. The Apache Tomcat server, written in Java, quickly executes Java servlets because... does not require their reinitialization. mod_perl technology is also based on the fact that Perl code is not unloaded between requests, but remains in memory. Of course, all of these servers have the same problems with unpredictability, memory leaks, and difficulty restarting as the FastCGI application.

Why FastCGI doesn't speed up PHP

You've probably heard that PHP can also be run in FastCGI mode, and that many high-load projects do this (Mamba, some Mail.Ru projects, etc.). This supposedly gives a "significant boost" in performance because (according to rumors) FastCGI saves time on script initialization and library inclusion.

Don't believe it! In reality, PHP's FastCGI support is purely nominal. More precisely, it does not provide advantages in the sense in which it is used to be used to reduce script initialization time. Of course, you can run a PHP FastCGI server and even have nginx or lighttpd work with it directly, but the speedup you get from loading code will be zero. Heavy PHP libraries (for example, Zend Framework) took a long time to load in mod_php or CGI modes, and will continue to load for a long time in FastCGI mode.

Actually, this is not surprising: after all, in order to run any PHP script in FastCGI mode, you do not have to modify it. Not a single line of changed code! When I first decided to experiment with FastCGI in PHP, I spent several hours searching the Internet for information on exactly how to modify PHP code to optimally run it in FastCGI mode. I studied all the PHP documentation and several dozen PHP developer forums, even looked source PHP, but haven't found a single recommendation. Having previous experience with FastCGI in Perl and C, I was incredibly surprised. However, everything fell into place when it turned out that there was no need to change the code and, although several connections are processed within one FastCGI process, the PHP interpreter is initialized anew each time (unlike the “classic” FastCGI). Moreover, it seems that most PHP developers who happily use FastCGI+PHP are not even aware that it should work any differently...

eAccelerator: Accelerating PHP Code Reloading

Every time a PHP script receives control, PHP compiles (more precisely, translates) the script code into an internal representation (bytecode). If the file is small, the translation occurs very quickly (Zend Engine in PHP is one of the leaders in translation speed), however, if the included libraries “weigh” several megabytes, the translation is delayed.

There are a number of tools that cache in shared space. random access memory(shared memory) translated internal representation of PHP code. Thus, when the PHP file is re-enabled, it is no longer translated, and the bytecode is taken from the cache in memory. Naturally, this significantly speeds up the work.

One such tool is eAccelerator. It is installed as PHP extensions(connected in php.ini) and requires minimal configuration. I recommend enabling the bytecode caching mode exclusively in RAM and disabling compression (set the parameters eaccelerator.shm_only=1 and eaccelerator.compress=0). Also install and configure the control.php control panel that comes with the eAccelerator distribution to monitor the cache status in real time. Without control panel It will be very difficult for you to carry out diagnostics if the eAccelerator does not work for some reason.

The advantage of eAccelerator is that it works very stable and fast even on large volumes of PHP code. I've never had any problems with this tool (unlike Zend Accelerator, for example).

“My script together with libraries takes up 5 MB, what should I do?..”

Do you think 5 MB of code is too much for PHP? Nothing like this. Try systems like Zend Framework and Propel to see otherwise. The entire Zend Framework takes up about 5 MB. The classes generated by Propel are also quite large and can take up several more megabytes.

Many people will laugh at this point and say that there is no need to use Zend Framework and Propel, because... they are slow. But the reality is that they are not even slow at all... The method that by default uses PHP to load code has poor performance. Fortunately, the situation is not difficult to correct.

In order not to be unfounded, I will present the results of a small test that I specifically conducted in a “clean” environment, not tied to any specific project. The connection speed of all Zend Framework files (with the exception of Zend_Search_Lucene) was tested. All require_once calls were previously removed from the code, and dependencies were loaded only through the autoload mechanism.

So, in total, 790 PHP files were connected with a total volume of 4.9 MB. Quite a lot, right? The connection went something like this:

function __autoload($className) ( $fname = str_replace("_", "/", $className) . ".php"; $result = require_once($fname); return $result; ) // Connect the classes one by one in order of their dependencies. class_exists("Zend_Acl_Assert_Interface"); class_exists("Zend_Acl_Exception"); class_exists("Zend_Acl_Resource_Interface"); class_exists("Zend_Acl_Resource"); // ... and so on for all 790 files

Because autoload is used, calling class_exists() forces PHP to include the appropriate class file. (This is the easiest way to “pull” the autoload function.) I chose the connection order in such a way that each subsequent class already had all its dependent classes loaded at the time of launch. (This order is easy to establish by simply printing the value of $fname in the __autoload function to the browser.)

Here are the test results with and without eAccelerator on mine, not very good powerful laptop(Apache, mod_php):

• Connecting all files one at a time, eAccelerator disabled: 911 ms.
• Connecting all files one by one, eAccelerator enabled: 435 ms. 15 M of cache memory is occupied for bytecode.

As you can see, eAccelerator gives approximately 2x speedup on 790 files with a total volume of 4.9 MB. A bit weak. In addition, 435 ms is clearly too much for a script that does nothing but include libraries.

Now let's add some steroids

Rumor has it that PHP loads one large file much faster than ten small ones of the same total size. I decided to test this claim by combining the entire Zend Framework into one 4.9 MB file and connecting it with a single require_once call. Let's see what happened.

• Enabling one large merged file, eAccelerator disabled: 458 ms.
• Enabling one large merged file, eAccelerator enabled: 42 ms. 31 MB of bytecode cache is occupied.

The first line says that one large file of 4.9 MB in size actually loads faster than 790 small ones: 458 ms versus 911 ms (see above). 2x savings.

But the second line made me jump in my chair in surprise and double-check the result several times. I hope the same happens to you. Indeed, 42 ms is 11 times faster than with eAccelerator disabled! It turns out that eAccelerator loves small files even less (by the way, even in eaccelerator.check_mtime=0 mode): 11-fold savings.

So, we actually got 22x faster loading times, just as promised in the title. Previously, the entire Zend Framework, divided into files, took 911 ms to connect, and using eAccelerator and combining all the files into one - 42 ms. And this, mind you, is not on a real server, but just on an ordinary laptop.

Conclusion: 22 times faster

Let's summarize.

• Merge all files into one big one plus enable eAccelerator for this large file gives a 22x speedup with a code size of 4.9 MB and the number of files 790.
• For a small number of large files, eAccelerator can provide 10x speedup. If there are a lot of files and the total volume is large, then the speedup is approximately 2 times.
• Cache memory consumption depends on the number of partition files: for a fixed size, the more files there are, the less consumption.

With all this, eAccelerator does not have the main problems of a “real” FastCGI server. Scripts are free of memory leaks and run in a guaranteed “clean” environment. You also do not need to monitor code changes and restart the server every time modifications are made to the more or less deep code of the system.

Note also that we included the entire Zend Framework. In real scripts, the amount of code will be much less, because Typically only a small portion of ZF is required for operation. But even if the libraries occupy 4.9 MB, we get a loading time of 42 ms - quite acceptable for a PHP script. After all, in busy projects, PHP scripts can work for several hundred milliseconds (Facebook, My Circle, etc.).

Of course, if you plan to run FastCGI in PHP not for performance reasons, but simply to avoid being tied to Apache and limit yourself to the “nginx+PHP” or “lighttpd+PHP” combination, nothing prevents this. Moreover, by using eAccelerator for FastCGI+PHP and merging many code files into one large one, you will get the same acceleration that I described above. However, do not flatter yourself with hopes that it was FastCGI that gave the acceleration: this is not so. Using mod_php+eAccelerator, you would achieve almost the same result as FastCGI+eAccelerator.

Manually merging all library files into one is a tedious task. It is better to write a utility that will automatically analyze the list of PHP files included by the script, and the next time it is launched, combine these files and write them to a temporary directory (if this has not already been done), and then connect them using require_once. Today I leave the writing of such a utility (give or take details) to the reader’s conscience.

I also recommend that you abandon the explicit inclusion of files using require_once and switch to autoload. Just don’t try to use Zend_Loader for this: it is very slow (according to my measurements, connecting a hundred files will take about 50 ms extra). It’s better to write your own simple autoload function that will quickly do all the work. Autoload will allow you to safely combine multiple library files into one without having to worry about how to deal with manual require_onces.

Finally, use the set_include_path() function so that the library inclusion code looks like this:

require_once "Some/Library.php";

require_once LIB_DIR . "/Some/Library.php";

Constants that explicitly define the path to the library directory are a big evil and complicate the program. They also indirectly contradict the Zend Framework and PEAR coding standards, which I also recommend adhering to whenever possible.

So, if you want to use “heavy” libraries in PHP scripts, good luck! PHP is a scripting language that truly allows you to do this without regard to the inconveniences of FastCGI and the problems of “built-in” servers.

When developing large projects, the question of optimizing the project code gradually arises: how justified is the memory consumption, how can you increase the execution speed of the written PHP code. At first, many people do not think about the correctness and efficiency of the written code; they write according to the principle: it works - and that’s okay. Although the PHP interpreter is quite fast at executing PHP code, and there are many bottlenecks that slow down code execution that are outside of PHP, PHP code optimization is also important, and code optimization should be applied early in the coding process .

Most PHP scripts do simple steps. The standard behavior of the script is to download a small amount of information from the user, retrieve some information from a database or file, output the appropriate HTML, and send the result to the client. Here, the first thing you need to understand is what exactly should be the result of optimization: performance, ease of scaling, reducing the amount of server resources used, reducing data transfer time, or all together. In the latter case, it is necessary not only to find all critical areas, but also to balance their optimization.

Let me give you a simple example: let there be two scripts on a server with 100 MB of free RAM, the result of which is the same. The first script is optimized for maximum performance, requires 10 MB of memory and receives data from a file by reading it completely, the second is optimized for minimal memory consumption, requires 5 MB of memory and receives data from the same file in parts. As a result of one request, the first script will be executed faster than the second, but if there are more than ten requests at the same time, it is the speed of the second script that will become higher. Why is this happening? In the first script, the bottleneck is the use of memory resources, in the second - the features of the I/O system. After the first script consumes all available RAM, the system will switch to using virtual memory, and the same I/O system will become an additional bottleneck of this scheme.

Of course, this example is greatly simplified, and there are other bottlenecks besides RAM, but the main idea is this: optimization for one case can become a critical point in another. In the example, as a result of optimization for a slight increase in speed at low loads, the speed of script execution at higher loads significantly decreased. Therefore, to get better returns, it is important to spend your energy optimizing the areas that truly deserve attention.

I will not consider here optimizing the operating system, optimizing server settings, etc., because... Most webmasters use hosting and, accordingly, will not be able to set everything up on their own. Only PHP code optimization will be considered here. It should be noted that in each specific case, some types of optimization will be useful, others will be a waste of time and effort. Often the benefit of improving the code will be negligible. Perhaps, over time, internal changes in PHP will render successful optimization useless or even harmful.

Below are the main performance steps for PHP 5 version:

Actions to optimize RAM consumption:

1. Analyze the results of your functions. Before writing a function, check to see if there is a standard equivalent.
2. Freeing memory when large arrays or objects are finished being used only in the global scope (memory will be freed automatically in the local scope). Please note that the function unset() removes a variable from the scope and, only if there are no other references to the object, frees the memory occupied by the object. Assignment value variable null always destroys the object and frees the memory occupied by the object, regardless of whether there are still references to this object. In this case, the variable will not be removed from the scope, i.e. in fact, the variable will contain an undefined (zero) value and, accordingly, will occupy memory for the contents of this variable (about 72 bytes).
3. Analysis of the justification for using OOP (object-oriented programming). Before writing object-oriented code, ask yourself two questions: “Does this require an object-oriented approach?” and “can I write object-oriented code?” For example, defining a static function inside a class increases the amount of memory required just to contain that function by 10-18%. Using an array rather than a class as the structure also saves memory. It may be more profitable to simply put the functions in a separate file, rather than implement them as class methods.
4. Analysis of the possibility of implementing a static version of a method in a class. If the method does not use a parameter $this, then it must be declared using the keyword static.

Actions to increase code execution speed:

1. Analysis of SQL query optimization. In most projects, it is the optimization of SQL queries that gives greatest increase productivity.
2. Using output buffering and various caching modules can increase performance by 25% -100%.
3. Using shorter short names for variables, functions, constants, and classes can improve performance by up to 20%. At the same time, do not forget about further code support, telling name functions are much more convenient when modifying code.
4. Checking the existence of a variable (function isset()) before contacting her. Suppressing the error that occurs when accessing a non-existent variable by using @ is a huge performance hit.
5. Using "single quotes" allows you to interpret the code faster, because in the case of “double quotes”, variables are searched inside the string
6. Analysis of the possibility of removing “extra” functions from the loop. For example, replacing a function count() to a variable calculated before the start of the loop and containing the result of this function, in the expression for($i=0; $i will increase the productivity of this cycle. Otherwise the function count() will be called and executed on every iteration of the loop.
7. Using the operator case instead of using multiple constructs if...else.
8. Using explicit access to array fields. Reversal of the form $array["id"] runs 7 times faster than reversal $array. In addition, this protects against errors during further support of the script, because one day there might be a constant named id.
9. Using an additional variable containing a reference to the final array when processing multidimensional arrays in a loop. To speed up the cycle for($i = 0; $i< 5; $i++) $a["b"]["c"][$i] = func($i); , before the start of the loop it is possible to write the next instruction $item =p$a["b"]["c"] and rewrite the loop like this: for($i = 0; $i< 5; $i++) $ref[$i] = $i; .
10. Using the Apache mod_gzip and mod_deflate modules allows you to reduce traffic, thereby increasing page loading speed.

The following code optimization steps improve performance only when used repeatedly: