If we're going to move to a consuming-our-own-API model, then that's going to benefit from an object caching system. Inevitably, that means Memcached or/or ElastiCache. ElastiCache has the advantage of being a turn-key setup, although Memcached seems awfully easy to install.
This ought to be pretty easy to interface with. The method to retrieve each type of content—say, a law—would take the file off the filesystem, unless Memcached is installed, in which case it pulls it out of Memcached.
The text was updated successfully, but these errors were encountered:
The only issue here is that you need as much memory as you've got data. Considering how large our dataset is we're only going to get a benefit from pure in-memory caches on things like the laws list (which is not resource intensive) and possibly a few of the more popular pages - on an "average" server, everything else will page-out too quickly to be useful. This might be a premature optimization as a result.
Honestly, if we're using static json files that have been pre-generated to respond to api requests, we'll get a much bigger benefit since it's just disk IO - which is relatively fast (though not as fast as in-memory ops) and very cheap compared to memory.
Memcached is a "least recently used" cache—it will happily optimize in the memory available to it. (Unlike APC, which has the annoying habit of deleting everything when the cache fills up.) So if it just caches the 500 laws requested the most frequently, that's pretty good. I don't see why it has to contain the whole legal code.
Separately, though, it's entirely possible that this is premature optimization. Alternately, it may well be that this is something that APC can handle quite nicely. If Virginia Decoded is any indicator, the long tail is very, very long—only a couple of dozen laws are regularly requested. Storing those in APC might provide a strong benefit to the largest percentage of the traffic (admittedly a low percentage), making it unnecessary to use an object caching system.