Feature #23
Page caching
| Status: | Closed | Start: | ||
| Priority: | High | Due date: | ||
| Assigned to: | yossarian | % Done: | 0% |
|
| Category: | Core | |||
| Target version: | 0.4 - Rebel Yell (2b || !2b) | |||
| Resolution: | fixed |
Description
We need to cache pages, although this could be pretty tricky because of the user-login system (need to investigate this more, maybe can do partial caching...)
History
Updated by yossarian over 3 years ago
- Status changed from New to Assigned
Page caching is now done on the show actions of all Content subclasses. There is a sweeper which also wipes the home page whenever a Content subclass (Article, Event, Video) gets created, updated, or destroyed.
The last 2 tasks here are:
- remove the role-specific stuff for admin access in the show pages for Content subclasses
- fix up the Apache config on the deployment servers.
Updated by yossarian over 3 years ago
Role-specific stuff has now been taken out, meaning that full page caching is now active for all Content subclasses and the home page. The apache config has also been updated.
More remains to be done. There seems to be a problem with apache currently, hitting any content show page (such as events/show/x) doesn't trigger rails, but the homepage is not being pulled from the cache despite the fact that Rails has correctly generated the index.html page in the cache.
I'm not sure why this is the case but it's obviously crucial to get this working. Another important thing is to cache the "featured videos" data which is also currently getting pulled every time from Rails.
Future directions in caching¶
For later, it would be good to rewrite the urls for the list pages so that a list page shows all content in a certain date range. This will allow us to avoid the Mir problem where publishing one article requires us to update all list pages to keep things in sequence - instead we can just update the single list page where the change has occurred. This is probably desirable anyway, I'd rather look through archives on the basis of "all articles published in from May 1 - May 7 2008" than "page 200 of 1000", it just makes more sense.
Other prime candidates for caching include all of the event listings pages, the calendar view, and the timeline data.
Updated by yossarian over 3 years ago
- Status changed from Assigned to Closed
- Resolution set to fixed
The front page is now working from the cache. Happily, the site pulls the JSON data for featured videos from the cache, meaning that there are no database requests at all on the front page of the site.
I should probably add some extra sweeper functionality to content subtypes, mainly because an update to an article, event, or video may need to update the cached page for any associated articles, events, or videos...however I'll put that in another ticket and will close this one so this doesn't turn into War and Peace.