Setting minimum cache life time and clearing only the expired entry from the cache???

Running cron shouldn't force pages to be re-cached. Do you have code that your cron runs that clears all cache? cache_clear_all() ?

All content WILL need to be re-cached whenever a node is added/updated/removed (this is a core function with Drupal). Like you suggested, "1. Setting a minimum cache lifetime. Say 2 days." is what we use on our site. I use a web-crawler which crawls the whole site nightly, and I set the cache lifetime to be 18 hours. Please know that the "minimum cache lifetime" on the "Performance" page doesn't actually work because Authcache uses its own code for that stuff.

I also use the blockcache_alter module which automatically clears the block cache. I've modified it so that it re-caches any nodes that the block appears on. This seems to do the trick for us.

Here is more information on how we use this module: http://drupal.org/node/768874

If it's ran just after 20 hours, it will clear 200 of them, if it's ran after 25 hours, it will clear all 500. Works pretty well on my site.

FYI, it's node.module that makes us need to hack authcache to have a minimum cache lifetime. function node_save(&$node) has "cache_clear_all()" at the end of it, so whenever a node is saved, any expirable cache is cleared (autcache defaults all content to CACHE_TEMPORARY, which is expirable).

Feature request of minimum cache lifetime, either in Autcache settings or using Drupal core minimum cache lifetime, would be nice to have. Otherwise this function is absolutely useless to us.

You could do that, but it's discouraged to modify core code. Other modules may rely on the cache_clear_all() being there.

OK so it is very interesting that cache_clear_all() is called on node saves. But it respects the minimum cache lifetime correct? I have tested running cron and saving nodes and since I have a 1 day cache min lifetime I dont see anything disappearing from cache_page.

The problem I have is that user behavior erratic and thus the odds of hitting an uncached page is extremely likely. We have a lot of pages and translations. We have at this second 27000 rows in cache_page and yet its very easy to hit an uncached page. My work around would be this. First since I use rules + cache actions to clear cached pages on demand I could make the expiration infinity basically. I could do that on cron as a workaround since I purge stuff on demand. What do you think of that strategy?

The other issue is that if this works the number of rows will increase any more and I'm nervous as to how many rows cache_page can handle since I dont think its super fast as it is.

We use minimum cache lifetime of 30 days, figuring that most pages will be re-cached within that period anyway, due to content/block/views updates, which we use rules and some module code to catch changes and only re-cache the pages that need it.

cache_page table can increase as much as it needs, but you need to see if it's reaching the storage-limit of the DB. We have about 10,000 cached pages, so it's not as large as yours, but the performance is ~30 ms if the browser has it cached, and ~500-800 ms to pull it from the database.

How could you set a minimum cache lifetime to 30 days? The settings page only gives you 1 day as the max. I suppose you could do a form alter to add 30 days - is that what you did?

Ya I use rules and I'm tired of all my authcached pages being purged every morning. I tried to use a trick to make the created date of the cache_page data way in the future but that is still getting purged.

Let me know how you did the 30 days deal.

We originally did 18 hours: http://drupal.org/node/768874#comment-4092176

Now we've upped it to 30 days, and put in a hook_nodeapi to clear a pages cache when it's updated

OK I see what I did wrong. I had my module override the created date but the expire column was set to -1 which means temporary. So I will use the patch you used. Altho an alternative to a patch would be a cron task that overrides the expire setting.