Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.We are always looking for new ways to cache; anything at all that will help speed the delivery of iur complex, composite pages.
The single most impactful thing we have tried to date was to hand over to Redis via the Redis module. That seems to have turned hitherto sluggish pages into lightning fast refreshable ones.
Before that however, we did have a good bash with the (non-DO) LSCache module but we never seemed to be able to tweak its configuration in any useful way that allowed it to mesh with Drupal's own 'informed' cache layer.
The question here is twofold:
1) How exactly does this new module extend the ability of the LightSpeed server to cache in a more Drupal-informed way, in particular in relation to logged in users and their 'edge side' bits and pieces that need to be rendered alongside the easily-cacheable anonymous stuff.
And
2) Is there actually any real point of trying the combo if Redis is already doing us proud. Might there be a noticeable difference which, in theory at least, might shave another second?
Lastly in that 2nd point, might any attempt to get these two to play well together actually end up counterproductive?
I think I'm fairly clear in my understand of the different layers in which where Redis and LSCache focus but some real insight from someone who actually knows the nitty-gritty details is way more useful than my philosophical 'feel' approach.
Please excuse the typos and corrections along the way, I am typing on smartphone ;-)
Comments
Comment #2
sirclickalotComment #3
sirclickalotComment #4
dinis commentedHa! :)
Multi-layer caching ends up feeling like voodoo for almost everyone. Partly because the layers are invisible, partly because the bits that "look like caching" (HTTP headers, drush output, dashboard widgets) often have nothing to do with whether the cache is actually doing anything.
Worth saying why this module exists, since you mentioned a previous attempt that didn't go anywhere: there are two LSCache modules for Drupal. The LiteSpeed-published one (litespeedtech/lscache-drupal on GitHub) works on its own terms but doesn't integrate with Drupal's cache-tag system or the Purge framework. drupal/lscache is a Drupal-native alternative built around those primitives, so invalidation, status reporting, and operator experience all line up with how the rest of the Drupal cache stack behaves.
Now to your actual question. Redis and LSCache live at different points in the request lifecycle, so they stack rather than compete. Redis sits below PHP. It's where Drupal stores its render cache, dynamic page cache, entity cache, and so on. LSCache sits in front of PHP, in the LSWS process, before a Drupal request handler is even constructed.
In short, they play nicely together.
A request with both in place looks roughly like:
1. LSWS sees a cacheable URL, and either returns a stored response without touching PHP (LSCache hit, well under typical PHP bootstrap time) or passes through to Drupal (LSCache miss).
2. PHP starts, Drupal bootstraps, Dynamic Page Cache and Render Cache consult Redis to skip re-rendering bits that haven't changed.
3. Whatever wasn't cached at step 2 renders from the database.
4. The response goes back out through LSWS, which stores it for next time.
The win from adding LSCache on top of a working Redis setup is that requests at step 1 never reach Drupal at all. The size of that win depends on your traffic mix. Mostly-anonymous sites (which sounds like bit-by-bit.org from the URLs you listed) can land most warm traffic at step 1. Heavily-authenticated sites see a smaller win on 1.0.x because authenticated responses can't be shared between users; 1.1.x added a private-cache mode that holds an authenticated response per user in LSWS too (the .htaccess directive becomes `CacheLookup public on private on`), and 1.2.x added an ESI render element (`#type: 'lscache_esi'`) for pages that are mostly anonymous but have a small per-user chunk like a cart count or welcome banner. Both are opt-in and off by default.
On the previous-attempt thing: I can't be sure what tripped you up without seeing the config. One thing worth specifically checking is whether you see `X-LiteSpeed-Tag` headers in your responses (visible via `curl -sI`) but never `x-litespeed-cache: hit/miss`. If so, the .htaccess setup wasn't right. drupal/lscache only emits response headers; LSWS doesn't act on them unless `.htaccess` has `CacheLookup public on` (the directive that tells LSWS to cache for this vhost), and without `php_flag output_buffering off` you usually still see miss-on-every-request because of PHP's buffering. Both directives go inside an `` block. Reports > Status report tells you whether they're present, and docs/htaccess-gotchas.md in the repo walks through the configuration.
1.3.0-rc1 is the cumulative current release, carrying everything from 1.0.x, 1.1.x, and 1.2.x forward. If you'd like a hand reading your specific setup, the output of `drush rq | grep -i LSCache` and a `curl -sI` against one of your public URLs would be a good starting point.