[php-maint] Bug#571762: Timezone querying

[Ondřej Surý]

I see this as twofold.

1. Added overhead when timezone is not set -> I don't think we should
really do anything in here. It's a simple matter of adding
date_default_timezone_set("xxx/yyy") to your application. After adding
this call PHP will use that value as first in guess_timezone().
However we could put something about it to README.Debian.

2. We call stat() everytime timelib_timezone_id_is_valid() is called.
That is adds some slowdown, but I don't really see a way how to fix
that unless you readahead all timezones, which will make PHP even more
slower (mainly at startup, but that happens basically every time with
non-threaded model). But I guess we could improve the performance
little bit anyway - using snprintfs are somewhat suboptimal and some
string related functions could be improved as well. I'll do that.

Ondrej

On Wed, Mar 17, 2010 at 21:17, Filipus Klutiero <chealer at gmail.com> wrote:
> Sean, let's do that. I'll recap what I wrote in my 3 last mails.
>
> Hi all,
> at the end of February, PHP 5.3 came to me, with an expected number of issues. One issue that annoyed me was that a warning is now triggered if a time-related function is used without having set the timezone in 3 approved ways: the TZ environment variable, the date.timezone PHP directive or calling date_default_timezone_set(). Thankfully, Sean Finney made Debian's PHP quiet this warning - so PHP now relies on the system timezone (PHP was already able to use that as a last recourse, but considered it unreliable, for an obscure reason).
>
> But I saw something worrying related to that when attending Rasmus Lerdorf's Confoo talk on PHP Performance. The slides are available at http://talks.php.net/show/confoo10/
> Slides 16 to 20 are relevant. Slide 20 shows that with HipHop PHP, running an application relying on the system timezone causes the application to run 25% slower (before using date_default_timezone_set, 20% of the time is spent in HPHP::TimeZone::Current).
>
> I don't know for sure that baseline PHP is affected as badly, but it seems so. I seem to remember the issue is that each determination of the timezone causes a syscall - not sure again. It would be nice if somebody could check this...
> The application in question is called Twit, and I don't know what it is except it was written by Rasmus: http://www.ora600.be/news/liveblogging-confoo-not-just-php-performance-rasmus-lerdorf
> But many applications use time extensively, so I have no trouble believing this case is not an exception.
>
> If this problem is found to be genuine, I have no great solution and I know very little about timezone handling but I think caching the timezone for a minute or so should be OK - the timezone should change rarely, it probably never changes on most Debian installs. We should also be able to look at other programs if needed - what happens to Python applications like Trac, for example? Even GUI applications use time a lot.
>
> Le mars 17, 2010 02:56:30 AM, Sean Finney a écrit :
>> hi filipus,
>>
>> how about you bring this up on pkg-php for discussion?
>>
>>       sean
>>
>> On Tue, Mar 16, 2010 at 09:51:27PM -0400, Filipus Klutiero wrote:
>> > Hi Sean and others,
>> > I'm back from Confoo 2010 and was able to get up early enough to see the last 15 minutes of Rasmus Lerdorf's talk on PHP performance. He was comparing HipHop PHP's performance with PHP's and had an initially slower result with HipHop. He profiled the HipHop version and after a few changes, it was still significantly slower than the PHP version. He found that a date or time function was taking about 15-20% of the execution time due to system calls querying the timezone. A simple date_default_timezone_set made the HipHop version take the lead.
>> >
>> > Now, I don't know what was the script and whether it used time/date functions a lot, but it looked like running without date_timezone, TZ and without calling date_default_timezone_set could have a significant performance hit if PHP doesn't cache the timezone. Caching the timezone for a minute or so would seem reasonable if it's not already done. I suppose the timezone is never changed on most Debian installs.
>> >
>> > I leave it to your discretion to determine whether this deserves investigation. Unfortunately, the slides aren't available, I can only suggest you ask Rasmus if you want more context.
>> >
>> > Thanks for the quick treatment of this bug,
>> > Filipus
>> >
>> > Le mars 13, 2010 06:51:14 PM, Debian Bug Tracking System a écrit :
>> > > This is an automatic notification regarding your Bug report
>> > > which was filed against the php5 package:
>> > >
>> > > #571762: [php5] please get rid of "Warning: date() [function.date]: It is not safe to rely on the system's timezone settings."
>> > >
>> > > It has been closed by Raphael Geissert <geissert at debian.org>.
>> > >
>> > > Their explanation is attached below along with your original report.
>> > > If this explanation is unsatisfactory and you have not received a
>> > > better one in a separate message then please contact Raphael Geissert <geissert at debian.org> by
>> > > replying to this email.
>
> _______________________________________________
> pkg-php-maint mailing list
> pkg-php-maint at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-php-maint
>



-- 
Ondřej Surý <ondrej at sury.org>
http://blog.rfc1925.org/