Tutorial on using XHGui to test PHP performance

Profiling is a technology used to observe program performance, and is very suitable for discovering program bottlenecks or tight resources. Profiling can go deep into the program and show the performance of each part of the code in the request processing process; at the same time, it can also identify problematic requests (requests); for problematic requests, we can also determine where the performance problem occurs within the request. For PHP, we have a variety of Profiling tools. This article mainly focuses on XHGui, a very excellent tool. XHGui is built on XHProf (XHProf is released by Facebook), but adds better storage for analysis results and a better information acquisition interface. In this respect, XHGui is more like a brand new tool.

XHGui has gone through several iterations, but the current version provides a more beautiful user interface and uses MongoDB to store its profiling results. All of these aspects are huge improvements compared to the previous version; because the previous version was more like a developer design, using files to save data, making the collected data very difficult to use. XHGui 2013 is a very comprehensive profiling tool for both managers and developers; at the same time, XHGui 2013 is designed to be lightweight enough to run in a production environment.

This article will demonstrate the installation of the program step by step and show you all aspects of information that can be collected using this tool.

Step one: Install dependencies

Because XHGui has some dependencies, our first step is to solve this problem. All the tutorials below are based on the Ubuntu 13.04 platform. Of course, you should be able to adapt them and apply them to your own platform. For now, we need to install MongoDB, PHP, and have some ability to install the PECL extension.

First, we have to install MongoDB, there are some official installation tutorials here, you can find the details related to your system, but for now I will install it simply through APT:

The version of MongoDB obtained through this method may not be the latest because this product is updated really quickly. However, if you want to keep it at a very recent version, you can add the library provided by MongoDB to your package manager so that you get the latest one.

At the same time, we also need the Mongo driver for PHP. The version of the driver in the repository is a bit old, so for today's demonstration we will get it from Pecl. If you don’t have the pecl command on your machine, you can install it with the following command:

Then, we add MongoDB’s driver to PHP via the following command:

In order to complete the installation, we finally need to add a new line to the php.ini file. However, new versions of Ubuntu provide a new system for configuring PHP extensions that works more like Apache module installation - save all the configuration in one place and then create a symbolic link to launch the configuration. First, we create a file to hold the settings, although in this example we only need to add a new line to the settings to enable the extension. We save it in the file /etc/php5/mods-available/mongo.ini and add the following line:

The command line will prompt us again to add a new line in php.ini. We use the same method as above to create the file /etc/php5/mods-available/xhprof.ini and add the following content to it:

Install XHGui

XHGui itself is mainly composed of web pages, which provide a more friendly interface for the data collected by the XHProf extension. You can clone from the repository GitHub repo; you can also download the zip file directly and unzip it. After obtaining the program, make sure the cache directory has sufficient permissions so that the web server has permission to write the file. Finally, run the installation script:

This is everything needed for program installation, and some dependent programs will be installed automatically; if an exception occurs, the installer will also prompt you.

I prefer to install XHGui in the virtual host; this requires the .htaccess file to be allowed and RUL rewriting needs to be enabled. Starting URL rewriting indicates that you need to start the mod_rewrite module, pass the following command:

(Don’t forget to restart Apache). If everything goes well, you can access the XHGui URL normally and see the following content:

Start XHGui in the virtual host

At this point, we want to launch XHGui in order to test the performance of our website. Note that performance testing is best performed before any optimization in order to detect the effect of the optimization. The simplest way is to add the auto_prepend_file statement in the virtual host, as shown in the figure below:

After everything is ready, you can start analyzing the website’s requests. XHGui will only profile 1% of website requests, so in order for XHGui to obtain meaningful data, you need to let XHGui run for a period of time or use a testing tool like Apache Bench to submit a batch of requests in batches. Why does XHGui only parse one out of 100 requests? Because XHGui is designed to be lightweight enough for use in a production environment and does not want to incur additional overhead for each request, a 1% sampling rate can already provide a clearer overview of the overall traffic of the website.

Meet the data

I use the test virtual machine to run all the examples in this article and use the Join.in API as the test code. In order to generate some traffic, I ran the API test case a few times. You can also collect data under load, so you can use XHGui during stress testing, and you can even use XHGui to collect data on live sites (sounds crazy, but Facebook officially developed this tool for this application) ). After sending a certain request to the application, revisit XHGui, and now it has saved some data:

This graph shows us each request that XHGui analyzed for us, with the latest request listed first, and showing some additional information for each request. This information includes:

• URL: The URL visited by the request
• Time: Request initiation time
• wtor: "Wall Time" – all the time the request has taken. This is short for "wall clock" time, which means all the time the user waited for the request to complete
• cpu: CPU time spent on this request
• mu: The memory consumed by this request
• pmu: The maximum memory consumed during request processing

In order to get more detailed information about each request ("run"), you can click on the column of each request that interests you. You can click on a URL to get detailed information about all requests for that URL. Either way, you can get more detailed information about the request:

This is a very long and very detailed page, so I quoted two screenshots (it would take 5 screenshots to show all the information). The left part of the above picture shows some information related to the request to help you track what aspects these statistics are related to; the main part on the right shows the most time-consuming parts and the time spent by each function call during the request process. memory consumed. There is a primary key below the graph to indicate each column.

The second picture shows more detailed information about each component of the request. We can see the number of calls and time consumption of each part, including CPU and memory information. Both inclusive and exclusive information are displayed in detail: exclusive means only the consumption caused by the method call; inclusive not only includes the consumption caused by this function, but also includes the consumption caused by other functions called by this function.

Another feature of XHGui is the "Callgraph". The "Callgraph" shows how time is consumed in a vivid virtual way:

This nicely demonstrates the hierarchy of function calls. The best part is that the diagram is interactive and you can drag to get a better look at the connections; you can also mouse over blobs to see more information. It bounces and moves playfully when you interact with it, which isn't a hugely important feature but made it really fun for me.

Understanding data

Having a lot of statistics is important, but it can be hard to know where to start. For a page whose performance is not as good as expected, use the following steps: First, sort the exclusive CPU time of each function and view the list of functions that consume the most time. Analyze these time-consuming function calls and refactor and optimize them.

Once changes are made, let the profiling tool check the new version of the program again to test performance improvements. XHGui has built-in tools perfect for comparing two runs; just click the "Compare this run" button in the upper right corner of the details page. This button will show you the results of each test for this URL, from which you can select an object you want to compare. For the object you want to compare, click the "compare" button, and XHGui will turn to the comparison view, as shown in the figure below:

The statistics table shows the main differences between the new version and the old version of statistics, including the actual number and percentage of each information change. The figure above shows that the request waiting time of the new version is only 8% of the old version. The statistical table shows the changes in each statistical information in detail, which we can often see on the "Details" page; you can sort any column to find the information you are interested in.

Once you've successfully refactored in one area, check the detail page to check how the new version actually works, and then pick other areas to optimize. Try to sort by memory usage or exclusive wall time to pick and optimize functions that maximize the overall performance of your application. At the same time, don't forget to check the number of calls. A repeatedly called function can exponentially improve the performance of the program after optimization.

Optimization method

It’s hard to know how much you’ve improved before you quantify the results, which is why we often test an app before optimizing it – otherwise how do you know if you’ve really optimized it? We also need to think about how a set of real data should be represented, otherwise, we may be heading towards an impossible goal. A very useful method is to try your best to find the most suitable data structure and the smallest storage space that needs to be used. If you can't run a "Hello world" program in half a second in your preferred work environment, don't expect a web page built with the same tools to perform well.

The above description is not disrespectful to the programming framework (framework); the programming framework exists because it is easy to use, supports rapid development, and is easy to maintain. Compared with writing code by hand, the reduction in performance of the programming framework is the result of our compromise in all aspects. Using a programming framework for application development is a good way to get it online as soon as possible. When needed, you can use Profiling tools to analyze and improve the performance of the program. For example, many modules of Zend Framework 1 provide very powerful features, but are very slow; using profiling tools you can identify the low-performance parts and replace them. All other frameworks have similar problems, and XHGui can show you where the problems are and check whether they have a quantifiable impact on your application.

Outside of your program, some other strategies may come in handy sooner or later to gain the upper hand:

• Beware of not-dangerously-slow-but-related functions showing up on a page. If your page spends 50% of its time in a series of functions in the view helper that handle formatting points (I promise this is a hypothetical example), then you may want to look into refactoring the entire component.
• Do less. Try removing features if performance is more important than them.
• Beware of content generated in one request but not used in a particular view, or content that is unchanged but regenerated multiple times.
• Good caching strategy. This will be another article about it, but consider using an OpCode cache in PHP (built-in as of PHP 5.5), adding a reverse proxy in front of your web server, and simply serving content that changes infrequently. Send appropriate cache headers.
• Violent decoupling. If there's a special feature that's horribly resource-intensive, remove it from your web server. Perhaps it could be handled asynchronously, so your program could just add a message to the queue, or be moved to a separate server and accessed as a separate service model. Either way, separation will help reduce load on your web server while enabling efficient scaling.

XHGui is your friend

XHGui is easy to install, goes with you when you use it, and the output is so great that it can be presented at a board meeting. It identifies bugs in our apps and helps us confirm that our apps actually work (or don’t!). This may go through some repetitive processes, but regardless of whether you have used XHProf or XHGui before, I urge you to take the time to try it on your application. You will be surprised by what you find.