Performance analysis of peripheral resources in PHP development (I)

For the moment, we will not discuss whether PHP is the best programming language. This article will analyze the backend peripheral resources and front-end peripheral resources of the PHP program, respectively, their impact on the overall PHP web application experience, this is often much larger than the language itself.

First, backend peripheral resources refer to network and I/O operations, storage services, middleware proxies, caches, and database access that are not related to the language itself during PHP running. in this article, first, we analyze IO operations and middleware services.

Why is the performance analysis of peripheral resources mainly based on the above three aspects? We can see the following overview of the PHP Web application background of OneAPM, a professional PHP performance monitoring tool in China, the total PHP response time of the database accounts for 60% or even a greater proportion, while the Memcached cache service barely sees the response time of this queue.

The following is the official start.

I. IO operations

Although the PHP language itself has performance differences, it can be seen from the micro-analysis of PHP's performance that, if only one operation is executed, this difference is very small in reality, in the previous experiment, more than 100,000 operations, there are hundreds of MS-level differences, because the PHP language itself operates the memory, a memory access, about 50ns. IO operations are disk access, which takes more than 5 ms to access a disk. From this order of magnitude alone, it is 0.1 million times the gap. In fact, according to experiments, there are also hundreds of times the gap (the gap between sequential access and random access is huge. In reality, the two are both at the same time, there will also be disk cache and so on ).

Therefore, IO is more likely to become a bottleneck than the language itself. First, let's take a look at the performance differences caused by IO operations.

A PHP script is run using the PHP command. the time consumed when the script runs normally is as follows:

After clearing the disk cache using the following command:

echo 3 | sudo tee /proc/sys/vm/drop_caches

Shows the first running time:

The code is exactly the same, but the running time is six times the normal running time. Of course, the slow time is not only caused by the IO operations of the program itself, but also caused by the larger slow speed. in CGI mode, all modules need to be loaded for every running of the PHP script, this loading is also accompanied by a large number of IO operations.

In another experiment, two pages with the same functions are split into independent templates by using MVC (the template engine is not used ), the intermediate logic is also processed using an independent Model class. The other require only has two files: macro definition and database operation.

Run the command AB-c 40-n 1000 http: // xxxxx/0929/zuche/carlist. php to perform a stress test. the stress test results are obtained after the two pages run stably.

On this page, the MVC version takes about 6-8 milliseconds. Although only a few files are added, the request latency is significantly increased. if file operations are more complex, such as file upload, detection, and conversion, the latency will increase by more than one order of magnitude. In actual production and use, it does not mean that a large latency will occur if file operations are performed, because in this example, because of the existence of disk cache, latency has been greatly reduced.

II. middleware proxy

Before using middleware, let's first compare the difference between using a database and not using a database. in the same example above, we set the data result set, get from the database and convert it to the direct result array settings. to make the structure clear, use the MVC version. At the same time, in order to make a more significant comparison with the previous test results and eliminate some slow factors in the language itself, we used PHP7 in this round of experiments, and the results were surprising. For versions with database connections and data reading, the PHP extension uses mysqli.

Since this page only has one database operation, the page structure is relatively simple, and the language itself has a huge impact factor, the speed of PHP 7 is improved by more than twice, originally, the average response time was 37-40 ms, and now it is 14 ms.

Even so, when the database is not read, there is a 4 ms gap, although the number is not large, but for an application with a total response time of only 14 ms, this 4 ms has been very significant, this is only a database query operation.

Next, let's take a look at how efficiency changes when a layer of database middleware is added? Because the middleware used by the author does not currently support PHP7, we will compare it based on the old version of PHP. Under the same server pressure, the middleware version is more than doubled. As shown in.

From this example, we can see that the operations for directly connecting PHP to the database and obtaining data have changed to middleware after middleware is added. middleware then to the database, the returned result is also true, this has led to a significant reduction in the speed (the resource occupation of the middleware itself has been removed here, and the original direct connection version is about 37-40 ms ).

Here, let us not misunderstand the example of downgrading the middleware usage speed. it is not to describe the poor middleware. in a distributed environment, it is necessary to use middleware. However, external resources of a program are often an important factor affecting performance, especially when the external resource connection and data acquisition speed cannot reach the desired result.

I/O operations and middleware services are analyzed here. the next article will analyze the impact of the database on the performance of the entire application.

OneAPM for PHP can go deep into all PHP applications to complete application performance management and monitoring, including visibility of code-level performance problems, fast identification and tracing of performance bottlenecks, Real User Experience Monitoring, server monitoring, and end-to-end application performance management.