Thread: Using DB to cache METARs ?
Brought to you by:
iridium
Menu
▾
▴
phpweather-devel
|
From: Phil P. <phi...@sw...> - 2004-01-03 06:53:22
|
Supposedly using a DB of some kind to cache METARs makes things faster. Is there any to DEBUG this? Because I'm finding it's simply not any faster at all. (and FYI I don't have shell access to the machine, so any debug will have to be via PHP scripting or something) Page generation takes anywhere from 1.4 to 1.9 seconds. When I use NO DB, *and* when I use Sleepycat DB3. The METAR was generated less than 1 hour ago, so after I've refreshed the page a couple of times, in theory the data should be in the database, right? Lemme know if you have any ideas where I can look to fit it and get the caching working. As obviously ~1.5 seconds per page is simply not accceptable. Thanks Phil P |
|
From: Phil P. <phi...@sw...> - 2004-01-04 07:25:52
|
I turned on *everything* for verbosity, and here's what it says.... Debug: get_location(): Looking for location in the database. Debug: The METAR is not set, I'll try to find the METAR in the database.. Debug: Returning this row from the DBA database: YSSY 040627Z 03021G34KT CAVOK 27/19 Q1007 NOSIG:1073197620. Debug: get_metar_from_db(): Found the METAR in the database. Debug: get_location(): Using old location: Sydney Airport, Australia. Debug: get_metar_from_db(): The METAR for Sydney Airport, Australia was 1073114715 seconds too old.. Debug: get_location(): Using old location: Sydney Airport, Australia. Debug: get_metar_from_web(): Updating METAR for Sydney Airport, Australia. Debug: Updating this row in the DBA database: YSSY 040627Z 03021G34KT CAVOK 27/19 Q1007 NOSIG:1073197620. Debug: get_location(): Looking for location in the database. Debug: The METAR is not set, I'll try to find the METAR in the database.. Debug: Returning this row from the DBA database: YSSY 040627Z 03021G34KT CAVOK 27/19 Q1007 NOSIG:1073197620. Debug: get_metar_from_db(): Found the METAR in the database. Debug: get_location(): Using old location: Sydney Airport, Australia. Debug: get_metar_from_db(): The METAR for Sydney Airport, Australia was 1073114720 seconds too old.. Debug: get_location(): Using old location: Sydney Airport, Australia. Debug: get_metar_from_web(): Updating METAR for Sydney Airport, Australia. Debug: Updating this row in the DBA database: YSSY 040627Z 03021G34KT CAVOK 27/19 Q1007 NOSIG:1073197620. Debug: get_location(): Using old location: Sydney Airport, Australia. Debug: The METAR was set - I'll just use that.. Debug: get_location(): Using old location: Sydney Airport, Australia. Debug: The METAR was set - I'll just use that.. FYI: the METAR timestamp is 040627Z, ie 06:27 UTC on the 4th. Time now is 07:23UTC on the 4th, so it should have decided it was within the cache-timeout and not gone to the web. Hopefully someone out there can gimme a hand to work this one out. Thanks, PhiL P Phil Pierotti wrote: > Supposedly using a DB of some kind to cache METARs makes things faster. > Is there any to DEBUG this? > Because I'm finding it's simply not any faster at all. > > (and FYI I don't have shell access to the machine, so any debug will > have to be via PHP scripting or something) > > Page generation takes anywhere from 1.4 to 1.9 seconds. > When I use NO DB, *and* when I use Sleepycat DB3. > > The METAR was generated less than 1 hour ago, so after I've refreshed > the page a couple of times, in theory the data should be in the > database, right? > > Lemme know if you have any ideas where I can look to fit it and get the > caching working. As obviously ~1.5 seconds per page is simply not > accceptable. > > Thanks > Phil P > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > PHPWeather-devel mailing list > PHP...@li... > https://lists.sourceforge.net/lists/listinfo/phpweather-devel > > |
|
From: Martin G. <gim...@gi...> - 2004-01-04 17:45:59
|
Phil Pierotti <phi...@sw...> writes: > Hopefully someone out there can gimme a hand to work this one out. I've just resend my earlier responce to the list, I really don't know why, but it never made it through. :-/ And to follow up on that, I've updated CVS so that things should work again for the MySQL and null databases. The rest is a mess --- we have a half-implemented archiving feature that someone needs to rewrite. Any chance you could do that, Etienne? -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather: Shows the current weather on your webpage and PHP Shell: A telnet-connection (almost :-) in a PHP page. |
|
From: Phil P. <phi...@sw...> - 2004-01-04 22:50:15
|
Just to be clear, by this you mean you've fixed the timestamping/cache problem for MySQL and the NULL database? In that case, did you see my other post about issues getting MySQL access to work? [ after much actually reading the configuration page, I realized I needed to physically (ie manually) copy the defaults file to my phpweather (eg in order to enable debug) -sigh- obviously not enough coffee yesterday] DEBUG=everything shows me: Fatal error: SQL-statement failed: CREATE TABLE pw_metars( icao char(4) NOT NULL, time timestamp(14), metar varchar(255) NOT NULL, timestamp timestamp(14), PRIMARY KEY (icao) MySQL said You have an error in your SQL syntax near '' at line 6 (1064). When I configure for MySQL database access, and then use the Create Tables page. Thanks, Phil P Martin Geisler wrote: > Phil Pierotti <phi...@sw...> writes: > > >>Hopefully someone out there can gimme a hand to work this one out. > > > I've just resend my earlier responce to the list, I really don't know > why, but it never made it through. :-/ > > And to follow up on that, I've updated CVS so that things should work > again for the MySQL and null databases. > > The rest is a mess --- we have a half-implemented archiving feature > that someone needs to rewrite. Any chance you could do that, Etienne? > |
|
From: Martin G. <gim...@gi...> - 2004-01-04 23:26:05
|
Phil Pierotti <phi...@sw...> writes: > Just to be clear, by this you mean you've fixed the timestamping/cache > problem for MySQL and the NULL database? Yes, I basically disabeled the code that played with the timestamps. The problem is that Etienne wanted to add support for caching METARs and also TAF reports --- which is a fine idea! But a METAR report has a timefield which only contains the current day of month together with the time of day. The present code always uses the current month as a basis, but with old archived METARs this wont work anymore. So the code was changed to try and work around this lack of a full timestamp, but unfortunately the result was a bit messy with some timestamps being of the form YYYYMMDDhhmmss and other timestamps being a standard Unix timestamp counting the number of seconds since Jan 1st 1970. The code now works as it used to --- that is, the archiving of METAR reports is probably broken, I don't know for I've never used it. All I know is that it has to be reimplemented some other way. Could anybody do a CVS update and confirm that things work at least using MySQL and the null db backend? If somebody uses PostgreSQL then it would be cool to get a report about that too! > In that case, did you see my other post about issues getting MySQL > access to work? > > [ after much actually reading the configuration page, I realized I > needed to physically (ie manually) copy the defaults file to my > phpweather (eg in order to enable debug) -sigh- obviously not enough > coffee yesterday] :-) But you're right, it might not be exactly what people expect from the configuration builder --- but then again, making a configuration generator that writes to the files would be dangerous, and also require people to setup proper permissions for the files. But they still have to do this if they want to use the DBA db backend, so perhaps I'm wrong... > DEBUG=everything shows me: > > Fatal error: SQL-statement failed: CREATE TABLE pw_metars( icao > char(4) NOT NULL, time timestamp(14), metar varchar(255) NOT NULL, > timestamp timestamp(14), PRIMARY KEY (icao) MySQL said You have an > error in your SQL syntax near '' at line 6 (1064). Yes, I've fixed those errors too --- the SQL statements lacks the final right parenthesis... -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather: Shows the current weather on your webpage and PHP Shell: A telnet-connection (almost :-) in a PHP page. |
|
From: Phil P. <phi...@sw...> - 2004-01-04 23:27:39
|
Downloaded the updates via CVS: MySQL access is now working :-) MySQL access is now caching :-) :-) For some reason, I'm no longer getting the ICONS displayed, though this could easily be some random stupidity in how I've scripted it into my site. (sigh) Thanks Very Muchly! Phil P Phil Pierotti wrote: > Just to be clear, by this you mean you've fixed the timestamping/cache > problem for MySQL and the NULL database? > > In that case, did you see my other post about issues getting MySQL > access to work? > > [ after much actually reading the configuration page, I realized I > needed to physically (ie manually) copy the defaults file to my > phpweather (eg in order to enable debug) -sigh- obviously not enough > coffee yesterday] > > DEBUG=everything shows me: > > Fatal error: SQL-statement failed: CREATE TABLE pw_metars( icao char(4) > NOT NULL, time timestamp(14), metar varchar(255) NOT NULL, timestamp > timestamp(14), PRIMARY KEY (icao) > MySQL said You have an error in your SQL syntax near '' at line 6 (1064). > > When I configure for MySQL database access, and then use the Create > Tables page. > > Thanks, > Phil P > > Martin Geisler wrote: > >> Phil Pierotti <phi...@sw...> writes: >> >> >>> Hopefully someone out there can gimme a hand to work this one out. >> >> >> >> I've just resend my earlier responce to the list, I really don't know >> why, but it never made it through. :-/ >> >> And to follow up on that, I've updated CVS so that things should work >> again for the MySQL and null databases. >> >> The rest is a mess --- we have a half-implemented archiving feature >> that someone needs to rewrite. Any chance you could do that, Etienne? >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > PHPWeather-devel mailing list > PHP...@li... > https://lists.sourceforge.net/lists/listinfo/phpweather-devel > > |
|
From: Phil P. <phi...@sw...> - 2004-01-04 23:33:30
|
For some reason at least some (most likely all) of the ICONS were
currupted when I downloaded them via CVS, copying back the set I
received from the 2.2.0 release works fine.
Now all I need to do is FSCK with the {select an icon} code so that it
correctly shows DAYTIME icons for my location and I'm set.
Thanks,
Phil P
Phil Pierotti wrote:
> Downloaded the updates via CVS:
>
> MySQL access is now working :-)
> MySQL access is now caching :-) :-)
>
> For some reason, I'm no longer getting the ICONS displayed, though this
> could easily be some random stupidity in how I've scripted it into my
> site. (sigh)
>
> Thanks Very Muchly!
>
> Phil P
>
> Phil Pierotti wrote:
>
>> Just to be clear, by this you mean you've fixed the timestamping/cache
>> problem for MySQL and the NULL database?
>>
>> In that case, did you see my other post about issues getting MySQL
>> access to work?
>>
>> [ after much actually reading the configuration page, I realized I
>> needed to physically (ie manually) copy the defaults file to my
>> phpweather (eg in order to enable debug) -sigh- obviously not enough
>> coffee yesterday]
>>
>> DEBUG=everything shows me:
>>
>> Fatal error: SQL-statement failed: CREATE TABLE pw_metars( icao
>> char(4) NOT NULL, time timestamp(14), metar varchar(255) NOT NULL,
>> timestamp timestamp(14), PRIMARY KEY (icao)
>> MySQL said You have an error in your SQL syntax near '' at line 6 (1064).
>>
>> When I configure for MySQL database access, and then use the Create
>> Tables page.
>>
>> Thanks,
>> Phil P
>>
>> Martin Geisler wrote:
>>
>>> Phil Pierotti <phi...@sw...> writes:
>>>
>>>
>>>> Hopefully someone out there can gimme a hand to work this one out.
>>>
>>>
>>>
>>>
>>> I've just resend my earlier responce to the list, I really don't know
>>> why, but it never made it through. :-/
>>>
>>> And to follow up on that, I've updated CVS so that things should work
>>> again for the MySQL and null databases.
>>>
>>> The rest is a mess --- we have a half-implemented archiving feature
>>> that someone needs to rewrite. Any chance you could do that, Etienne?
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IBM Linux Tutorials.
>> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
>> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
>> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>> _______________________________________________
>> PHPWeather-devel mailing list
>> PHP...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpweather-devel
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> PHPWeather-devel mailing list
> PHP...@li...
> https://lists.sourceforge.net/lists/listinfo/phpweather-devel
>
>
|
|
From: Phil P. <phi...@sw...> - 2004-01-05 03:45:40
|
Just for the sake of completeness, I downloaded the icons again through CVS, still corrupted. Enjoy, Phil P Phil Pierotti wrote: > Downloaded the updates via CVS: > > MySQL access is now working :-) > MySQL access is now caching :-) :-) > > For some reason, I'm no longer getting the ICONS displayed, though this > could easily be some random stupidity in how I've scripted it into my > site. (sigh) > > Thanks Very Muchly! > > Phil P > > Phil Pierotti wrote: > >> Just to be clear, by this you mean you've fixed the timestamping/cache >> problem for MySQL and the NULL database? >> >> In that case, did you see my other post about issues getting MySQL >> access to work? >> >> [ after much actually reading the configuration page, I realized I >> needed to physically (ie manually) copy the defaults file to my >> phpweather (eg in order to enable debug) -sigh- obviously not enough >> coffee yesterday] >> >> DEBUG=everything shows me: >> >> Fatal error: SQL-statement failed: CREATE TABLE pw_metars( icao >> char(4) NOT NULL, time timestamp(14), metar varchar(255) NOT NULL, >> timestamp timestamp(14), PRIMARY KEY (icao) >> MySQL said You have an error in your SQL syntax near '' at line 6 (1064). >> >> When I configure for MySQL database access, and then use the Create >> Tables page. >> >> Thanks, >> Phil P >> >> Martin Geisler wrote: >> >>> Phil Pierotti <phi...@sw...> writes: >>> >>> >>>> Hopefully someone out there can gimme a hand to work this one out. >>> >>> >>> >>> >>> I've just resend my earlier responce to the list, I really don't know >>> why, but it never made it through. :-/ >>> >>> And to follow up on that, I've updated CVS so that things should work >>> again for the MySQL and null databases. >>> >>> The rest is a mess --- we have a half-implemented archiving feature >>> that someone needs to rewrite. Any chance you could do that, Etienne? >>> >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: IBM Linux Tutorials. >> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's >> Free Linux Tutorials. Learn everything from the bash shell to sys admin. >> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click >> _______________________________________________ >> PHPWeather-devel mailing list >> PHP...@li... >> https://lists.sourceforge.net/lists/listinfo/phpweather-devel >> >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > PHPWeather-devel mailing list > PHP...@li... > https://lists.sourceforge.net/lists/listinfo/phpweather-devel > > |
|
From: Martin G. <gim...@gi...> - 2004-01-05 15:56:46
|
Phil Pierotti <phi...@sw...> writes: > Just for the sake of completeness, I downloaded the icons again > through CVS, still corrupted. The icons themselves look fine to me --- normal PNG images. Are you sure it's not just the generated URL that's wrong, and therefore the icons look broken in your browser? Use icons_path to indicate the path that will be inserted infront of the image names, the standard setting of $this->properties['icons_path'] = 'icons/'; only works for index.php in the root PHP Weather folder because the icons are put in the icons subdirectory. -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather: Shows the current weather on your webpage and PHP Shell: A telnet-connection (almost :-) in a PHP page. |
|
From: Phil P. <phi...@sw...> - 2004-01-05 23:01:44
|
Actually that was my first thought: bad URLs.
So I checked the HTML source.
- All Good
So I checked the path/subdirs on the web server.
- All Good
So I went to the subdir where CVS had dumped phpweather on my local hard
drive, and tried to open an icon file.... Specifically icons/temphigh.png
My preferred graphic viewer (irfanview 3.85) replies with
{filename}: PNG Decode error !
This is not a valid PNG File !
Also neither FireBird 0.7+ nor MSIE 6 are able to display that local file.
Loading up the icons/ subdir from the previous release (2.1.2) works
perfectly fine without changing any code.
Also: downloading the 2.2.0 release (ZIP file) also gives me complete
working PNGs under icons/
Basically (and I've CVS'd them down several times now) the icons/* files
I'm receiving from CVS (I'm using WinCVS 1.3.13.2) are arriving
corrupted and thereby not valid PNG images. All of them. Every time.
I've tried with and without TCP Compression, and WinCVS is always
dumping into a new empty directory, so there's no mystery file-collision
weirdness going on either.
So, either
(a) the PNG icons/ in CVS are corrupted
(b) WinCVS is corrupting them icons/ as they download
Anyone else out there want to CVS down the latest PHPWeather (preferably
using Windows and not WinCVS) and let us know if the icons arrive safely?
Thanks,
Phil P
Martin Geisler wrote:
> Phil Pierotti <phi...@sw...> writes:
>
>
>>Just for the sake of completeness, I downloaded the icons again
>>through CVS, still corrupted.
>
>
> The icons themselves look fine to me --- normal PNG images. Are you
> sure it's not just the generated URL that's wrong, and therefore the
> icons look broken in your browser?
>
> Use icons_path to indicate the path that will be inserted infront of
> the image names, the standard setting of
>
> $this->properties['icons_path'] = 'icons/';
>
> only works for index.php in the root PHP Weather folder because the
> icons are put in the icons subdirectory.
>
|
|
From: Phil P. <phi...@sw...> - 2004-01-06 02:13:15
|
While I was trolling through the code, I often saw what looked like many
and various chunks of code which essentially re-processed the RAW METAR
data from scratch. (eg interpreting the timestamp).
[
Maybe I'm not being clear here... it looks to me like different bits of
PHPWeather that need (for example) the timestamp re-interpret it from
the RAW data themselves, rather than a chunk of code munging that into
an internal datastructure (ie once) which all the code chunks read as
they need.
Let me also just say that I've only done a little trolling around
PHPWeather sources, and I'm barely able to 'crawl' when it comes to
writing PHP. I'm not trying to criticize the code, merely wanting to
better understand how it works (perhaps I might try my hand at
contributing some tweaks/features in the not-too-distant future)
]
As this makes much and heavy use of regexes, I was wondering if this
could have a material impact on performance.
So, I did some quick hacking around with my PHP scripts and came up with
the following stats:
- full site page, including process (ensure this has been cached) METAR
for TEXT as well as evaluate for ICONS)
- 0.089 seconds or thereabouts
- same page, remove the code chunk/module for the METAR processing and
output
- 0.018 seconds
ugh! even when it's cached, processing the METAR and generating the
html-ified output makes the page generation take 3 times longer than
previously.
(of course, I'm using MySQL as the datastore for METARs, so this delay
could be mostly due to MySQL query queueing and processing delays)
So I hacked around, and wrote some additions to my scripts to cache my
formatted HTML output into a file. Now (as long as the cached results
are within the timeout) showing the processed weather data takes negible
additional time over normal page generation.
That's nice as a workaround. But obviously it only helps me and nobody
else (well, not much). Here's the code-fragment I used to 'cache the
output HTML' if anyone else wants to use it.
/* LockFile must exist, cacheFile must be writeable by the webserver */
if((time() - filectime($cacheFile)) < $metarCacheTimeout) {
readfile($cacheFile);
} else {
/* here we regenerate the formatted METAR results */
$output = {munged html-ified output you want on your site};
/* grab a lock on LOCKFILE, rewrite cachefile, release lock */
$fp = fopen($cacheFile . '-LOCK', 'r');
if( flock($fp, LOCK_EX + LOCK_NB) ) {
$fp2 = fopen($cacheFile, 'w');
if($fp2) {
fwrite($fp2, $output);
fflush($fp2);
fclose($fp2);
}
flock ($fp, LOCK_UN);
}
echo $output;
}
At some point I'll have a closer look and see if I can find where the
bulk of the time is going, but for now I just thought I'd throw my
findings out there and listen to any comments/feedback others might have.
Thanks,
Phil P
|
|
From: Martin G. <gim...@gi...> - 2004-01-06 14:43:01
|
Phil Pierotti <phi...@sw...> writes:
> Actually that was my first thought: bad URLs.
>
> So I checked the HTML source.
> - All Good
> So I checked the path/subdirs on the web server.
> - All Good
Okay, I just wanted to make that it wasn't some trivial mistake like
that...
> My preferred graphic viewer (irfanview 3.85) replies with
> {filename}: PNG Decode error !
> This is not a valid PNG File !
>
> Also neither FireBird 0.7+ nor MSIE 6 are able to display that local file.
Ahh... MSIE 6... you're using Windows! That made a bell ring! :-)
The problem is that your client translates the newlines into
carrige-return newline --- Unix uses a plain newline, but Windows
likes to use carrige-return newline. And of course one cannot just go
around changing binary files like that...
But it was really my mistake, I had forgot to use a -kb flag when I
commited the files. That flag tells CVS that the file is binary, and
so it shouldn't mess with the newlines.
If anybody finds other binary files lacking this option, then let me
know.
--
Martin Geisler My GnuPG Key: 0xF7F6B57B
See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather: Shows the current weather on your webpage and
PHP Shell: A telnet-connection (almost :-) in a PHP page.
|
|
From: <sr...@ma...> - 2004-01-06 23:13:19
|
Hi What is the status of TAF decoding ? Thanks in advance. Steen |
|
From: Martin G. <gim...@gi...> - 2004-01-04 17:45:29
|
Phil Pierotti <phi...@sw...> writes: Hi Phil. I'm sorry about all your trobles with this release... :-( But you're right, something definitely wrong, at least with the timestamps. Some further investitagion shows that all timestamps are set to 2^31-1 which is 03:14:07 on Jan 19th 2038, the time when the 32 bit timestamps used in Unix wraps around, bringing us all chaos. It just seems that the chaos have hit us a little earlier... :-) > Supposedly using a DB of some kind to cache METARs makes things > faster. Is there any to DEBUG this? > > Because I'm finding it's simply not any faster at all. Hmm... I think this would have something to do with the problem with the timestamps --- the METARs are put in the database using the wrong timestamp, and then later when they are retrieved they are deemed to be old. PHP Weather then goes to the NWS and refetches the METAR, and in doing so you get poor performance. > (and FYI I don't have shell access to the machine, so any debug will > have to be via PHP scripting or something) That's the common situation, I don't have shell access to gimpster.com either... > Page generation takes anywhere from 1.4 to 1.9 seconds. > When I use NO DB, *and* when I use Sleepycat DB3. > > The METAR was generated less than 1 hour ago, so after I've refreshed > the page a couple of times, in theory the data should be in the > database, right? Yes, exactly. But when the data is inserted with the wrong timestamp, things doesn't work as adverticed :-) I'll see about finding out what wrong when I get back tonight or perhaps tomorrow --- now I really must to and study for my exams... -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather: Shows the current weather on your webpage and PHP Shell: A telnet-connection (almost :-) in a PHP page. |
|
From: Martin G. <gim...@gi...> - 2004-01-04 18:54:28
|
Phil Pierotti <phi...@sw...> writes: Hi Phil. I'm sorry about all your trobles with this release... :-( But you're right, something definitely wrong, at least with the timestamps. Some further investitagion shows that all timestamps are set to 2^31-1 which is 03:14:07 on Jan 19th 2038, the time when the 32 bit timestamps used in Unix wraps around, bringing us all chaos. It just seems that the chaos have hit us a little earlier... :-) > Supposedly using a DB of some kind to cache METARs makes things > faster. Is there any to DEBUG this? > > Because I'm finding it's simply not any faster at all. Hmm... I think this would have something to do with the problem with the timestamps --- the METARs are put in the database using the wrong timestamp, and then later when they are retrieved they are deemed to be old. PHP Weather then goes to the NWS and refetches the METAR, and in doing so you get poor performance. > (and FYI I don't have shell access to the machine, so any debug will > have to be via PHP scripting or something) That's the common situation, I don't have shell access to gimpster.com either... > Page generation takes anywhere from 1.4 to 1.9 seconds. > When I use NO DB, *and* when I use Sleepycat DB3. > > The METAR was generated less than 1 hour ago, so after I've refreshed > the page a couple of times, in theory the data should be in the > database, right? Yes, exactly. But when the data is inserted with the wrong timestamp, things doesn't work as adverticed :-) I'll see about finding out what wrong when I get back tonight or perhaps tomorrow --- now I really must to and study for my exams... -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather: Shows the current weather on your webpage and PHP Shell: A telnet-connection (almost :-) in a PHP page. |
|
From: Phil P. <phi...@sw...> - 2004-01-06 14:51:52
|
Martin Geisler wrote: > Ahh... MSIE 6... you're using Windows! That made a bell ring! :-) > > The problem is that your client translates the newlines into > carrige-return newline --- Unix uses a plain newline, but Windows > likes to use carrige-return newline. And of course one cannot just go > around changing binary files like that... Don't ya just *hate* that? Ya know, I have to say: I saw an option in WinCVS saying "Checkout text files with the Unix LF (0xa)" And thought to myself, "nah, can't be that , these are BINARY files". Glad we've managed to hunt that one down :-) Phil P |
|
From: Martin G. <gim...@gi...> - 2004-01-06 21:29:05
|
Phil Pierotti <phi...@sw...> writes: > Martin Geisler wrote: >> Ahh... MSIE 6... you're using Windows! That made a bell ring! :-) >> The problem is that your client translates the newlines into >> carrige-return newline --- Unix uses a plain newline, but Windows >> likes to use carrige-return newline. And of course one cannot just go >> around changing binary files like that... > > Don't ya just *hate* that? Yeah, those binary formats are no fun at all... :-) > Ya know, I have to say: > > I saw an option in WinCVS saying > "Checkout text files with the Unix LF (0xa)" > And thought to myself, "nah, can't be that , these are BINARY files". > > Glad we've managed to hunt that one down :-) So am I! It's one of those things that I've read about, and when I did, I thought to myself: yes, I'll remember that, but guess what... I still forgot :-) -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather: Shows the current weather on your webpage and PHP Shell: A telnet-connection (almost :-) in a PHP page. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X