"Voytek Eymont" <li...@sbt.net.au> writes:
> On Sat, September 18, 2010 7:17 pm, Daniel Pittman wrote:
>> "Voytek Eymont" <li...@sbt.net.au> writes:
>
>> A screen draw? Are you running X locally on the system, or is this on your
>> client? Neither one necessarily points to RRD 1.2 vs 1.4, although it
>> could be involved in either.
>
> sorry, I meant lag to generate /populate graph images in the browser, to
> load the cacti graph page in a browser on a client over ethernet
OK. So, just to check: can you reproduce this performance problem with a page
that contains only one single graph?
One of the big performance ... well, not problems any longer, but issues with
our use of munin in-house is that the default view for a host contains
something like 60 or 80 graphs[1].
Using the CGI or FastCGI drawing model this, by default, means that we fired
off something like 120 processes on the machine when we visit that page. That
caused some performance delay in getting results, because they all took about
the same length of time to draw, and were all CPU hogs...
So, it might be worth checking if your problem isn't RRD, but rather the fact
that you have lots of instances running concurrently on an old and slow
machine[2] that just take ages to start delivering results.
Daniel
We fixed it my limiting concurrency, so you get less overall delay, and faster
initial results, out of the system.
Footnotes:
[1] We love us some metrics, and how!
[2] Heck, with a P4 or Celeron it wasn't a fast machine even back in the day,
thanks to Intel's foolish micro-architecture decisions and all.
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
