[support] how cache works: on the fly content creation (not node) and caching

[Ivan Sergio Borgonovo]

On Fri, 1 Jan 2010 16:19:05 -0600
Larry Garfield <larry at garfieldtech.com> wrote:

> On Friday 01 January 2010 11:54:58 am Jean-Michel Pouré wrote:

> > I looked at MySQL table and they had unique indexes. This
> > is what MySQL does: it is only a desaster. It can work for small
> > sites, but when using large sites, you need a minimum of two
> > servers, one for database, the other for MySQL. And you go
> > beyond 1000 simultaneous users, you probably need a farm, which
> > will ruin you.

> Please do not spread FUD on the support list.  MySQL can be an
> extremely effective database and very fast and scalable, if you
> know how to configure and maintain it properly.  There are plenty
> of people who have such knowledge, and MySQL runs several very
> high-end sites.  (Slashdot and, oh yeah, Drupal.org come to
> mind.)  If you don't know how to maintain a MySQL database and try

Skype, Yahoo, Apple etc... for postgresql...

> to throw something that heavy at it, sure, it's going to crumble.
> The same is true of any other database, or any web app, Drupal
> included.

I wouldn't put it this way. It's like saying that a train can take
you from Hide Park to Piccadilly as well as a motorbike if you know
how to drive them.

And yeah people who has been driving a motorbike for the past 5 years
would oppose a bit of resistance before learning to drive a train
and will hardly understand how a train can be "faster".
Still a train is not a motorbike and it looks sluggish when you put
it at tasks more suited for a motorbike.

Actually for few tens of a second I was thinking to use ISAM just
for cache[1]... I wonder if this would become easier for D7. Yeah
I'm aware of fastpath... but I still meant *easier*.

Anyway even in pure speed if you compare pg with InnoDB Postgresql
became quite competitive in the past years, if you include other
factors other than "pure speed" when comparing pg with InnoDB, pg is
more than just competitive. So maybe you're right... other factors
come to play, and not just performance. Prejudice?

> 'course, if you know how to maintain a Postgres database then
> sure, you can make it sing on low or high traffic sites.  And
> someone who knows MySQL can do the same with MySQL.  Knowing your
> tool matters, no matter what the tool.

> Besides, what the OP asked about was how to selectively invalidate
> the cache to avoid running queries at all.  A rant about how
> Postgres would be faster than MySQL really doesn't add anything to
> the conversation.

url were actually a very good pk for page cache (btw many urls in
drupal are too short (255) including cache_page.cid). So I can't
complain about having to do some extra work to invalidate the cache
efficiently in my case.
I was looking if I could delay a real solution to the problem
passing the $expire parameter at page creation time... so that I
could assign longer/shorter cache times accordingly to the
probability that a certain page will become stale.
But I can't see no way to pass $expire at content creation time.
This seems to be true even for D7.

What is the mechanism governing "next general cache wipe"?

thanks

[1] I abandoned the idea so fast not because I thought that ISAM is
not suited for anything... but just because making it works properly
is not trivial and right now I don't have the time nor the need.

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it