Panels caching on d6
We're getting close to relaunching our site (information.dk - see http://drupal.org/information.dk) on Drupal 6. We're still using panels. This time it the SUPER panels3 for D6. However we have one concern and that is speed.
On d5 we used panels_preempt, but right now there seems to be no other cache for Panels 3 than Drupals page cache or panels3's simple cache. Have any of you got an alternative?
The optimal solution would be a cache, that is not generated on a page request, since loading the non-cached frontpage panel could take a while. Too long for users to wait for it. Since the panel content is the same for our registered and anonymous users, the cache wouldn't have to be user specific. Of course it should use standard caching procedures, so cached content could be stored in Memcache, APC or static file cache.
Any ideas? If you have any suggestions, please let me know :-)
Best
/Johs.
Panels Caching Engines!
I've been thinking ahead to this as well, as we have some Panels3 sites in the pipeline.
Currently the "Simple Cache" uses cache_get/set, so while it doesn't define its own specific cache table, it can be made to take advantage of memcached, APC or static file cache.
That should satisfy your scenario, except for the "not triggered by page load" part. Currently most drupal caching is triggered by a pageload, which is why clearing the cache makes the site slow for the next cycle. However, it's not that hard to write a script or function that "pre warms" the cache.
There's also a great new
hook_panels_cache()which can be used for more custom, robust or exotic caches. Certainly it would be nice to have an alternative that used a dedicated cache table (e.g. cache_panels) and contained an option to pre-warm or freshen the cache outside of a user-generated page request. Totally possible now too!http://www.chapterthree.com | http://www.outlandishjosh.com
We're using Panels 3
We're using Panels 3 in our new configuration that will launch in a small market in a couple of weeks. I'm not sure about the exact caching configuration, and the guy who would know is on vacation. We do use memcache for all of our caching inside of Drupal, and Squid to protect Drupal from needless anonymous traffic.
Pre-caching
Johs wrote:
I think generating static cache on a page request would be fine if the previous cache is shown to the user at this moment (for speed), and then -immediately after showing it- the cached page is regenerated if that page was marked as expired (but kept and not deleted until serving it for that page request). Then the refreshed cache would wait for the next page request to be shown for the first time. This is of course just an idea of what I would like, basically for speed considerations.
Well, maybe this is not so essential since users are just randomly affected by expired cache and slow non-cached pages. But I think a solution like this one would be nice.
There are for example some Boost's issues on pre-caching, but I'm not sure how this is currently done.
Boost Pre-Caching
How it's going to work:
The page gets flushed via cron, then if that page has been marked to be pushed out it will then use the crawler and hit those pages. Crawler is now platform independent; I need to make one that uses the drupal database. The export code uses the Drupal Batch API, and that doesn't work when run from cron.