Using Xhprof and Xhgui to analyze PHP running performance _php techniques under Linux systems

What is performance analysis?
performance analysis is a measure of the relative performance of your application at the code level. The events that the profiling will capture include: CPU usage, memory usage, function call length and times, and call graph. Performance analysis behavior can also affect application performance.
When should performance analysis be performed?
When considering whether to perform performance analysis, you should first consider whether there is a performance problem with the application. If so, you should consider further: how big is the problem?

If you do not, you will be caught in a trap-premature optimization, which may waste your time.

To determine whether the application has a performance problem, you should set performance goals. For example, 100 concurrent users have a response time of less than 1s. Then, you need to benchmark your tests to see if you can achieve this goal. A common mistake is benchmarking in the development environment. In fact, you have to benchmark your production environment. (The actual production environment or the simulated production environment, which is easy to implement in SaaS.)
There are many products for benchmark testing, including Ab,siege and JMeter. I personally prefer the JMeter feature set, but AB and siege are more usable.

Once you are sure that the application has a performance problem, you need to analyze its performance, implement the improvements, and then test the benchmark again to see if the problem is resolved. After each change, you should have a benchmark review effect. If you make a lot of changes and find that the application is going down, you won't be able to determine exactly which change caused the problem.

The following figure is the performance lifecycle I defined:

General causes of performance degradation
Some of the common causes of performance degradation are quite unexpected. Even in a high-level language like PHP, the code is rarely the source of the problem. In today's hardware configuration, CPU is rarely the cause of performance constraints. The common reasons are:

Data storage

• PostgreSQL
• Mysql
• Oracle
• MSSQL
• Mongodb
• Riak
• Cassandra
• Memcache
• Couchdb
• Redis

External resources

• APIs
• File system
• Network interface
• External process
• Bad code.

Which performance Analyzer do you want to select?
in the PHP world, there are two distinct performance analyzers-active and passive.

Active VS Passive Performance analysis
the active analyzer is used during development and is enabled by the developer. The active Analyzer collects more information than the passive analyzer and has a greater impact on performance. Typically, the active analyzer cannot be used in a production environment. XDebug is an active analyzer.

Because of the inability to use the active analyzer in a production environment, Facebook launched a passive analyzer--xhprof. Xhprof is built for use in a production environment. It has minimal impact on performance and gathers enough information to diagnose performance problems. Both Xhprof and ONEAPM are passive analyzers.

Typically, additional information gathered by XDebug is not necessary for general performance problem analysis. This means that the passive analyzer is a better choice for uninterrupted profiling, even in the development environment.

Xhprof + Xhgui
Xhprof, developed by Facebook, contains a basic user interface for viewing performance data. In addition, Paul Reinheimer developed Xhgui and an enhanced user interface (UI) for viewing, comparing, and analyzing performance data.

Installation
Install Xhprof
Xhprof can be installed by PECL, as follows:

$ pecl Install Xhprof-beta

The PECL command will attempt to automatically update your php.ini settings. Pecl The file you are trying to update can be found using the following command:

$ pecl Config-get Php_ini

It adds a new configuration line at the top of the specified file (if any). You may want to move them to a more appropriate position.

Once you have compiled the Extender, you must enable it. To do this, you need to add the following code to the PHP INI file:

[Xhprof]
Extension=xhprof.so 

After that, the combination of Xhgui can easily perform performance analysis and inspection.

Install Xhgui
installation of Xhgui must be obtained directly from Git. This item can be found on the GitHub, address: Https://github.com/perftools/xhgui

Xhgui Requirements:

• PHP 5.3+
• Ext/mongo
• Composer
• MongoDB (if you only need to collect data, you can choose not to choose; If you need data analysis, it is required)

First, clone the project to any location. In Debian based Linux systems (such as Ubuntu, etc.), it may be/var/www. In Mac OS X system, may be/library/webserver/documents.

$ cd/var/www
$ git clone https://github.com/perftools/xhgui.git
$ cd Xhgui
$ php install.php

The last command is to run composer to install dependencies and check Xhgui cache directory permissions. If you fail, you can manually run composer install.

Next, you may need to create a configuration file. This step is easy to implement, and you can use the default configuration file under/path/to/xhgui/config/config.default.php.

If you are running MongoDB locally and there is no authentication, you may not need to do so. Because it will retire back to the default value. In a multiple-server environment, you will need a remote MongoDB server where all servers can be stored and properly configured.

