How does it compare to other caching solutions?

[ezequiel6arrido]

I noticed Surge has some benchmarks in the plugin's description.

In various load tests, Surge has shown to easily handle 1000-2500 requests per second at 100 concurrent, on a small single-core server with only 1 GB of RAM. That’s over 70 times faster than a stock WordPress install.

It seems to me a natural follow up question would be how does it compare to other caching solutions, either plugin based (WP Super Cache, WP Fastest Cache, WP Rocket, etc.), or server based (OpenLiteSpeed Cache, or propietary caches like Kinsta's).

Is the point of Surge to be a performant plug and play cache plugin (as opposed to the configurable options), or the best performing cache plugin (which also happens to be plug and play)? I suspect its somewhere in between, but I'm not entirely sure.

Would love to hear about how you've done the benchmarks and, if at all possible, contribute in the "comparison" department.

Let me know if I can help, thanks.

[kovshenin]

Thanks for your question! Every caching plugin is slightly different and it's fairly tricky to do a fair comparison, especially since most caching plugins will have a lot of different settings that can make or break a benchmark.

In general however, Surge is on par with the rest of advanced-cache.php based plugins out there, slightly faster in some cases due to its simplicity, also faster than anything that's based on Redis and Memcached (Batcache) due to the additional TCP round-trip required to an external service.

Mostly all server-side solutions (or caching at the edge for that matter) will outperform anything that's based on advanced-cache.php, simply for the reason that they don't hit PHP at all, but most of them work great in addition to Surge, for example Nginx's FastCGI cache, even with a very low TTL plays really nicely with Surge.

Here are some relevant benchmarks if you're interested:

• https://konstantin.blog/2021/page-caching-filesystem/
• https://konstantin.blog/2021/redis-vs-memcached-vs-file_get_contents/
• https://konstantin.blog/2021/php-benchmark-include-vs-file_get_contents/

[ezequiel6arrido]

Hey, thanks for answering! Will do my best to make some follow up questions because I believe a modest benchmark should still be possible.

Thanks for your question! Every caching plugin is slightly different and it's fairly tricky to do a fair comparison, especially since most caching plugins will have a lot of different settings that can make or break a benchmark.

❓Would comparing it with recommended configuration of other advanced-cache.php based plugins be productive?
Say WP Super Cache, WP Rocket or W3 Total Cache.

I'd argue the results may not be negligible considering this chart by the LiteSpeed Cache plugin authors showcasing the differences between some of them, but I may be wrong.

In general however, Surge is on par with the rest of advanced-cache.php based plugins out there, slightly faster in some cases due to its simplicity, also faster than anything that's based on Redis and Memcached (Batcache) due to the additional TCP round-trip required to an external service.

❓We're talking about Redis/Memcached performance when caching static pages right?

I understand how Surge would outperform the round-trip in static pages, but I don't think they're comparable when talking about caching private user database queries in dynamic pages, but I may be wrong (a bit out of my depth here 😅).

Mostly all server-side solutions (or caching at the edge for that matter) will outperform anything that's based on advanced-cache.php, simply for the reason that they don't hit PHP at all, but most of them work great in addition to Surge, for example Nginx's FastCGI cache, even with a very low TTL plays really nicely with Surge.

❓Would you be able to expand on this?

As I understand it, you've configured NGINX to cache the already cached files by Surge, with a very low TTL (1 second, microcaching), which then bypasses PHP completely (for a short amount of time) and yields a 2.5x speed improvement over sites with just Surge, which means its and incredible optimization for sites where you can control the server infrastructure.

I don't understand however why it would be better than just having a FastCGI cache running without Surge at all, wether or not you're using the microcaching strategy.

https://konstantin.blog/2021/page-caching-filesystem/
https://konstantin.blog/2021/redis-vs-memcached-vs-file_get_contents/
https://konstantin.blog/2021/php-benchmark-include-vs-file_get_contents/

Subscribed! I already know which video I'm watching the next time I have a couple hours to kill. Thanks for the articles too, I've read them and it helped quite a bit.

All that being said, I still think running some benchmarks against (friendly) competitors may be worth it, and it may even make it more obvious why zero config is (on average) better for the end user, even if, as you've said, the advanced user has to be a little be more creative to get what it wants.

Thank you and have a great day.

[kovshenin]

I'd argue the results may not be negligible considering this chart by the LiteSpeed Cache plugin authors showcasing the differences between some of them, but I may be wrong.

Interesting! Where did you find that chart? Just by looking at WP Super Cache at 92 RPS I can say that the benchmark was wrong/broken. With the default setup of serving cached items using PHP, WP Super Cache is at the very list on a very similar level as Surge, W3TC, and WP Rocket, i.e. read a file, send it to the browser during advanced-cache.php. Many of these (excluding Surge) have an option to by-pass PHP completely, usually using .htaccess rules, and also on by default if it can determine an Apache-compatible environment, so depending on the setup, they should all be doing 2000+ RPS, just like Surge with FCGI Cache.

W3TC also has like a million different modes for caching requests, and 1k RPS looks way too low.

I understand how Surge would outperform the round-trip in static pages, but I don't think they're comparable when talking about caching private user database queries in dynamic pages, but I may be wrong.

I'm referring to Redis/Memcached-based full page caching plugins, like Batcache for example.

Would you be able to expand on this?

Mostly because invalidation is hard. Even if you find a way to invalidate cache entries by URL (outside of Nginx Plus), you still need a way to determine when and which URLs should be cleared + you'll have a billion edge cases. For example, a search URL will contain posts, when those posts are updated, this should be reflected in search results, with all keywords targeting those posts. Surge for example solves a lot of these invalidations, much more than you could by purging URLs in FastCGI (or Varnish, etc.) That's why having a high TTL on FastCGI Cache is quite risky, especially for sites with dynamic content or frequent changes.

Let me know if you have any other questions.

[ezequiel6arrido]

Interesting! Where did you find that chart? Just by looking at WP Super Cache at 92 RPS I can say that the benchmark was wrong/broken. With the default setup of serving cached items using PHP, WP Super Cache is at the very list on a very similar level as Surge, W3TC, and WP Rocket, i.e. read a file, send it to the browser during advanced-cache.php. Many of these (excluding Surge) have an option to by-pass PHP completely, usually using .htaccess rules, and also on by default if it can determine an Apache-compatible environment, so depending on the setup, they should all be doing 2000+ RPS, just like Surge with FCGI Cache.

W3TC also has like a million different modes for caching requests, and 1k RPS looks way too low.

Sorry I should've linked it, its the first screenshot in the LiteSpeed Cache wordpress.org plugin page. If it's really that off (I believe you), perhaps the need for some benchmarks holds true, or at the very least, a FAQ with all this info.

❓Why doesn't surge use .htaccess in an Apache context?

I understand this is the "Expert mode" in WP Super Cache, and the standard solution for WP Fastest Cache and others.
Seems to be faster but, of course, limited to Apache-like hosting environments.
I'm wondering if its a deliberate design decision in Surge, or just something you didn't get to explore yet.

I'm referring to Redis/Memcached-based full page caching plugins, like Batcache for example.

Gotcha, thanks.

Mostly because invalidation is hard. Even if you find a way to invalidate cache entries by URL (outside of Nginx Plus), you still need a way to determine when and which URLs should be cleared + you'll have a billion edge cases. For example, a search URL will contain posts, when those posts are updated, this should be reflected in search results, with all keywords targeting those posts. Surge for example solves a lot of these invalidations, much more than you could by purging URLs in FastCGI (or Varnish, etc.) That's why having a high TTL on FastCGI Cache is quite risky, especially for sites with dynamic content or frequent changes.

Ah! So FastCGI caching with a longer TTL would be faster in theory, but also more error-prone (defeating the purpose), thus microcaching the cached files by Surge would be a good compromise between speed an realiability. ❓Did I get that right?

Thanks for the quick response by the way.

[kovshenin]

Why doesn't surge use .htaccess in an Apache context?

It's a different way of storing the cached content. To be able to do that, you can only have one cached entry per URL without query variables (Surge supports as many as you like) plus they're all "public" and/or guessable by default, since Apache needs a way to proxy to these. And they also have to be in pure HTML format for Apache (Surge stores cache metadata in the same file as the cache contents). So I guess the answer to your question is simplicity, flexibility and security.

Did I get that right?

Yeah. For this very same reason it's hard to reliably cache contents at the edge (Cloudflare, etc.) for a very long time (more than a few minutes).

[ezequiel6arrido]

It's a different way of storing the cached content. To be able to do that, you can only have one cached entry per URL without query variables (Surge supports as many as you like) plus they're all "public" and/or guessable by default, since Apache needs a way to proxy to these. And they also have to be in pure HTML format for Apache (Surge stores cache metadata in the same file as the cache contents). So I guess the answer to your question is simplicity, flexibility and security.

Seems I've got a lot to read up on. Thank you so much for your insights and I'll try to make a fair comparison (if at all possible), since LiteSpeed gets it so wrong.

In the meantime, ❓ Would you prefer to close the issue or leave it open? I have no problem either way.
I feel the initial questions have been answered, the only thing that could "update" this issue would be some benchmarks or FAQs to add to the readme as soon as I can get around to contributing them.

Again, thanks for taking the time to answer my questions, and have a great day.

[kovshenin]

Happy to leave this issue open if you're planning to run some benchmarks :)

[ezequiel6arrido]

Great! Fully intend to do so.

Currently not contributing in any other OSS projects so I'd love to start here (and Sail which I'm eager to try out).

I'm fairly limited in how much time I have available though so forgive me if its a slow-ish process. Hopefully I can help in a significant way despite it.

Thanks for your time, and have a great day.

[LukaszJaro]

How does surge compare to managed hosting caching? I normally don't install any caching plugins since my host has it configured already using NGINX. Would there still be benefit of using this plugin?

[nlemoine]

Hi,

First, thanks for this great plugin. There's many caching plugins out there and it's often hard to find the right candidate. This one has definitely some innovative, amazing features.

Since this seems to be the place for discussions (maybe enable the discussions feature of this repo?), I would also raise a couple of questions/feature requests on Surge.

Filters

I really like the simplicity of this plugin and since I usually handle all the front-end optim myself, I just need page caching without any extra features (preloading, compressing, concatenating, minimizing assets, etc.).

But some filters would be nice to alter the behavior of some parts besides config.

Compression (gzip, brotli)

This missing feature is one of the reason why I'm not switching to Surge yet. It can really make a difference on page weight. Is this something you would consider?

I'll be glad to help if I can.

[iandunn]

Some parts of the config can be tweaked w/ a custom config file.