graphite-dev team mailing list archive

[Chris Davis <chrismd@xxxxxxxxx>]

Ok cool that makes sense. I will revert my earlier changes, sorry I didn't
notice that distinction.

Also, on a related note I noticed you have committed a lot of new things to
trunk which is great but I do have concerns with the addition of threading
to render/views.py and render/evaluator.py. I understand the goal is to do
the I/O calls in parallel, and its entirely possible that this will be
better in most cases but I need to load test it before I can deploy it to my
production systems. Since I have a deployment coming up this week I would
feel more comfortable moving these changes to another branch and removing
them from trunk for now. I'll register another branch called something like
lp:graphite-threaded-io and put it on the project page. Hopefully I can get
it all tested and possibly merged back in for the next release in February.

Anyways, thanks again for all the recent work!

-Chris

On Sun, Jan 24, 2010 at 4:49 PM, Kraig Amador <kraig@xxxxxxxx> wrote:

> yMax and yLimit work differently. yMax will force a graph to always have
> the upper limit of yMax. yLimit will allow for an upper limit based on the
> data in the series and only takes effect when the series is greater than
> yLimit.
>
> For example you have a series that normally stays around 100. Using
> yMax=1000 your graph is always pinned to 1000, even with the data is no
> where near this. With yLimit=1000 the graph will stay at its natural scale
> around 100 until the series breaches yLimit at which point the scaling is
> stopped at yLimit.
> _______________________________________________
> Mailing list: https://launchpad.net/~graphite-dev<https://launchpad.net/%7Egraphite-dev>
> Post to     : graphite-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~graphite-dev<https://launchpad.net/%7Egraphite-dev>
> More help   : https://help.launchpad.net/ListHelp
>