Download the PHP package reliforp/reli-prof without Composer

Reli

Reli is a sampling profiler (or a VM state inspector) written in PHP. It can read information about running PHP script from outside of the process. It's a stand alone CLI tool, so target programs don't need any modifications. The former name of this tool was sj-i/php-profiler.

What can I use this for?

• Detecting and visualizing bottlenecks in PHP scripts
  • It provides not only at the function level of profiling but also at line level or opcode level resolution
• Profiling without accumulated overhead even when a lot of fast functions called as this is a sampling profiler (see the links below, tideways, xhprof, and the profiler of xdebug, many profilers have this overhead)
  • Profiling Overhead and PHP 7
  • nikic/sample_prof
• Investigating the cause of a bug or performance failure
  • Even if a PHP script is in an unexplained unresponsive state, you can use this to find out what it is doing internally.
• Finding memory bottlenecks or memory leaks

How it works

It's implemented by using following techniques:

• Parsing ELF binary of the interpreter
• Reading memory map from /proc/\<pid>/maps
• Reading memory of outer process by using ptrace(2) and process_vm_readv(2) via FFI
• Analyzing internal data structure in the PHP VM (aka Zend Engine)

If you have a bit of extra CPU resource, the overhead of this software would be negligible.

Differences to phpspy, when to use reli

Reli is heavily inspired by adsr/phpspy.

The main difference between the two is that reli is written in almost pure PHP while phpspy is written in C. In profiling, there are cases you want to customize how and what information to get. If customizability for PHP developers matters, you can use this software at the cost of performance. (Although, we hope the cost is not too big.)

Additionally, reli can find VM state from ZTS interpreters. For example, in the daemon mode, traces of threads started via ext-parallel are automatically retrieved. Currently this cannot be done with phpspy only. Reli also provides functionality to only get the address of EG from targets, so you can use actual profiling with phpspy if you want, even when the target is ZTS.

Other features of reli that phpspy does not currently have include:

• Output more accurate line numbers
• Customize output format with PHP templates
• Get running opcodes of the PHP-VM
• Automatic retrieval of the target PHP version from stripped PHP binaries
• Output traces in speedscope format
• Deeply analyzing memory usage of the target process

There is no particular reason why these features cannot be implemented on the phpspy side, so it may be possible to do them on phpspy in the future.

On the other hand, there are a few things that phpspy can do but reli cannot yet.

• Redirecting output of child processes
• Forcing the address of EG
• Run more faster with lower overhead.
• etc.

Much of what can be done with phpspy will be done with reli in the future.

Requirements

Supported PHP versions

Execution

• PHP 8.1+ (NTS / ZTS)
• 64bit Linux x86_64
• FFI extension must be enabled.
• PCNTL extension must be enabled.

Target

• PHP 7.0+ (NTS / ZTS)
• 64bit Linux x86_64

On targeting ZTS, the target process must load libpthread.so, and also you must have unstripped binary of the interpreter and the libpthread.so, to find EG from the TLS.

Installation

From Composer

From Git

From Docker

Usage

Get call traces

Daemon mode

top-like mode

Get the address of EG

[Experimental] Dump the memory usage of the target process

Examples

Trace a script

Attach to a running process

The executing process must have the CAP_SYS_PTRACE capability. (Usually run as root is enough.)

Daemon mode

The executing process must have the CAP_SYS_PTRACE capability. (Usually run as root is enough.)

Get the address of EG

The executing process must have the CAP_SYS_PTRACE capability. (Usually run as root is enough.)

Show currently executing opcodes at traces

If a user wants to profile a really CPU-bound application, then he or she wouldn't only want to know what line is slow, but what opcode is. In such cases, use --template=phpspy_with_opcode with inspector:trace or inspector:daemon.

The output would be like the following.

The currently executing opcode becomes the first frame of the callstack. So visualizations of the trace like flamegraph can show the usage of opcodes.

For informational purposes, executing opcodes are also added to each end of the call frames. Except for the first frame, opcodes for function calls such as ZEND_DO_FCALL should appear there.

If JIT is enabled at the target process, this information may be slightly inaccurate.

Use in a docker container and target a process on host

Generate flamegraphs from traces

The generated flamegraph below visualizes traces from the execution of the psalm command.

Generate the speedscope format from phpspy compatible traces

See #101.

Generate the callgrind format output from phpspy compatible traces and visualize it with kcachegrind

Dump the memory usage of the target process

[!CAUTION] Don't upload the output of this command to the internet, because it can contain sensitive information of the target script!!!

[!WARNING]
This feature is in an experimental stage and may be less stable than others. The contents of the output may change in the near future.

Only NTS targets are supported for now.

The output would be like the following.

And you can get the call trace from the dump.

You can also see the contents of the local variables of a specific call frame.

If a context is referencing another location in the dump file, it can also be extracted with jq.

You can also extract all references to a specific object.

The refcount of the object recorded in the memory location is 6 in this example. Calling methods via $obj->call() adds refcount by 1, but $this->call() doesn't add refcount. References from objects_store don't add refcount too. So all 6 references are analyzed here.

See ./docs/memory-profiler.md for more info.

Troubleshooting

I get an error message "php module not found" and can't get a trace!

If your PHP binary uses a non-standard binary name that does not end with /php, use the --php-regex option to specify the name of the executable (or shared object) that contains the PHP interpreter.

I don't think the trace is accurate.

The -S option will give you better results. Using this option stops the execution of the target process for a moment at every sampling, but the trace obtained will be more accurate. If you don't stop the VMs from running when profiling CPU-heavy programs such as benchmarking programs, you may misjudge the bottleneck, because you will miss more VM states that transition very quickly and are not detected well.

Trace retrieval from ZTS target does not work on Ubuntu 21.10 or later.

Try to specify --libpthread-regex="libc.so" as an option.

I can't get traces on Amazon Linux 2.

First, try cat /proc/<pid>/maps to check the memory map of the target PHP process. If the first module does not indicate the location of the PHP binary and looks like an anonymous region, try to specify --php-regex="^$" as an option.

Goals

We would like to achieve the following 5 goals through this project.

• To be able to closely observe what is happening inside a running PHP script.
• To be a framework for PHP programmers to create a freely customizable PHP profiler.
• To be experimentation for the use of PHP outside of the web, where recent improvements of PHP like JIT and FFI have opened the door.
• Another entry point for PHP programmers to learn about PHP's internal implementation.
• To create a program that is fun to write for me.

LICENSE

• MIT (mostly)
• tools/flamegraph/flamegraph.pl is copied from https://github.com/brendangregg/FlameGraph and licenced under the CDDL 1.0. See tools/flamegraph/docs/cddl1.txt and the header of the script.
• Some C headers defining internal structures are extracted from php-src. They are licensed under the Zend Engine License or the PHP License. See src/Lib/PhpInternals/Headers . So here are the words required by the Zend Engine License and the PHP License.

What does the name "Reli" mean?

Given its functionality, you might naturally think that the name stands for "Reverse Elephpantineer's Lovable Infrastructure". But unfortunately, it's not true.

"Reli" means nothing, though you are free to think of this tool as something reliable, religious, relishable, or whatever other reli-s you like.

Initially, the name of this tool was just "php-profiler". Due to a licensing problem (#175), this simple good name had to be changed.

So we applied a randomly chosen string manipulation function to the original name. strrev('php-profiler') results to 'reliforp-php', and it can be read as "reli for p(php)".

Thus, the name of this tool is "Reli for PH*" now. And you can also call it just "Reli".

See also

• adsr/phpspy
  • Reli is heavily inspired by phpspy.