Xdebug Document (6) Analyzing PHP scripts, _PHP tutorial-PHP Tutorial-php.cn

Xdebug Documentation (6) Analyzing PHP scripts,

Analyzing PHP scripts

Introduction

Xdebug analyzer is a powerful analyzer that analyzes PHP code and determines bottlenecks or determines where the code is running too slow and requires the use of accelerators. Xdebug2's analyzer output information is expressed in cachegrind compatible files. This allows you to use the excellent KcacheGrind tool (Linux, KDE) to analyze the data. If you use Linux you can install it in your installation manager.

There is also a precompiled QcacheGrind binary installation package available under Windows (QCacheGrind is the version of KcacheGrind that does not bundle KDE)

If you use a Mac system, here are instructions on how to install QcacheGrind.

Windows users can also choose to use WinCacheGrind. But its function is different from KcacheGrind, so this article does not introduce the software here. When Xdebug2.3 was published, WinCacheGrind still did not currently support cachegrind compression functions and files.

If you don’t use KDE (or don’t want to use it), the kcachegrind package also carries the perl script “ct_annotate” that can analyze the trace file and output ASCII.

Start analysis

Set xdebug.profiler_enable in Php.ini to 1 to enable analysis. This setup command xdebug enables profiling and writes to the directory specified by xdebug.profiler_output_dir. The generated file name generally starts with "cachegrind.out" and ends with the PHP (or apache) process PID (process ID) or the crc32 hash of the directory containing the initial debugging script. Make sure your xdebug.profiler_output_dir setting directory has enough space to save analysis. Complex script analysis generates huge analysis data. For example, there is eZ Publish, a complex application of more than 500MB.

You can also manually enable the profiler by setting xdebug.profiler_enable_trigger to 1. When it is set to 1, you can tell the profiler to exploit GET/POST or COOKIE values using a variable named XDEBUG_PROFILE. FireFox 2 extensions can be used to enable the debugger (see HTTP Debug Sessions) and can also be used to use this setting. In order for the trigger to function properly, xdebug.profiler_enable needs to be set to 0.

Analysis output

When the analysis results are generated, you can use KCacheGrind to open it:

Once the file is opened, KCacheGrind will have different panels providing sufficient information for your reference. On the left you can see the "Flat Profile" panel that lists all script functions in order of time spent, including the time of its subfunctions. The second column "Self" shows the time spent by the function (excluding sub-functions), the third column "Called" refers to the frequency of being called, and the last column "functions" shows the function name. Xdebug changes the PHP internal function name and adds the prefix "php::" to the function name, and the referenced files are also processed in the specified way. Calls to the include command are followed by "::" and the referenced file name. In the screenshot on the left you can see "include::/home/httpd/ez_34/v..." and the memory function example "php::mysql_query". The numbers in the first two columns can represent the total running time as a percentage (see example) or as an absolute time (1 unit represents 1/1.000.000 of a second). You can switch between these two modes with the button on the right.

The panel on the right contains upper and lower panels. The upper panel displays which function calls the currently selected function ("eztemplatedesignresource->executecompiledtemplate" in the screenshot). The lower panel displays the list of functions called by the selected function.

The Cost column of the upper panel displays the time spent when the currently selected function is called in the list. This number in the Cost column is usually 100%. The Cost column of the lower panel shows the time spent calling the functions in the list. Among the numbers in this column, you will never see a function that reaches 100% execution time.

"All Callers" and "All Calls" show not only the direct calls performed by the function respectively, but also show more superior and subordinate relationships of the function. The upper panel in the screenshot shows a column of all functions called by the currently selected function, with other functions directly and indirectly related in the middle of the stack. (The translation ability is limited...the original sentence is like this: The upper pane in the screenshot on the left shows all functions calling the current selected one, both directly and indirectly with other functions inbetween them on the stack.) The "Distance" column represents How many function calls are in the list, and the current selection is (-1). If there are different distances between the two functions, a range of values is also displayed (for example: "5-24"). Numbers in parentheses represent average values. The lower panel is also displayed similarly, but the difference is that it displays all function information called by the currently selected function, whether directly or indirectly.

Related settings

xdebug.profiler_append

Type:

integer, Default value: 0

When set to 1, when the analysis file is mapped to the same file under a new request (depending on xdebug.profiler_output_name), the analysis results will not be overwritten, but the analysis information will be appended to the end to form a new analysis file.

xdebug.profiler_enable

Type: integer, Default value: 0

Opening Xdebug's analyzer can create analysis files in the profile output directory. These files can be read by KcacheGrind to visually analyze the data. This setting cannot be set in a script using ini_set(). If you want to selectively enable the profiler, you can use the xdebug.profiler_enable_trigger setting to 1 instead.

xdebug.profiler_enable_trigger

Type: integer, Default value: 0

When set to 1, you can use the GET/POST parameters of XDEBUG_PROFILE or set the cookie value of XDEBUG_RPOFILE to trigger the generation of analysis files. These write profiles to a predefined directory. To prevent profile files from being generated on every request, you need to set xdebug.profiler_enable to a value of 0. Access triggers may be configured via xdebug.profiler_enable_trigger_value.

xdebug.profiler_enable_trigger_value

Type: string, Default value: "", since Xdebug > 2.3

As described in xdebug.profiler_enable_trigger, this setting is used to limit who can take advantage of the XDEBUG_PROFILE functionality. When changing from the original empty string default value, the cookie, GET or POST parameter value needs to match the shared secret set and enable the analyzer along with the configuration.

xdebug.profiler_output_dir

Type: string, Default value: /tmp

This directory is where the analysis file is output. Please ensure that the account running PHP has write permissions to this directory. This setting cannot be set in a script using ini_set().

xdebug.profiler_output_name

Type: string, Default value: cachegrind.out.%p

This setting determines the name of the analysis file, which can be specified using a format identifier, similar to sprintf() and strftime(). There are several identifiers that format file names. For details, please refer to xdebug.trace_output_name description.