-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perf_events #243
Comments
Another fairly stable metric should be "number of executed zend opcodes". It looks like there is this:
However that seems to only show how many are loaded, not actually executed. |
I haven't read everything here https://man7.org/linux/man-pages/man2/perf_event_open.2.html, but the worst case seems to be Linux 4.3+
Exactly, and there is no such stat collected by Zend Engine.
Yes I could be interested, but could you first:
|
tl;dr It could be useful for profiling, but I think my needs might be better served by e.g. phpbench. I'm still planning on using spx for tracing, though ❤️
After I posted this, I poked around in php-src for it and couldn't find it either. Closest was
I'm trying to track performance over time in a potentially noisy CI environment. I realized later that my use case might be better served by e.g. phpbench. Although they don't seem to be able to track custom metrics yet...
Honestly, this may be a bit above my pay grade, but I suspect that using it in sampled mode should be fairly low overhead, as the kernel appears to write the data into a shared memory buffer (I believe the HHVM link above uses this). It appears a mutex and a signal handler will be necessary in this case. I experimented a bit with exposing the info without sampling to userland. In this case, it involves one read(2) call + optionally(?) two ioctl if you want to pause the counters while processing that data + processing the buffer.
I'm not sure, maybe this part from the manpage would clear things up a bit:
I'm not sure about the context switches. I would imagine context switches shouldn't affect the number of executed instructions that much, but I don't know. There will be some overhead from reading the data, of course. The example pauses the counters with Just to reiterate, this is a linux syscall so it would have to be behind a configure flag (no BSD, OSX, Windows, etc). |
Looks like perf_event_open is unavailable on Github Actions, might not be worth the trouble: actions/runner-images#4974 (The CI system I was planning to run it on was not Github Actions, though) |
Yes it is not the best tool for performance testing. |
I think it could be valuable, but not being able to run it in GHA is a big pain point. It sounds like you aren't convinced they would be useful enough to outweigh the added potential maintenance, which is totally okay, of course. Thank you for entertaining the idea. For now, if I find the time and motivation, I think I will play around with my userspace bindings, perhaps I'll find some workarounds. |
I'm not totally closed to the idea, it's just, as you said, a matter of trade-off between all costs and the added value. I've also seen your repository about the user space binding https://github.com/jbboehr/php-perf. If, in the future, I change my mind, it could help a lot with adding this metric to SPX. |
I've been messing around with this extension recently and it's been really great! I am looking into using it for profiling my application over time, but I am a little concerned the metrics (wt, ct) might be a little noisy.
perf seems to have the ability to measure instructions and cycles, which should be fairly stable, as long as the hardware and php compiler flags don't change. Would there be any interest in adding these metrics?
perf, the program, seems a little tricky to use since it is coupled to the linux kernel version. I don't know if perf_event_open suffers from this as well, or not.
HHVM seems to use it somehow: https://github.com/facebook/hhvm/blob/master/hphp/util/perf-event.cpp
Manpage for perf_event_open: https://man7.org/linux/man-pages/man2/perf_event_open.2.html
I wouldn't mind looking into it a bit if you are interested.
The text was updated successfully, but these errors were encountered: