Production cleanup tasks.

[stevenvandervalk]

• Linting of js
• Cleanup of css, html
• Benchmarking of serve times and caching changes?

Previously tried the first but broke js on qa-deploy so need to test more systematically.

[stevenvandervalk]

1. and 2. dealt committed and passing local tests in https://github.com/vecnet/dl-discovery/tree/qa-deploy-rollback
2. Both http://guides.rubyonrails.org/caching_with_rails.html and suggest shifting to ActiveSupport::MemoryStore if we have the extra ram to spare to deal with slow load times. But perhaps vecnet production has some other cache in place - if this even an issue in the first place!

@dbrower if we end up having a chat during the week, you can say if this is even an issue.

[dbrower]

I'm all for adding caching. I think either a file store, which i believe is the default, or redis store are better than the memory store. We are running redis, so that would be easy to get going.

first, though, is whether we are even caching any partials. Also, I know the original backend is very slow. In which places is the discovery interface slow? For the most part it is getting its data from the database and from solr, both of which are pretty fast.

[stevenvandervalk]

Yep file store is the default. Cool I think redis is a good option so long as the network cost lag is low. So we need to check the benchmarking however.

Currently not caching any partials but I think we should consider the common elements because not much else changes really. I could ask the blacklight/geo guys what they are thinking in that way as well? I don't anything is that slow personally but always check the box in case?

[stevenvandervalk]

Also is your nginx handking compression of some kind, don't think this app has rack::deflater on.

[dbrower]

I think redis is on the same host as the ruby code, so there is not really any network latency.

Also, I think i tried to set up compression on nginx, but I don't know if it is working.

We could also cache pages in nginx, which is turned off at the moment. Or at least cache public pages. But since a fair number of results are private or what not, I think adding fragment caching to the application would also be a good idea, and that would be my preference between nginx caching and rails caching.

[stevenvandervalk]

Ok let's setup redis and fragment caching on the common partials? Will need to record the current serving times from qa-deploy to compare against i guess. Sent an email to arrange a time to chat and kick start it etc.

[stevenvandervalk]

https://github.com/redis-store/redis-rails seems the current preference.
Also curious about http caching, never tried it before with redis.