-
Notifications
You must be signed in to change notification settings - Fork 384
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
Incorporate Server Timing API #990
Comments
@westonruter hi! Is it possible to turn off Server Timing headers in response? For example, with default configs for PHP-FPM + Nginx as a reverse proxy, Nginx drops requests as headers are too big. Tunning the fastcgi buffers fixes the problem, but it would be great to make these headers optional. |
@igkuz It's not currently possible to turn off the
Note that this is only for a response when the post-processor is invoked because the processed result is not cached yet. Once the post-processed response is cached, then the sanitizers are bypassed and none of the |
(As I paste that, I see something is wrong in that it is repeating |
@westonruter I see the same and AMP_Tag_And_Attribute_Sanitizer is repeating for several times. And when the page is big enough it's a problem. We're using the latest beta build, you can check the output here http://goo.gl/jTqZCW. |
@igkuz The issue of duplicated sanitizer names in the headers will be fixed with #1283. How many sanitizers are you using? While I expect there to be numerous instances of the |
@westonruter So if you place for example fastcgi_buffer_size 32k; everything is ok. PHP-FPM settings are not far from default ubuntu apt repo package, the changes are not connected with buffers. We added 4 Sanitizers to the array in our plugin. |
@igkuz I'm seeing a very large number of
This is not expected. There should only be ~22 such headers since you added 4 sanitizers. |
@westonruter you're correct, it's 60 of them, we're checking our code also, but still having an opportunity to turn them off would be great. |
To help facilitate debugging issues related to the performance of the preprocessor, we should leverage the new Server Timing API to report how long each sanitizer is taking to run, how long WordPress took to generate the page prior to the sanitizers running, etc.
Relates to #959.
The text was updated successfully, but these errors were encountered: