Re: Using DB to cache METARs ?

[Martin G. <gim...@gi...>]

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.