Skip to content
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

Profiling an intermediate hook is sometimes empty #126

Open
danielbachhuber opened this issue Jan 3, 2017 · 9 comments
Open

Profiling an intermediate hook is sometimes empty #126

danielbachhuber opened this issue Jan 3, 2017 · 9 comments

Comments

@danielbachhuber
Copy link
Member

When profiling an intermediate hook (e.g. wp profile hook plugins_loaded:before), some environments don't log any results:

image

In debugging this initial report, the callback hooked into register_tick_function() is only fired once.

@danielbachhuber
Copy link
Member Author

This is a bug in PHP 7 https://bugs.php.net/bug.php?id=72966

Related thread from another profiling plugin khromov/wp-performance-profiler#1

@austinginder
Copy link

austinginder commented Nov 28, 2017

One of the comments in https://bugs.php.net/bug.php?id=71448 mentioned the following:

PHP 7.1 supports async signals, see https://wiki.php.net/rfc/async_signals. It looks like pcntl_async_signals() is not documented yet. This allows handling signals without using ticks.

Maybe this issue can be resolved by recoding how intermediate hooks work with PHP7.1?

@lkraav
Copy link

lkraav commented Mar 21, 2018

Yeah, after running into this now, and going through the PHP bug discussion - it actually was a bug in PHP5, and PHP7 fixed the leak.

Looks like profile intermediate hooks won't work at all on PHP 7.0, and the only way forward for PHP 7.1+ is to modernize our approach here like upstream has noted (via @austinginder).

@uprise10
Copy link

Is there another way to profile the (for example) wp_head:before hook? Or is switching back to PHP 5.6 the only option for now?

@danielbachhuber
Copy link
Member Author

PHP 5.6 is the only option.

@pcfreak30
Copy link

@ehausen
Copy link

ehausen commented Jun 7, 2022

So currently this won't work on PHP 7.1+ either, correct?

(But could be made to work?)

@tobias992
Copy link

Hello,
i am not a professional on github. Sorry for my question if it's stupid. For this bug here looks like there is a fix (https://gist.github.com/danielbachhuber/6bc4276ce559ddaa8b809a17c5ad6cd5) - there is a way to download this wp-cli profile package including this fix?

@tdiam
Copy link

tdiam commented Apr 4, 2023

Hello, i am not a professional on github. Sorry for my question if it's stupid. For this bug here looks like there is a fix (https://gist.github.com/danielbachhuber/6bc4276ce559ddaa8b809a17c5ad6cd5) - there is a way to download this wp-cli profile package including this fix?

Assuming you have WP-CLI and the profile command installed, you can apply the patch with the following one-liner:

wget -qO- https://gist.githubusercontent.com/danielbachhuber/6bc4276ce559ddaa8b809a17c5ad6cd5/raw/9ca11c146c88f481367494e62eb940835b0bcd95/wp-cli-profile-command-160.diff | patch -p1 -d ~/.wp-cli/packages/vendor/wp-cli/profile-command/

However, bear in mind that the patch by @danielbachhuber isn't complete and there are missing parts. Specifically, the FileStreamWrapper class in the patch does not fully implement streamWrapper .

For example, WordPress when loading the translation files (load_textdomain function), uses the fseek operation which is not implemented in the patch and so the command breaks:

Warning: fseek(): Stream does not support seeking in /home/user/public_html/wp-includes/pomo/streams.php on line 197

Also, this leaves *_file.php files behind, which you can easily cleanup:

find . -name '*_file.php' -delete

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants