[metrics-team] Cache advice for Onionoo Node.js API client

[Karsten Loesing]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 18/12/16 09:10, Luke Childs wrote:
> Hello everyone,

Hi Luke,

> I’m Luke, I spoke to some of you about Tor Explorer ( 
> https://github.com/lukechilds/tor-explorer) on IRC the other day.
> 
> I’ve separated the Onionoo bits from Tor Explorer out into a
> reusable Node.js module
> (https://github.com/lukechilds/onionoo-node-client). This will
> allow other people to easily include this module in their Node.js
> projects and use the Onionoo API with minimal effort.

Sounds great!  As you noticed at the last meeting, we're in the middle
of redoing the Tor Metrics website.  My hope is that we can add links
to both projects to the Tor Metrics website, so that users can find
Tor Explorer and other developers can find that Node.js module.

> I’m just cleaning it up and making sure everything works properly
> before publishing v1. You can track progress here if you’re
> interested: 
> https://github.com/lukechilds/onionoo-node-client/milestone/1
> 
> I’m slightly confused about how to handle caching and was wondering
> if any Onionoo devs (or anyone else) could provide some guidance on
> a couple of questions I have.
> 
> 
> 1. Cache strategy
> 
> I’m currently just saving the responses in memory for however long
> the Cache-Control max-age header value says, after the max-age has
> expired a new request will be made. However I read this in the 
> docs:
> 
>> Clients should make use of the "Last-Modified" header of
>> responses and
> include that timestamp in a "If-Modified-Since" header of
> subsequent requests.
> 
> This suggests I should be storing the responses indefinitely. After
> the max-age has expired I should do a new request with
> If-Modified-Since and if I get a 304, return my already cached
> value (and possibly update the max-age in my cache?). Just double
> checking, is that correct?

That sounds correct, assuming you have enough memory to really store
responses indefinitely.  Realistically, you could safely discard them
after an hour or even sooner.

> 2. How to calculate max-age
> 
> Regarding max-age, what is the correct value I should be using
> here? I was just using the Cache-Control max-age header value
> directly, however I noticed this often stays the same but the age 
> header increments. Possibly varnish caching the max-age header
> from Onionoo? So how should I reliably calculate the cache lifetime
> by the time I get the response?
> 
> I think this would offset the time Varnish has already been holding
> it for:
> 
> max-age - age = cache-lifetime-ms
> 
> but maybe this would be more accurate to compensate for network
> latency too:
> 
> date + max-age = valid-until-date valid-until-date - now =
> cache-lifetime-ms

It's been a while since I last looked into this, but I'd say keep it
simple and just use the first formula above.

> If anyone could offer some advice on these two issues that would be
> greatly appreciated

I guess my advice, except for the attempts to answer your questions
above, is not to over-engineer the client-side cache for this Node.js
module.  When in doubt, just make another request.  I mean, it's great
that you care about saving requests.  But I'm more worried of
thousands of mobile clients each making a handful of requests than a
server caching responses a little less long than it could.  I'm not
saying to take out caching entirely, but it's okay to find a middle
ground between sending a new request each time (bad) and waiting for
the very last second to invalidate your own cache (too good).

All the best,
Karsten


> 
> Cheers, Luke
> 
> P.S I find GitHub issues to be quite efficient for discussing this
> sort of thing. If you have a GitHub account, feel free to post
> replies in the cache issue: 
> https://github.com/lukechilds/onionoo-node-client/issues/2. If
> you’d rather not use GitHub, no problem :)
> 
> 
> 
> _______________________________________________ metrics-team
> mailing list metrics-team at lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team
> 

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCAAGBQJYVnIlAAoJEC3ESO/4X7XBLD4H/2aZUKQFkm3lpu/2eKtNL9yN
quxmHFa9n7Q18ahbwo+qYg9FgBqe2NzFUJgtcS8ACiWW4VC6KbimxZzE3wsTEClD
SBX/FAmFik3fU9B9z3iRsHrHitqDIVOD+EpzCZ6H7pTB+eWunDzh0z5LMAHxmadM
/zIKFl9uYVdalM1S/BIjUbP2RA4sSmdsCR0XiAphaJedUl29gD1yae6isVUSgaEt
L2bpLfwErc+rzU/KxmNkuCEFI23Fgx+e6Tp37YUu50DHM0EkGtxWj0lHGcdzGdRe
EFcTDkAhoSiMTSHceoNFGT9qrRCq5jFotSgISbaXJ7bp4Sm60QaOo03p19nN80k=
=k+ve
-----END PGP SIGNATURE-----