We've already optimized Backdrop to the point that a database connection is not necessary if you're using an alternative cache-backend like Memcache. Even though the database is unnecessary except for the single query to get the cached page, we still need that database connection just for that single query.
I was experimenting with using a flat-file cache as an alternative, a basic port of https://www.drupal.org/project/filecache. The results were fairly promising running ab -c 100 -n 100 http://backdrop.local/:
Database cache:
Requests per second: 569.45 [#/sec] (mean)
Time per request: 175.608 [ms] (mean)
Time per request: 1.756 [ms] (mean, across all concurrent requests)
Transfer rate: 12078.02 [Kbytes/sec] received
File cache:
Requests per second: 741.53 [#/sec] (mean)
Time per request: 134.857 [ms] (mean)
Time per request: 1.349 [ms] (mean, across all concurrent requests)
Transfer rate: 15727.74 [Kbytes/sec] received
So roughly a 30% performance increase in cached page delivery. The downside is that the disk becomes littered with non-sense cache files. But as far as disk-space goes, this is no different from the page cache, which takes up just as much room, but it's hidden away in the database.
If we can test this approach on various servers and consistently get a similar increase, I think we might consider bundling a flat-file cache and using it by default for the page cache.
Recent comments
You can edit this View (/admin/structure/views) to suit your needs. The MORE link is used to display additional results, which can sometimes be useful.
Blog module questions
Hello, I have a question about the block “Recent blog posts”. I've set it up so that the five most recent blog posts are always displayed on the page (mybackdrop.de/blog) at the TOP...
Blog module questions
I fixed the usage statistics again today and filed an issue against Project module to fix it permanently: https://github.com/backdrop-contrib/project/issues/66 The short explanation is...
July 16th, 2026 - Weekly Meetings