Server side cache?

[chicagobuss]

Given that tessera runs as a server side app, I have to ask - do you do any caching of calls to graphite? Or are all data calls initialized from the browser? This is the #1 reason we still use our own home-grown dashboarding system - by making the calls to graphite on the server and caching the results, it doesn't matter how many more people have dashboards open - we don't put any additional load on graphite.

Anyway, if this is already on the roadmap, I'm just curious when we'll see it - if not, I'd like to formally request this as it means we could completely switch to tessera (which I'd love to do given how nice this looks!)

Thanks

[aalpern]

Nope - all calls to graphite are made from the browser, and there are currently no plans to implement a caching HTTP proxy for graphite (if you want a dashboard system that does that now, Grafana 2.0 is moving in that direction, with a proxy for all data writen in Go).

[chicagobuss]

Gotcha, any objections to us submitting pull requests to implement optional server-side caching? Or are there design reasons to keeping all calls coming from the browser?

[aalpern]

The main issue with doing it in python is that it's single-threaded; you need to run multiple instances of tessera under a WSGI front-end (we use gunicorn) to scale if you have long-running blocking calls, so sharing the cache is a problem. Grafana's new back-end is written in Go, where you don't need to run multiple processes to achieve concurrency on a single machine.

For what it's worth, you can scale Graphite up considerably - we run with lots of users and lots of complex dashboards, and have no Graphite performance problems. I don't know all the specifics of our graphite deployment (our ops team would, of course), but it's a three-node cluster for graphite-web.

[clohtd]

Side note: Would love to see some information from your ops team on their deployment; diagram, configs, results, etc.

[aalpern]

Sure - I'll see what I can dig up.