On Wed, Feb 17, 2016 at 7:16 AM Stas Malyshev smalyshev@wikimedia.org wrote:
Well, again the problem is that one use case that I think absolutely needs caching - namely, exporting data to graphs, maps, etc. deployed on wiki pages - is also the one not implemented yet because we don't have cache (not only, but one of the things we need) so we've got chicken and egg problem here :) Of course, we can just choose something now based on educated guess and change it later if it works badly. That's probably what we'll do.
Wouldn't those usecases be wrapped in an extension or WMF-controlled
JavaScript? In that case, queries could always indicate that use, and they could be cached, for hours if need be. No reason to put everything behind a long cache by default, just because of those controllable cases.
Also, what about creating more independent blazegraph instances? One (or more) could be for wiki extension queries, with long cache; others could be for Labs use (internal network only?), a "general" external-facing server, etc.
If the problem (and it's not even certain we have one) can be mitigated or solved with throwing a few more VMs at it, I'm all for it :-)