You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Paul Querna <pa...@querna.org> on 2011/11/15 17:06:29 UTC
setting TZ env var
So, I was looking at all the system calls we make in a single request,
and comparing it to nginx.
We were actually pretty close, baring supporting our features like
htaccess, there was only one thing that stood out.
Glibc is opening, calling fstat twice, and then reading /etc/localtime
for every request:
[pid 31496] 0.000051 open("/etc/localtime", O_RDONLY) = 8 <0.000014>
[pid 31496] 0.000041 fstat(8, {st_mode=S_IFREG|0644, st_size=118,
...}) = 0 <0.000011>
[pid 31496] 0.000048 fstat(8, {st_mode=S_IFREG|0644, st_size=118,
...}) = 0 <0.000010>
[pid 31496] 0.000048 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbd87efa000 <0.000013>
[pid 31496] 0.000040 read(8,
"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0"...,
4096) = 118 <0.000015>
[pid 31496] 0.000051 lseek(8, -62, SEEK_CUR) = 56 <0.000011>
[pid 31496] 0.000034 read(8,
"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0"...,
4096) = 62 <0.000011>
[pid 31496] 0.000048 close(8) = 0 <0.000012>
One way to fix this, is to set the TZ environment variable.
For example:
<https://github.com/pquerna/httpd/commit/37e5815a70e88a733cd088398d016803146b545f>
This specific patch has some issues, but is there any objections to
the concept of setting the timezone on process startup?
This single change gives about a 2% performance boost in my testing.
To merge to trunk I'd like to have it detect your active timezone,
instead of forcing UTC+0, but if you changed timezones on your
machine, you will need to restart httpd.
Thoughts?
Thanks,
Paul
Re: setting TZ env var
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/15/2011 10:06 AM, Paul Querna wrote:
>
> One way to fix this, is to set the TZ environment variable.
>
> For example:
> <https://github.com/pquerna/httpd/commit/37e5815a70e88a733cd088398d016803146b545f>
Without modifying TZ, what happens to the profiling if a call
to tzset() is added at startup?
Re: setting TZ env var
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/16/2011 4:39 AM, Rainer Jung wrote:
>
> I'd say it is OK. I assume a "apachectl restart" would do?
> It should be expected for a long running daemon to signal it to adopt to environmental
> changes like the timezone.
Yup. Not that the times are "wrong", they carry zone info within
the access logs.
However, our error log timestamps appear to be bullshit. We don't
carry the timezone delta. Ergo the DST->ST shift can't be delineated
anyways. So the existing log time logic is broken.
+1 to the whole concept provided that error logging adopts access.log
time representation.
Re: setting TZ env var
Posted by Rainer Jung <ra...@kippdata.de>.
On 15.11.2011 17:06, Paul Querna wrote:
> So, I was looking at all the system calls we make in a single request,
> and comparing it to nginx.
>
> We were actually pretty close, baring supporting our features like
> htaccess, there was only one thing that stood out.
>
> Glibc is opening, calling fstat twice, and then reading /etc/localtime
> for every request:
>
> [pid 31496] 0.000051 open("/etc/localtime", O_RDONLY) = 8<0.000014>
> [pid 31496] 0.000041 fstat(8, {st_mode=S_IFREG|0644, st_size=118,
> ...}) = 0<0.000011>
> [pid 31496] 0.000048 fstat(8, {st_mode=S_IFREG|0644, st_size=118,
> ...}) = 0<0.000010>
> [pid 31496] 0.000048 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbd87efa000<0.000013>
> [pid 31496] 0.000040 read(8,
> "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0"...,
> 4096) = 118<0.000015>
> [pid 31496] 0.000051 lseek(8, -62, SEEK_CUR) = 56<0.000011>
> [pid 31496] 0.000034 read(8,
> "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0"...,
> 4096) = 62<0.000011>
> [pid 31496] 0.000048 close(8) = 0<0.000012>
>
>
> One way to fix this, is to set the TZ environment variable.
>
> For example:
> <https://github.com/pquerna/httpd/commit/37e5815a70e88a733cd088398d016803146b545f>
>
> This specific patch has some issues, but is there any objections to
> the concept of setting the timezone on process startup?
Fine for me.
> This single change gives about a 2% performance boost in my testing.
>
> To merge to trunk I'd like to have it detect your active timezone,
> instead of forcing UTC+0, but if you changed timezones on your
> machine, you will need to restart httpd.
I'd say it is OK. I assume a "apachectl restart" would do?
It should be expected for a long running daemon to signal it to adopt to
environmental changes like the timezone.
Regards,
Rainer
Re: setting TZ env var
Posted by Issac Goldstand <ma...@beamartyr.net>.
On 15/11/2011 18:06, Paul Querna wrote:
> but is there any objections to
> the concept of setting the timezone on process startup?
>
> This single change gives about a 2% performance boost in my testing.
>
> To merge to trunk I'd like to have it detect your active timezone,
> instead of forcing UTC+0, but if you changed timezones on your
> machine, you will need to restart httpd.
>
> Thoughts?
Well, the only 2 use-cases I can see for changing TZs at runtime are:
1) Flight/Travel/Navigation systems, which probably already use UTC for
this reason, and
2) Mobile Apps (and maybe, maybe PC apps running on laptops). So how
many mobile apps do we think there are based on httpd and how critical
is the timezone (presumably changing at airports, like we just did)?
Issac
Re: setting TZ env var
Posted by Issac Goldstand <ma...@beamartyr.net>.
On 16/11/2011 01:06, William A. Rowe Jr. wrote:
> On 11/15/2011 4:28 PM, Issac Goldstand wrote:
>>
>> I'd likely -1 anything that assumed without allowing the user to specify
>> an override.
>
> what on earth is wrong with
>
> --- ../httpd-2.x/support/apachectl.in (revision 1198625)
> +++ ../httpd-2.x/support/apachectl.in (working copy)
> @@ -44,6 +44,9 @@
> # the path to your httpd binary, including options if necessary
> HTTPD='@exp_sbindir@/@progname@'
> #
> +# desired local timezone representation for logs
> +TZ=GMT+0000
> +#
> # pick up any necessary environment variables
> if test -f @exp_sbindir@/envvars; then
> . @exp_sbindir@/envvars
>
> or...
>
> SetEnv TZ GMT+0000
>
> There you go, two mechanisms "allowing the user to specify
> an override"
>
> Can we quit inventing redundant directives?
>
> I'm certainly -1 on such a directive. I'm totally +1 if someone
> wants to document the appropriate use of the TZ variable.
>
> And I'd be very cool with ensuring that we tzset() after allowing
> conf parsing/SetEnv processing and before forking.
Good point - that's definitely fair enough, just need to make sure it's
documented in the right place.
Issac
Re: setting TZ env var
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/15/2011 4:28 PM, Issac Goldstand wrote:
>
> I'd likely -1 anything that assumed without allowing the user to specify
> an override.
what on earth is wrong with
--- ../httpd-2.x/support/apachectl.in (revision 1198625)
+++ ../httpd-2.x/support/apachectl.in (working copy)
@@ -44,6 +44,9 @@
# the path to your httpd binary, including options if necessary
HTTPD='@exp_sbindir@/@progname@'
#
+# desired local timezone representation for logs
+TZ=GMT+0000
+#
# pick up any necessary environment variables
if test -f @exp_sbindir@/envvars; then
. @exp_sbindir@/envvars
or...
SetEnv TZ GMT+0000
There you go, two mechanisms "allowing the user to specify
an override"
Can we quit inventing redundant directives?
I'm certainly -1 on such a directive. I'm totally +1 if someone
wants to document the appropriate use of the TZ variable.
And I'd be very cool with ensuring that we tzset() after allowing
conf parsing/SetEnv processing and before forking.
Re: setting TZ env var
Posted by Issac Goldstand <ma...@beamartyr.net>.
On 15/11/2011 21:35, William A. Rowe Jr. wrote:
> On 11/15/2011 10:06 AM, Paul Querna wrote:
>>
>> To merge to trunk I'd like to have it detect your active timezone,
>> instead of forcing UTC+0, but if you changed timezones on your
>> machine, you will need to restart httpd.
>>
>> Thoughts?
>
> If it did so (extract the correct offset) then I'd be +1.
>
> I'm not clear if the zone changes between EDT and EST, but I'd
> presume the name doesn't and the value does?
>
> OTOH, this causes something of a mess in the server logs. If the
> user cycles them out between restarts, then sticking to the same
> time zone for the lifespan of the server seems like a feature, to me.
Well, for me it went beyond saying that the proposal would include a
config directive to overwrite the detected system TZ...
I'd likely -1 anything that assumed without allowing the user to specify
an override.
Issac
Re: setting TZ env var
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/15/2011 10:06 AM, Paul Querna wrote:
>
> To merge to trunk I'd like to have it detect your active timezone,
> instead of forcing UTC+0, but if you changed timezones on your
> machine, you will need to restart httpd.
>
> Thoughts?
If it did so (extract the correct offset) then I'd be +1.
I'm not clear if the zone changes between EDT and EST, but I'd
presume the name doesn't and the value does?
OTOH, this causes something of a mess in the server logs. If the
user cycles them out between restarts, then sticking to the same
time zone for the lifespan of the server seems like a feature, to me.