Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Possible RFC: $_SERVER['REQUEST_TIME_FLOAT'] »

Possible RFC: $_SERVER['REQUEST_TIME_FLOAT']

php.internals

Herbert Groot Jebbink

3 years ago
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

Herbert Groot Jebbink

3 years ago
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_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 >
pfff, the "forgot to change after a copy/paste" mistake, the variable in the subject must be $_SERVER['REQUEST_TIME_HR']

Herbert Groot Jebbink

3 years ago
On Wed, 12 Apr 2023 at 11:53, Rowan Tommins wrote:
> 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)

Rowan Collins

3 years ago
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]

Herbert Groot Jebbink

3 years ago
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

Robert Landers

3 years ago
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.

Herbert Groot Jebbink

3 years ago
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

Rowan Collins

3 years ago
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]