Skip to main content ↑ ↓
Topic: Full Page Caching (Read 1570 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Full Page Caching

There are two ways to improve the performance of a system: lessen the resources/time needed to do an operation or to not have to do the operation. We've focused primarily on the former for years.

That's great. It has made SMF and Elk among the fastest forum applications. There's a huge problem with that - it really gets in the way of innovation because we spend so much time focused on micro-optimizations. As a great example, working on making BBC parsing faster. I keep going back to it but in reality, it's such a small piece of the pie and there's no need to parse the same data for every page load.

This idea has been discussed before and it always came back to a couple of issues: size of the cache, invalidating cache because of differences in permissions and settings, etc. If you don't have a few GB of RAM, you probably don't need to worry about performance anyway. Chances are more than 90% of the people are in 1 or 2 groups with all permissions and settings. They are probably in a guest and member group.

It's time to explain how it would work. This isn't a new concept by any means. It's done in just about every major enterprise application. There are two ways to do it and perhaps it's a good idea to incorporate both of them or at least, do it in a stepped feature release.

The main thing I want to focus on is the content of the page. The other parts, like the header and footer, don't generally require much in terms of queries or parsing. In the case of user data, that's already cached pretty well. When you visited this topic, the application has to do a query to get the category information, the topic information, and information for each of the messages. It has to get the user information for each of the message authors. It has to then parse the BBC in each of the messages. I might be missing some stuff, but that's a high-level overview of what it does.

Instead of doing any of that, the application could do a single request to get the parsed HTML and output that. It would collect the variables: topic id, user groups, and display settings. It would serialize those variables in an array and create a cache key. On display, it would do a cache lookup. If it's there, don't do whatever the main render function is for the page.

To set that, the template system would do the same thing that it did to generate the key. It would then buffer the output around the main content.

This could be taken a step further to allow for what's known as "punchouts". That's where your entire content is cached but you have places where it's not. Spitballing here and I haven't looked how other's do it. If an area is deemed to be a punchout (you have something specific to a user and it needs to be parsed per page), you would then want to break the output buffering at that point. Maybe a method like "startPunchout()" with a corresponding "endPunchout()". When the output gets parsed/loaded, it will hit that method and stop output buffering. When it hits the end function, it will start again. Then the template system will have an array of strings and methods to call for the punchout.

Before we get back to arguing about RAM space, all caching libraries have a method for compressing large strings. HTML, in general, is pretty compressable. Before you say "it needs to account for me having 100 user types" - you need to be smart about your configurations. If you have 100 groups of users and they have different permissions, then you probably don't want to use this system. You probably have some tiny hobby site anyway; most people wouldn't have the time to keep up with all of that if they were running a decently sized website.

The one thing that makes this kind of difficult is if you have BBC that isn't cacheable. Then each message that isn't cacheable would need to be punched-out. Luckily, there's none of that in the default BBC.

I know this is kind of a big feature, but if you're going to spend any time trying to make ElkArte more performant, you should just work on this. You'll have more gains than you'll ever have with anything else you do.