One of the biggest hurdles which has taken up a majority of our time behind the scenes is working on speed. Since we've been archiving huge amounts of rp-related posts we've gathered 220,000 posts and 4.03 million comments that are being indexed and full-text searchable on forums.red.
That's a heck of a lot of content to sort through, and the old framework for retrieving these results does not operate the way we want it.
We've always had a layer of caching, but with custom views, new sorting methods, and individually tailored feeds on trp.red, the caching mechanisms we were using have not kept up.
One solution that we've already implemented was upgrading our hardware. We knew as our traffic increased that this was going to be a bridge we would need to cross. And thanks to the contributions here, we've been able to do this.
But we still have much to do in the way of query optimization, table design, and server-side caching.
One of the new features we're working on is the Private Tribe feature. It exists similarly to the Daily Prescription feed, except it's private to you and only the friends that you invite into the tribe.
Because it uses primarily the same functionality of the main feed, we've had to focus on overhauling our caching for the main feed.
On each page load there are a number of data-driven events for TRP.RED:
- Check session and ensure user is who they say they are / logged in.
- Load friends list
- Check notification counts and message counts for header notifications.
- Load specially tailored feed that displays users you subscribe to (friends).
- Load contents of feed and put it through the design layer.
- Load IRC log.
Most of this does not change very often, as as such needs to be cached in a clever way. The issue then becomes this- if your cache grows too large, does the cost of querying the cache exceed the cost of the original queries.
It's not an easy question when you consider the variables at play. Is the cache better with more active users / less active users? How does this interact with query caching in the database?
Anybody familiar with the problem likely knows the solutions are to cache what doesn't change often, and to cache only the content that shows on the first x number of pages since these will be the most commonly loaded.
And this is what we're doing on forums.red.
But the problem with trp.red is that the feed is unique for each logged in user.
Although we've got quite a few registered users, during any given hour, only a small fraction of our userbase is logged in at the same time. During their visit, they may request the same content a dozen or so times. For each user, the experience is much smoother if it doesn't require round trips to the much larger database tables each time.
The trick to handling a custom feed is to separate the set of post identifiers for each user, and the content of each post. Since most users share friends, it doesn't make sense to request the same post content and cache it for each user who will see it. You only need to cache it once.
Then, the only work that needs to be done is to get the unique index of posts that each user would see. Less work, smaller cache.
Couple this with some table optimizations to archive older content that rarely gets served, and you've gone done and improved the experience on your website.
Right now, for a user who hasn't been online in a week, to do a fresh login to trp.red can sometimes take up to 3 seconds for the initial page load with the current caching scheme. This has slowly crept up from our original launch in which pages loaded in mere fractions of seconds. Not great.
Our updates that we're working on now has that initial load well under half a second, and subsequent requests under 0.05 seconds.
We hope to bring these features live very soon, as they are almost complete.
And as always, thanks for your continued support. We greatly appreciate it and it helps us continue the work to provide censorship-free alternatives.