PHP Performance Analysis Second: Xhgui in-depth

"Preface" This is a foreign well-known blogger Davey Shafik wrote the second article of the PHP Application Performance Analysis series, the first introduction Xhprof/xhgui, the third focus on performance tuning practice.

In the first article, we introduced the xhprof and how to install and run the analyzer. In this article, we will introduce Xhgui?? The user interface (UI) used to review and compare xhprof data.

Using Xhgui

Xhgui offers a number of features to assist with performance evaluation, both for a single run and for a converged environment. Let you pinpoint specific issues and identify trends.

Terms

To improve the efficiency of Xhgui, you need to be familiar with many terms:

1. Number of Calls

Number of function calls

2.[contains] actual execution time (WT)

function actual execution time

3.[contains] CPU use/CPU time (CPU)

Time elapsed for running the function CPU

4.[contains] memory usage (MU)

The amount of memory currently used by this function

5.[contains] memory usage Peak (PMU)

Memory spikes used by functions

6. The actual execution time (EWT)

7. CPU Time (ECPU)

8. Exclusive memory Usage (EMU)

9. Exclusive memory usage spikes (EPMU)

The terms 2 to 5 are all inclusive measurement indicators (although not always explicitly stated), which calculate the invocation of functions and their sub-functions. The terms 6 to 9 are the measurement indicators of the specificity type?? They only calculate the resource invocation of the function itself. All measured values are cumulative values after the function is called. (for example, if a function is called two times, the first time is 900 milliseconds, the second, because of the cache, it only takes 40 milliseconds and the final display is 940 milliseconds).

Ready to start

Once you run Xhgui on the HTTP server, you will first see:

At the top, you'll see a menu that contains:

Recent? Most recent runs (paging)

Longest wall time? Sort from slowest run based on actual execution time

Most CPUs? Start sorting from the run that consumes the most CPU time

Most Memory? Start sorting from the most memory-intensive run

Custom View? Execute MONGO DB custom query

Watch Functions? The tag function that should appear at the top of the review page

Waterfall? Viewing the interaction of concurrent requests from an experimental view

In this tutorial, I chose to analyze website performance built with Wordpress. More than 18% of Web sites on the Internet are built on WordPress, which means that even small performance improvements to WordPress can have a huge impact.

View performance data for one run

After analyzing the performance of several pages (or importing files), you will see them listed in Xhgui:

To view performance data once run, just click on the date.

By clicking the appropriate header, you can view these operations based on actual execution time (WT), CPU time (CPU), Memory usage (MU), or peak memory usage (PMU). This allows you to easily find the slowest page.

A single performance page shows quite a lot of information. On the left you can see the overall situation of the run, as well as the runtime's environment data, including GET (or POST) data and server data:

On the right, the Watch function list is displayed:

This table details the function name, number of calls, specific actual execution time (EWT), exclusive memory usage (EMU), and exclusive memory usage spikes (EPMU). In addition, you may notice two buttons at the top of the page, "View CallGraph (see call graph)" and "Compare this run".

Next, we see two graphs. Figure one shows the six functions with the longest actual execution time, which is used at the time of the function itself (not including the time taken by any child function calls). Figure two shows the six functions with the largest memory usage. These graphs can often point you to performance bottlenecks.

The details of the function are listed below. If you slide the mouse over the cylinder in the diagram, the information will also appear in the Prompt box.

Finally, we see the bulk of the information that the Performance Analyzer collects?? List of functions:

The table contains a floating title bar (even if the mouse scrolls down, the column remains at the top of the screen), including the function name, number of calls, and the previously mentioned single and included measurements.

By default, the table is sorted by a one-time, actual execution time, with the oldest being ranked first. Usually you don't want to change this order, because it lets you quickly figure out the slowest function, unless you want to see the amount of memory used.

When you want to see how a function is running, clicking on the function jumps to its detail page. The page will first show the details of the function itself recursively. Next, the "Parent Functions" section lists all functions that call the function directly. Finally, "Child Functions (sub-function)" lists other functions that the function calls directly.

The parent function lists the standard list data according to the actual elapsed time.

You need to determine whether the function itself is running slowly, or if it is called too many times to cause the cumulative actual execution time to be too long. By examining the call count of the function, and then recalling its parent function list.

If you think the number of function calls is not a problem, you should look at the function of the child functions. This is the part where the function consumes time.

The child function displays only the measured values, because you want to quickly find the longest-consuming code path.

You can click each sub-function, drill down to the same detail view, and perform the same analysis.

Compare performance data

The best feature of Xhgui is to compare two different runs. This allows you to:

• Modify the system (such as Enable Opcache, MySQL query cache) and compare the results

• Modify code (code or SQL optimizations) and compare results

