Enable at runtime for long running processes using a signal (ie USR2)

[danielealbano]

For a platform I am working on I am planning on integrating a profiler to be able to easily monitor it if stuff starts to go south.

This extensions looks very cool because:

• supports google tracing format
• support the metrics I need
• it's a php extension, I don't need to fill my code with useless stuff

Sadly I will not be able to use it because currently it's not possible to enable / disable the profiler at runtime.

It would even be more cool if this extensions would be able to be turned on and off while the long running process is running.

How much complicated would it be? First and foremost the extension should keep track of the stack trace even if it's off, and quite probably it should keep track internally of some more metrics, but, for example, it wouldn't need to buffer the timeline events.

If you give me some hints I can try to take a look at it!

The reason for which I am asking is that even setting the environment variable is not straightforward, especially on live environments running on docker, kubernetes or similar.

[NoiseByNorthwest]

I'm sorry to say that since v0.2.0 google trace event format support has been dropped.

Turning on/off the extension via a user signal could be very useful, but such a feature is IMHO especially needed for non-dev environment and let's say production environment. So if you need it for a production environment please keep in mind that SPX is not yet production ready, not enough reviewed, tested...

To summarize:

1. A PHP script is launched with SPX disabled.
2. Something like a SIG_USER2 is sent to the process and interpreted as this configuration: SPX_ENABLED=1 SPX_REPORT=full which means it will produce a report for the web UI.
   • Are you ok with that?
3. SPX will be disabled once the process is finished or if another user signal is sent.
4. SPX should supports several on/off cycles for the same script.

About the implementation:

• Not so straightforward
• Will require a custom automated test infrastructure (BTW same issue for web UI) in case we want tests
• It is possible to start profiling without having kept track of the call stack (it can be unwound with Zend Engine like debug_backtrace do), just extra works

I prefer do it myself since it is a bit tricky and it will touch the most critical parts. It might be done withing a month or two at the latest. If you have some ideas for the automated tests or event want to make them I'm interested.

[danielealbano]

Yeah, I think that the biggest issues nowadays is the lack of support for the little stuff that makes those kind of components production friendly :)

I know that it's not production ready but it is for an internal tool that will be used once every month but that will have to process a lot of data (ie. billions) so having a profiler that can be turned on/off on demand would be great!

I already worked with those kind of systems both in C# and Java and I am quite good with C and I have a little of experience with pre php70 extensions so if you want I may try to help.

About the testing, it is a quite complex situation to test, probably the best would be to mock the code related to the signal handler so it could be tested easily, I will start taking a look on how you implemented the tests, I didn't ever used C testing frameworks.

EDIT About the file format, do it supports the Google Trace View? If it supports ftrace it could be used https://github.com/catapult-project/catapult/tree/master/tracing

[NoiseByNorthwest]

If you feel you can do it I can assign to you, it suits me. Feel free to ask me some hints if you have doubts or if things get complicated.

About Google Trace View, can you open another issue ?

[danielealbano]

I will start to look into the code more in the detail this weekend :+1:

[NoiseByNorthwest]

Thanks!

[orls]

It might be worth noting that php-fpm already has special behaviour for USR2, so this might conflict/confuse things in that scenario.

[NoiseByNorthwest]

@orls good point. The signal handlers are (or should be) registered only for CLI SAPI.

EDIT: this is currently the case https://github.com/NoiseByNorthwest/php-spx/blob/ce5f55497cd7ea7d65118d8afb0454b3589fe652/src/php_spx.c#L444