[Theforum] [---Dev] RE: [---tent] Article cleanup issue

Martin Burns martin at easyweb.co.uk
Wed Jul 24 08:31:55 CDT 2002

On Wed, 24 Jul 2002, .jeff wrote:

> ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > From: Martin Burns
> >
> > ...much of which doesn't seem to be needed if the vast
> > majority of people only browse the 1st few pages
> ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> wrong.
> everyone that logs in the same day and views the site within
> the timespan window keeps that query cached.  therefore the caching
> effectively benefits everyone except those that surf the site not logged in.

I was contrasting 2 situations:
1) Currently, *all* the pages of results are cached, and retrieving and
caching that takes 10 seconds
2) An alternative is that only the 1st N pages of results are cached.

Caching *all* (as opposed to some) of the results leads to the large
amount of data being returned which, as you've established, is the thing
taking the time.

> it also benefits you anytime you return to the homepage.

What does it return, compared to only caching a bit of data?

I'm only really seeing the "page X of Y" which is a unique benefit of
caching everything?

> ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > > all queries would take longer
> >
> > How much longer? A wee bit? Or 5000ms?
> ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> twice as long or more to execute everything.

How long is the existing time? If at the moment it's lightning fast, then
1/2 the speed of lightning I can accept, particularly traded off against
"Some users have to wait 10s+"

> ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > > because every hit to the site would generate
> > > at least one or more database requests.
> >
> > Only the index pages, surely, as the full article
> > content hasn't been cached.
> ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> homepage and category pages would be affected.

's what I meant. So only *some* hits to the site would be affected, as a
large group are the article pages themselves (and the author pages) which
generated db requests anyway.

And the number affected would be even lower because of browser caches...

> ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > Another thing to think about - if the purpose of having
> > an occasional slow query is to cache the data for the
> > benefit of everyone else, why does it have to be a real
> > human user who suffers that delay? Why couldn't it be
> > (say) a bot scheduled on a cron job?
> ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> only if the query doesn't have any criteria based on the user's request,
> like date last logged in like the query has now.

See my query of why that has to be "since last logged in" as opposed to
"in last 24hrs" (approx - could even be "with today's date" so it's only
generated once a day)


Also starring in fine email     | "Names, once they are in common use, quickly
productions such as             | become mere sounds, their etymology being
martin at easyweb.co.uk            | buried, like so many of the earth's marvels,
martin.p.burns at uk.pwcglobal.com | beneath the dust of habit." - Salman Rushdie

More information about the theforum mailing list