Introduce fragment caching #77
Conversation
|
how about the in-memory cache? |
|
disk is generally a bad idea because you end up with a huge number of files which is a pain to remove (think hoist prune) |
|
in-memory cache is not very efficient when used with Phusion Passenger where you have many processes responding to requests. On disk is actually not that bad if you have a single server. Cleaning up just means removing the cache directory inside |
|
Removing the directory requires you to unlink every inode, which means it is an O(n) operation, where n is the number of files. very very slow. |
|
I've stuck with the file store since we're using Passenger; the speed of clearing the cache shouldn't be a problem if we have a nightly job for it while traffic on the server is low anyway. The extra javascript code to reformat the elapsed time column in the tables allows fragment caching to be applied to several other pages, and the update_time endpoints allow the page to be more selective about when it triggers a refresh. |
| = link_to("Rebuild", rebuild_project_build_part_path(@project, @build, @build_part), :method => :post) | ||
| - if attempt.running? | ||
| = link_to("Abandon", finish_build_attempt_path(attempt, :state => :errored), :method => :post) | ||
| - cache("build-attempt-#{attempt.id}-#{attempt.updated_at.to_i}") do |
There was a problem hiding this comment.
cache(attempt) will automatically expand to a cache key which includes the id and updated_at.
* build_time_history * recent project performance stats
| = link_to("Rebuild", rebuild_project_build_part_path(@project, @build, @build_part), :method => :post) | ||
| - if attempt.running? | ||
| = link_to("Abandon", finish_build_attempt_path(attempt, :state => :errored), :method => :post) | ||
| - cache(attempt) do |
There was a problem hiding this comment.
I would like to place the entire BuildPart#show page in a cache rather than 1 individual cache for each row.
Start with two areas:
The project show page is the slowest page because of these two areas. The stats stuff generates a ton of sql queries and build_time_history is one big slow query.
Open question: what should the cache store be? Right now I am using the default which is disk but we have Redis available.
A downside to adding this caching is I had to add
touchto the project -> build -> build_part -> build_artifact chain. Theupdated_ats are going to be changing frequently in order to make cache expiration easy.