Hello,
With this mail I want to do the first step of a RFC: "1. Email
internals@lists.php.net to measure reaction to your intended proposal."
I'm in the process of using hrtime(true) instead of microtime(true), for
this it would be great if REQUEST_TIME_HR would also exist next to
REQUEST_TIME and REQUEST_TIME_FLOAT
The implementation can be done with adding below 2 lines to
main/php_variables.c where REQUEST_TIME and REQUEST_TIME_FLOAT are also
defined.
ZVAL_LONG(&tmp, php_hrtime_current());
php_register_variable_quick("REQUEST_TIME_HR", sizeof("REQUEST_TIME_HR")-1,
&tmp, ht);
With Kind Regards, Herbert
On Wed, Apr 12, 2023 at 12:01 PM Herbert Groot Jebbink <
herbert@groot.jebbink.nl> wrote:
Hello,
With this mail I want to do the first step of a RFC: "1. Email
internals@lists.php.net to measure reaction to your intended proposal."I'm in the process of using hrtime(true) instead of microtime(true), for
this it would be great if REQUEST_TIME_HR would also exist next to
REQUEST_TIME and REQUEST_TIME_FLOATThe implementation can be done with adding below 2 lines to
main/php_variables.c where REQUEST_TIME and REQUEST_TIME_FLOAT are also
defined.ZVAL_LONG(&tmp, php_hrtime_current());
php_register_variable_quick("REQUEST_TIME_HR",
sizeof("REQUEST_TIME_HR")-1, &tmp, ht);With Kind Regards, Herbert
pfff, the "forgot to change after a copy/paste" mistake, the variable in
the subject must be $_SERVER['REQUEST_TIME_HR']
Should the same approach happen here? e.g. should all three
values be based on hrtime
fallback for REQUEST_TIME and REQUEST_TIME_FLOAT to hrtime seems not
possible, hrtime is not based on the actual time, hrtime can be used to
calculate a duration or so, not to retrieve the actual time itself.
The reason that I want to migrate from microtime(true) to hrtime(true) is
described in the comment in the PHP manual for hrtime:
"This function is particularly necessary on VMs running on KVM, XEN
(openstack, AWS EC2, etc) when timing execution times.
On these platforms which lack vDSO the common method of using time() or
microtime() can dramatically increase CPU/execution time due to the context
switching from userland to kernel when running the gettimeofday() system
call."
This migration is almost done, except in the case when it is used together
with REQUEST_TIME_FLOAT, that's the trigger for this possible RFC. The
extra precision is a bonus, but in my use case not needed. (in fact I
remove it so that old code still works)
On Wed, 12 Apr 2023 at 13:25, Herbert Groot Jebbink <
herbert@groot.jebbink.nl> wrote:
fallback for REQUEST_TIME and REQUEST_TIME_FLOAT to hrtime seems not
possible, hrtime is not based on the actual time, hrtime can be used to
calculate a duration or so, not to retrieve the actual time itself.
Fair enough, but that makes my first question all the more important: are
there any situations or platforms where generating an hrtime value for
every request would have a performance penalty?
How does that performance (for everyone) compare with a single call to
microtime(true) in your application to calculate the duration from
REQUEST_TIME_FLOAT to start of profiling, with all subsequent profiling
using hrtime?
Regards,
Rowan Tommins
[IMSoP]
Op wo 12 apr. 2023 16:04 schreef Rowan Tommins rowan.collins@gmail.com:
On Wed, 12 Apr 2023 at 13:25, Herbert Groot Jebbink <
herbert@groot.jebbink.nl> wrote:fallback for REQUEST_TIME and REQUEST_TIME_FLOAT to hrtime seems not
possible, hrtime is not based on the actual time, hrtime can be used to
calculate a duration or so, not to retrieve the actual time itself.Fair enough, but that makes my first question all the more important: are
there any situations or platforms where generating an hrtime value for
every request would have a performance penalty?How does that performance (for everyone) compare with a single call to
microtime(true) in your application to calculate the duration from
REQUEST_TIME_FLOAT to start of profiling, with all subsequent profiling
using hrtime?
ok, valid point, I also found out that setting a REQUEST_TIME_x variable at
that point is too late, the request has been going on for a while, that's
most likely the reason it's coming from the active SAPI and not from the
current time.
Thanks for the feedback, I will not file a RFC
On Thu, Apr 13, 2023 at 8:53 AM Herbert Groot Jebbink
herbert@groot.jebbink.nl wrote:
Op wo 12 apr. 2023 16:04 schreef Rowan Tommins rowan.collins@gmail.com:
On Wed, 12 Apr 2023 at 13:25, Herbert Groot Jebbink <
herbert@groot.jebbink.nl> wrote:fallback for REQUEST_TIME and REQUEST_TIME_FLOAT to hrtime seems not
possible, hrtime is not based on the actual time, hrtime can be used to
calculate a duration or so, not to retrieve the actual time itself.Fair enough, but that makes my first question all the more important: are
there any situations or platforms where generating an hrtime value for
every request would have a performance penalty?How does that performance (for everyone) compare with a single call to
microtime(true) in your application to calculate the duration from
REQUEST_TIME_FLOAT to start of profiling, with all subsequent profiling
using hrtime?ok, valid point, I also found out that setting a REQUEST_TIME_x variable at
that point is too late, the request has been going on for a while, that's
most likely the reason it's coming from the active SAPI and not from the
current time.Thanks for the feedback, I will not file a RFC
If you're using php-fpm and nginx, you can set variables in NGINX
(fastcgi.conf):
fastcgi_param REQUEST_TIME $date_gmt;
fastcgi_param REQUEST_TIME_ISO $time_iso8601;
then it should be available in the $_SERVER object. I didn't test
this, so it might need some experimentation to get it how you want it.
On Wed, Apr 12, 2023 at 4:04 PM Rowan Tommins rowan.collins@gmail.com
wrote:
On Wed, 12 Apr 2023 at 13:25, Herbert Groot Jebbink <
herbert@groot.jebbink.nl> wrote:fallback for REQUEST_TIME and REQUEST_TIME_FLOAT to hrtime seems not
possible, hrtime is not based on the actual time, hrtime can be used to
calculate a duration or so, not to retrieve the actual time itself.Fair enough, but that makes my first question all the more important: are
there any situations or platforms where generating an hrtime value for
every request would have a performance penalty?How does that performance (for everyone) compare with a single call to
microtime(true) in your application to calculate the duration from
REQUEST_TIME_FLOAT to start of profiling, with all subsequent profiling
using hrtime?
Is it every request? or at the first reference to the $_SERVER super global
?
But yeah, of course everything new thing does have a performance penalty
On Wed, 12 Apr 2023 at 11:01, Herbert Groot Jebbink <
herbert@groot.jebbink.nl> wrote:
I'm in the process of using hrtime(true) instead of microtime(true), for
this it would be great if REQUEST_TIME_HR would also exist next to
REQUEST_TIME and REQUEST_TIME_FLOAT
Hi :)
The idea sounds reasonable on the face of it.
Are there any performance issues calling hrtime on every request (possibly
platform-specific)?
I note that the existing values are not fetched directly from a time
source, but have some logic for SAPIs to provide a value [1] e.g. from the
Apache request context [2], and then REQUEST_TIME is just
REQUEST_TIME_FLOAT truncated to integer.
Should the same approach happen here? e.g. should all three values be based
on hrtime if the SAPI does not provide a value? Would we even need an extra
value if REQUEST_TIME_FLOAT had enough precision?
[1] https://heap.space/xref/php-src/main/SAPI.c?r=9d5f2f13#1085
[2]
https://heap.space/xref/php-src/sapi/apache2handler/sapi_apache2.c?r=4da0da7f#371
Regards,
Rowan Tommins
[IMSoP]