graphite-dev team mailing list archive

[chrismd <question166527@xxxxxxxxxxxxxxxxxxxxx>]

Question #166527 on Graphite changed:
https://answers.launchpad.net/graphite/+question/166527

chrismd proposed the following answer:
The reason rendering requests take roughly the same amount of time when
you add rawData=true is because the vast majority of the time spent
handling each request is in fetching the datapoints off disk, not
actually rendering the graph.

This is also why you can easily construct requests that take longer than
others, there are two factors that roughly determine the cost of a
request and that is the number of unique metrics and the number of
datapoints being fetched for each one. More metrics will definitely make
it take longer because each metric's datapoints exist in their own file
on disk, so drawing 100 metrics in one graph means reading 100 files.
Similarly, 10-second precision if you request the past minute thats only
6 datapoints for each metric in the graph, whereas the past month would
require a much larger read from each file.

While doing all this retrieval work on-demand may seem a bit much (ie.
reading a bunch of files every time you render a large graph) keep in
mind that it is largely mitigated by caching. Both the datapoints and
the graph itself are cached, by default for one minute (set
DEFAULT_CACHE_DURATION in your local_settings.py or on a per-request
basis using the cacheTimeout query-string param, both specify an
integral number of seconds). So if you make the same request repeatedly
(a very common case when you have a dashboard of graphs viewed by many
users), serving cached graphs is quite cheap.

Also there is a very tangible-but-hard-to-predict effect of the kernel's
own I/O caching. Especially when it comes to recently written data it is
possible that some reads require no actual I/O work at all.

-- 
You received this question notification because you are a member of
graphite-dev, which is an answer contact for Graphite.