To improve the performance of MongoDB, you can run the following instructions to add an index:

$ MONGO
> Use xhprof
db.results.ensureIndex ({' Meta. SERVER. Request_time ':-1}) 
Db.results.ensureIndex ({' Profile.main (). WT ':-1}) 
Db.results.ensureIndex ({' PROFILE.M Ain (). Mu ':-1}) 
Db.results.ensureIndex ({' Profile.main (). CPU ':-1} ') 
db.results.ensureIndex ({' Meta.url ': 1}) 

Other configuration
If you do not want to install MONGO in a production environment, or you cannot have the WEB server access the MONGO server, you can save profiling data on disk and import it into a local MongoDB for later analysis.

To do this, make the following modifications in config.php:

<?php 
' save.handler ' = ' file ', 
' save.handler.filename ' => '/path/to/xhgui/xhprof-'. Uniqid ("", true) . '. Dat ', 
?>

Change the Save.handler in the file, and then uncomment the Save.handler.filename to assign an appropriate value to it.

Note: Only one profiling file is saved by default on a daily basis.

Once you are ready to analyze the data, you can import it using the script included with Xhgui:

$php/path/to/xhgui/external/import.php/path/to/file.dat

The steps after this are the same.

Run Xhgui
Xhgui is a PHP based WEB application, you can set a standard virtual host with/path/to/xhgui/webroot as the root file.

Alternatively, you can simply use PHP 5.4+ cli-server for example:

$ Cd/path/to/xhgui
$ php-s 0:8080-t webroot/

This will enable Xhgui to communicate over 8080 ports across all network interfaces.

Run Performance Analyzer
When you run the analyzer, you need to include the external/header.php script on all the pages you want to analyze. To do this, you can set up auto_prepend_file in the PHP INI file. You can either set it directly in the public INI file or restrict it to a single virtual host.

For the Apache server, add the following code:

Php_admin_value auto_prepend_file "/path/to/xhgui/external/header.php"

For the Nginx server, add the following code in the server configuration:

Fastcgi_param php_value "auto_prepend_file=/path/to/xhgui/external/header.php";

If you are using PHP 5.4+ cli-server (php-s), you must set the command line tag:

$ php-s 0:8080-dauto_prepend_file=/path/to/xhgui/external/header.php

By default, the parser runs only to parse (approximately) 1% of requests. This is controlled by the following external/header.php code:

<?php 
if (rand (0)!==) {return 
  ;
}
? >

If you want to analyze each request (for example, during the development phase), you can comment out the code. If you want to make an analysis of the 10% request, you can make the following changes:

<?php
if (rand (0)!== 4) {return
  ;
}
? >

This allows you to analyze a small number of user requests without too much impact on individual users or too many users.

If you want to perform manual control during performance analysis, you can do this:

<?php 
if (!isset ($_request[' A9v3xusnkx3aeinsudzzv ')) &&!isset ($_cookie[' A9v3xusnkx3aeinsudzzv ')) {return 
 ;
} else {
 //Remove trace of the special variable from Request_uri
 $_server[' request_uri '] = str_replace (Array ('? A9v3xusnkx3aeinsudzzv ', ' &a9v3xusnkx3aeinsudzzv '), ', $_server[' Request_uri '];
 Setcookie (' A9v3xusnkx3aeinsudzzv ', 1);
}
if (Isset ($_request[' No-a9v3xusnkx3aeinsudzzv ')) { 
 Setcookie (' A9v3xusnkx3aeinsudzzv ', 0, Time ()-86400);
 return;
>

This code examines a randomly named Get/post/cookie variable (in this case: A9V3XUSNKX3AEINSUDZZV) and creates a COOKIE with the same name to parse the entire process of the request, such as the redirection after the form is submitted, the Ajax Requests, and so on.

In addition, it allows a get/post variable named No-a9v3xusnkx3aeinsudzzv to remove the Cookie and stop parsing.

Of course, we welcome you to try using ONEAPM to do a free performance analysis for your PHP and Java applications. ONEAPM's unique probes go deep into all PHP and Java applications to perform application management and monitoring, including the visibility of code-level performance issues, rapid identification and traceability of performance bottlenecks, real user experience monitoring, server monitoring, and End-to-end application performance management. ONEAPM can be traced to poorly performing SQL statements traces records, Third-party APIs that perform poorly, Web services, Cache, and so on.