context caching - in memory vs. file

[ndushay]

@darrenleeweber said he would look into this -- whether it will save us anything or not. See #96 for background.

We may be caching from a file at the moment with rack cache.

[dazza-codes]

The issues here are:

• whether or not the json-ld context documents provide adequate cache information in the header response for a HEAD or GET request
• the benefits of using an in-memory store for the meta-cache, see options documented at http://rtomayko.github.io/rack-cache/storage

[dazza-codes]

With regard to cache headers for the json-ld contexts, the header data below was retrieved for the IIIF contexts. Most of the cache data does not declare it 'public' or 'private', so I'm not sure what that means, but it might be clearer if it were 'public'. The expiry is set for about a day and there is a Last-Modified value, which is not too bad, although this data may in fact have a much longer expiry if it not changed much. An Etag header might be useful for this data, esp. if it doesn't change frequently.

$ curl -I http://iiif.io/api/image/1/context.json
HTTP/1.1 200 OK
Date: Mon, 30 Mar 2015 19:36:53 GMT
Server: Apache/2.2.15 (Red Hat)
Last-Modified: Fri, 27 Mar 2015 23:04:07 GMT
Accept-Ranges: bytes
Content-Length: 775
Cache-Control: max-age=86400
Expires: Tue, 31 Mar 2015 19:36:53 GMT
Access-Control-Allow-Origin: *
Content-Type: application/json

$ curl -I http://iiif.io/api/image/2/context.json
HTTP/1.1 200 OK
Date: Mon, 30 Mar 2015 19:37:19 GMT
Server: Apache/2.2.15 (Red Hat)
Last-Modified: Fri, 27 Mar 2015 23:04:07 GMT
Accept-Ranges: bytes
Content-Length: 2544
Cache-Control: max-age=86400
Expires: Tue, 31 Mar 2015 19:37:19 GMT
Access-Control-Allow-Origin: *
Content-Type: application/json

$ curl -I http://iiif.io/api/presentation/1/context.json
HTTP/1.1 200 OK
Date: Mon, 30 Mar 2015 19:37:39 GMT
Server: Apache/2.2.15 (Red Hat)
Last-Modified: Fri, 27 Mar 2015 23:04:07 GMT
Accept-Ranges: bytes
Content-Length: 4022
Cache-Control: max-age=86400
Expires: Tue, 31 Mar 2015 19:37:39 GMT
Access-Control-Allow-Origin: *
Content-Type: application/json

$ curl -I http://iiif.io/api/presentation/2/context.json
HTTP/1.1 200 OK
Date: Mon, 30 Mar 2015 19:37:42 GMT
Server: Apache/2.2.15 (Red Hat)
Last-Modified: Fri, 27 Mar 2015 23:04:07 GMT
Accept-Ranges: bytes
Content-Length: 4235
Cache-Control: max-age=86400
Expires: Tue, 31 Mar 2015 19:37:42 GMT
Access-Control-Allow-Origin: *
Content-Type: application/json

$ curl -I http://www.shared-canvas.org/ns/context.json
HTTP/1.1 302 Found
Date: Mon, 30 Mar 2015 19:38:15 GMT
Server: Apache/2.2.15 (Red Hat)
Location: http://iiif.io/api/presentation/1/context.json
Cache-Control: max-age=3600
Expires: Mon, 30 Mar 2015 20:38:15 GMT
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1

Note that http://www.shared-canvas.org/ns/context.json redirects to http://iiif.io/api/presentation/1/context.json.

[dazza-codes]

I've compiled related notes about caching in another issue, see https://github.com/ld4l/marc2linkeddata/issues/1

[dazza-codes]

With regard to rack-cache storage options:

• the defaults for rack-cache use in-memory heap space for the meta and entity stores
• triannon explicitly sets the meta and entity stores on the file system (instead of heap space)
  • Naomi wonders whether the rack-cache code might be using in-memory objects even when the meta/entity cache stores are on the file system?
• One recommendation at http://rtomayko.github.io/rack-cache/storage is to use an in-memory option for the meta store and a file system option for the entity store.
• If triannon is caching only a very limited number of HTTP resources (i.e. only a few json-ld context files), the system may perform much better by using the default heap space.
  • If there is a concern about using too much of the heap, another in-memory option is memcache (which would require an additional dev-ops and deployment system dependency on memcache and a project dependency on the dalli gem).
  • if there are only a few files to cache, using in-memory options for both the meta and entity store could provide the best performance.

[azaroth42]

How do we get this issue closed? :)

[ndushay]

1. @cbeer amends pull request to RDF gem
2. RDF gem merges cbeer's pull reqeust
3. RDF gem cuts a new release
4. we figure out how to do caching with changes
5. we implement caching anew with changes

[azaroth42]

Assigning to @cbeer :) Please re-assign when we're not blocked by the RDF gem.

[azaroth42]

@azaroth to Poke Gregg.

[ndushay]

resources:

http://rtomayko.github.io/rack-cache/storage (see "memcached storage" section) if dalli: https://github.com/mperham/dalli

Doing this requires a memcache daemon to be running on the Rails box, which means some more devops set up on the rails boxes and some configuration tweaks in the app itself (not the gem, but the app).

Testing that we are using the memcache - I'm sure there's a way, but it's not something we can automatically test.

Using the memcache approach for triannon's specs -- not sure how we'd do that either, though I'm sure it's possible to have rake task spin up memcache daemon etc. Dunno if travis would like it or not.

[ndushay]

@azaroth42 and I conclude that this will be tabled for now. Perhaps to be revisited when triannon goes to prod and/or when triannon has more realtime users.

[azaroth42]

There's easier places to make performance improvements than this particular issue. Lets get feature complete and then look to optimize, rather than prematurely make small and expensive changes.