graphite-dev team mailing list archive

[chrismd <question166527@xxxxxxxxxxxxxxxxxxxxx>]

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

    Status: Open => Answered

chrismd proposed the following answer:
Hi Steve, I'd be happy to help you optimize your Graphite setup but
first I'll explain a little about how Graphite works so we can figure
out where things can be improved in your setup.

Graphite's frontend is a WSGI webapp that people generally run under
Apache using mod_wsgi. The mod_wsgi module has its own configuration as
far as how many process/threads to allocate, and you can monitor the
individual performance of each process to assess if more are needed or
not.

A good thing to note about Python in general is that while it supports
threading from a technical perspective, CPython's threading
implementation does not behave as you might expect because of the Global
Interpreter Lock. I would advise reading about the GIL here:
http://wiki.python.org/moin/GlobalInterpreterLock. This does not mean
you should set threads=1 in your WSGI config, experimentation is the
best method for determining an optimized setup and usually I start with
a few more processes than I have cores, and an equal number of threads
per process.

Rendering performance is a function of many things. How many metrics are
included in the graph, how many datapoints in the requested time range,
whether or not you have memcache running, etc. You should definitely run
a memcached instance if you are not already. Also it is important to
keep in mind how the performance is measured. If you're measuring the
HTTP response time then that includes things like how long it took to
fetch the datapoints from cache/storage. If you're measuring the
rendering times from rendering.log then it will be more of a "pure CPU"
measurement. In any case though, the rendering itself is not threaded
and there is little you can do to improve it aside from making sure you
don't have too many threads per process (concurrently rendering threads
will block one another due to the GIL). The biggest factors in webapp
responsiveness are typically I/O latency and caching configuration.

Graphite's backend is completely separate and there are many knobs to
tune in carbon.conf as well as different ways to run multiple carbon
daemons to distribute load across multiple cores (each carbon daemon
uses only 1 core at a time because of the GIL). Optimizing the backend
tends to be a deeper topic that will depend on your dataset, how your
clients feed their data in, whether or not you use carbon-aggregator,
I/O latency, memory available, etc...

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