On Wed, Feb 17, 2016 at 7:16 AM Stas Malyshev <[email protected]> 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 :-)
_______________________________________________ Wikidata mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata
