Cache cacheable content and investigate additional caching options

[decimalator]

Descriptive summary

OD1 is still able to take advantage of Rails 4's Page and Action caching, as you can see with the following command on OD1:

memcached-tool localhost display

Rails 5 removed the integrated Page and Action caching, which means OD2 does not yet have the same level of caching that OD1 has.

Without widespread caching, OD2 is going to have a difficult time handling large amounts of traffic. We are able to take advantage of other caches like ActiveFedora's LDP cache for Fedora content. We have Blazegraph for caching triples. We have caching for SQL queries to our primary PostgreSQL database. But to handle larger amounts of traffic and decrease overall response times we need more caching for our Rails frontend application.

Without caching, Rails has to query backend services for every request, which manifests as longer and longer response times as backend services get more busy. Our average response time when the system is relatively idle ranges from 1.5 - 2.5 seconds. While large amounts of Sidekiq jobs are running this can increase to 5 seconds to 20+ seconds.

With more caching we can maintain a more stable User Experience regardless of how busy the overall system is. This will also help to lighten the load on backend services. In addition to the extra resources that background jobs will have available, caching can be added to background jobs where it makes sense to speed them up even further.

Since earlier this week we're now hooked up to memcached via Rails.application.config.cache_store. We can write and fetch keys from the Rails.cache. Without anything taking advantage of that our cache_store is empty, or mostly empty.

irb(main):034:0> Rails.cache.stats["memcache.od2-prod.svc.cluster.local:11211"]["total_items"]
=> "1"

This was after creating and clearing keys manually, otherwise it would still be returning 0.

Out of the box we can cache fragments and partials

To make use of caching for OD2, we will need to add caching code for content that should be cached.

Additionally, Rack Cache can cache content without changes to code. See the References section for a link.

The Page and Action caching that are missing in Rails 5 are available as gems, which we should test on Staging. See the References section for links.

We can also do low level caching with Rails.cache.fetch() and Rails.cache.write() for data from backends that won't change often, or are acceptable to be eventually correct. Whether that's SOLR query results, or responses from other external APIs, if the response changes infrequently or eventually correct results are ok we should be caching them. See the low level caching section of the Ruby on Rails Caching Guide for details.

Expected behavior

Infrequently changed content should be cached wherever possible.

We should be seeing increasing numbers of items in the memcache cache_store.

References

https://guides.rubyonrails.org/caching_with_rails.html https://rtomayko.github.io/rack-cache/configuration https://github.com/rails/actionpack-page_caching

[decimalator]

We do get SQL record caching... per session. The cache is destroyed when the transaction is completed. There might be SQL queries that we want to cache to actually avoid repeated identical SQL queries from reaching Postgres

[wickr]

Solr has some built-in caching/etags/etc support, though we have to be careful that's it's broken/updated as desired: https://github.com/OregonDigital/OD2/blob/c004fd1aa1786419ffc585cb6f1f91b1d9f0183d/config/solr/conf/solrconfig.xml#L625