LAMP system performance tuning-Performance Measurement

Article Title: LAMP system performance tuning to measure performance. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

LAMP performance measurement
Continuously Measuring performance is helpful in two aspects. First, measurement can help you understand performance trends, including good and bad trends. As a simple method, you can check the CPU usage of the central processing unit (CPU) on the Web server to see if the CPU is overloaded. Similarly, you can view the total bandwidth used in the past and infer future changes to help determine when network upgrades are required. These measurements are best considered in conjunction with other measurements and observations. For example, if you complain that the application is too slow, you can check whether the disk operation has reached the maximum capacity.
The second purpose of performance measurement is to determine whether optimization is helpful to the system or worse. The method is to compare the measurement results before and after modification. However, for effective comparison, only one setting should be modified each time, and then appropriate indicators should be compared to determine the effect of the modification. The reason for modifying only one setting at a time should be obvious: the two modifications made at the same time may affect each other. The indicators used for comparison are more subtle.
The selected indicator must reflect the response that the Application User feels. If the goal of a modification is to reduce the memory usage of the database, canceling Various Buffers will certainly help, but this will sacrifice the query speed and application performance. Therefore, you should select indicators such as application response time, which will enable the tuning to be in the correct direction, not just for database memory usage.
Application response time can be measured in many ways. The simplest method may be to use the curl Command, as shown in Listing 1.
Listing 1. Using cURL to measure the response time of a Web site
$ Curl-o/dev/null-s-w % {time_connect }:%{ time_starttransfer }:%{ time_total }\
Http://www.canada.com
0.081: 0.272: 0.779
Listing 1 shows how to execute curl commands on a popular news site. The output is usually HTML code, which is sent to/dev/null through the-o parameter. The-s parameter removes all status information. The-w parameter allows curl to write the timer status information listed in table 1:
Table 1. Timer used by curl
Timer description
Time used by time_connect to establish a TCP connection to the server
Time_starttransfer time used by the Web server to return the first byte of data after the request is sent
Time_total time used to complete the request
These timers are relative to the start time of the transaction, or even prior to the Domain Name Service (DNS) query. Therefore, after a request is sent, the time used by the Web server to process the request and start sending back data is 0.272-0.081 = 0.191 seconds. The time used by the client to download data from the server is 0.779-0.272 = 0.507 seconds.
By observing curl data and its changing trend over time, you can better understand the responsiveness of the site to users.
Of course, a Web site is not only composed of pages. It also includes images, JavaScript code, CSS, and cookies to process. Curl is suitable for understanding the response time of a single element, but sometimes you need to know the loading speed of the entire page.
For the Tamper Data extension of the Firefox browser (see the link in reference section), you can record each request sent by the Web browser in the log and display the download time of each request. To use this extension, select Tools> Tamper Data to open the Ongoing requests window. Load the page to be checked, and then you will see the status of each request sent by the browser and the time it took to load each element. Figure 1 shows the result of loading the developerWorks homepage.
Figure 1. request details for loading the developerWorks Homepage

 
Each row describes the loading of an element. The displayed data includes the request time, loading time, size, and result. The Duration column lists the time used to load the element, and the Total Duration column lists the time used by all child elements. In Figure 1, the time taken to load the primary page is 516 ms (ms), but the time taken to load everything and display the entire page is 5101 ms.
The Tamper Data extension has a useful mode for drawing the output of page load Data into a graph. Right-click anywhere in the upper part of the Ongoing requests window and select Graph all. Figure 2 shows the graphical view of the data in figure 1.
Figure 2. graphical view of requests used to load the developerWorks Homepage

 
In Figure 2, the duration of each request is displayed in dark blue and relative to the start time of page loading. Therefore, we can see which requests have slowed the loading of the entire page.
Through the description in the article and the powerful illustration in the image, we clearly know the second step of LAMP system performance tuning: Measuring Performance