• Compare the operation of an exception to a "normal" run

To compare two runtimes, you must first select a base run. Click on its date to see the details page for that run.

Next, click the Compare this Run button in the upper-right corner:

It then jumps to the run list under the same URL, and you can choose one to compare:

Click the "Compare" button that you want to compare, and you will be redirected to the Compare page.

The comparison view shows only the differences between the two runs. The two runs in the comparison are displayed at the top of the page, along with a number of buttons that assist in modifying the sort.

The following is an overview:

Although all the information in this table is useful, the two differences that are particularly noteworthy are "function calls" and "single-minded actual run time".

The difference in the number of function calls implies significant differences in the two runs: different code paths or caches. The first difference may be due to intentional optimization, but if this is not your goal, comparing these two runs is likely not to be of much value. caching, on the other hand, is a useful and effective way to improve performance. This comparison makes it easy to verify that the cache is occurring.

The percentage difference that includes the actual execution time shows the actual results of performance tuning. Ideally, we will see a smaller percentage?? This is the ratio of the second run time to the first run time. In, the second run only took the first run of 79% of the time, which means a performance increase of 21%.

Finally, we see the feature details:

Keep in mind that this view only shows the difference. The difference is expressed by a negative number in green and a positive number in red. (negative numbers indicate fewer calls, less actual execution time, shorter CPU time, or less memory consumption) if there is no difference, it is grayed out 0.

As with other tables, you can sort on any column, and the default order is the call order of the function.

Here you can verify that the changes you have made have a real effect and are expected to be effective. You can also use this view to track the cause when performance drops.

A good example of performance improvement is that only one function is called based on a condition?? For example, you may not need to filter the data if it has been done before.

When you make this change, you expect the number of calls to the filter function to be reduced, thereby improving performance.

These two things can be verified here, and other unexpected reasons?? Does your condition take longer than the filter itself? If so, this has a negative impact on performance.

Here we can see that the number of calls to Noop_translations::translate and Apply_filter has been reduced, but the exclusive memory usage of Apply_filter has increased by 133,560 bytes!

Discover trends

For me, the most powerful feature of Xhgui is viewing trends. Because Xhprof is a passive analyzer that can be enabled in all environments (Dev, QA, staging, production), you can continuously sample traffic for analysis.

To review all the data for a given URL, simply click it on the Run list:

This will jump to the URL to run the page.

This page displays two important charts. The first shows the actual run time and CPU time, the second shows memory usage and peak memory usage. The data that is run in these chart lists, including the URL for each run, time, actual run time, CPU time, memory usage, and peak.

These graphs are key to viewing trends and outliers. But how do you deal with this information?

For data anomalies, first you can hover your mouse over it Yue Heyue, and then you can look at its single run. or compare it with other normal operations to find the difference.

For trends, the best option is to review when the trend starts?? Did you add the cache at this point? As the cache becomes more complete, the overall trend should be downward. Or if your cache fails, you will see an uptrend, when the cache is rebuilding.

By default, these charts show the last 100 runs, and you can click on the next page to see how much more time is running.

Alternatively, you can click the Search button to customize the displayed interface:

Click the button to display the search form:

You can search for a run between specific dates. You can also view the last 30 minutes, 1 hours, 2 hours, 12 hours, 24 hours, 1 weeks, 2 weeks, or 30 days of operation?? Smaller intervals are suitable for evaluating the results of performance tuning.

Finally, you can specify a custom time interval using the PHPs datetimeintervalinterval specification format?? For example, p2d can be used in the last 2 days and pt15m can be used in the last 15 minutes.

Watch Functions

Watch functions allows you to identify specific functions, or groups of functions, from a regular expression and display them on a single run page (see previous article).

Because regular expressions can be used, we can easily see the functionality in a module or extension.

For example, to watch all MySQL activity, simply add one of the following:
For example, to view all MySQL activities, simply add any one of the following lists:

• Mysql_ (. *) for Ext/mysql

• Mysqli (. *) for Ext/mysqli

• PDO (. *) for PDO (applies to all pdo-based database interactions)

If you use an ORM such as Propel, you may use (.) Query::(.) Track all Query classes.

Call Graph (callgraphs)

The final part of the xhprof is the call graph, which shows the code execution path of the run.

Click the "View CallGraph" button at the top of the single run page to view the call graph.

In the call graph, drag nodes to better view the data. Hovering over each click displays the actual execution time and allows you to enter the function's detail page.

To view the diagram more visually, click:
Experience the SaaS service for free with ONEAPM online PHP app performance analysis!

Next Chapter

In the third and final part, we use XHPROF data to optimize the code. We will also briefly introduce other tools to optimize the code.
(This article is the application performance management leader Enterprise OneAPM engineer compiles and organizes)

