WEB-Interface performance

Sébastien Barbereau barbereau at gmail.com
Sat Oct 8 12:41:59 CEST 2005


Hi to all,
just adding my 2cents here:
I agree that html page generation from the CGI is one of the major
performance bottlenecks for display in Nagios. This is particularly true
when you have 10 users querying the same CGI every 90seconds ...
but, why not use some caching mechanism to prevent the repeated cgi
execution? You dont't have to modify nagios for this, you could just use
apaches mod_cache / mod_proxy or squid for example.
 Seb.Barbereau
 On 10/8/05, Andreas Ericsson <ae at op5.se> wrote:
>
> Marcel Mitsuto Fucatu Sugano wrote:
> > Hello again,
> >
> > On Thu, 2005-10-06 at 11:16 +0100, Rob Moss wrote:
> >
> >>Yeah, there are some CFLAGS you could be using to optmise your build..
> >>I am assuming that you have a recent version of GCC, and that your P4
> >>HT cpu is shown as having two logical CPU's
> >>
> >>Try rebuilding with the following command:
> >>
> >>cd nagios-2.0b4
> >>CC=gcc CFLAGS="-mtune=i686 -O3 -pipe -march=i686 -funroll-loops
> >>-ffast-math" \
> >> ./configure --prefix=/usr/local/nagios ...... [rest of nagios
> >>configure commands]
> >
> >
> > I've tried this with no luck, having an error message displaying that
> > -ffast-math wasn't a recognized flag, with gcc-3.3.5. This was the
> > second try to handle the cgi's performance. The first thing we tryied,
> > was setting up a tmpfs mountpoint at /opt/nagios/var/tmpfs, and pointed
> > nagios to write the status file there, but again with some errors that
> > was a little weird, the cgi begins to ending prematurely (apache
> > errorlog), and displaying "500 internal server error". This happened to
> > 10% of the check_http running to test it :), and the response time
> > didn't get too much of a performace improvement as well.
> >
> > I don't think this could be Virtual Machine OS's fault, so the problem
> > might be with the status.cgi reading the tmpfs, but i can't tell for
> > sure, as we tried this setup yesterday. Is there anyone here who made
> > it? (status.dat been written in a tmpfs mountpoint?)
> >
> >>The main problem is that you have thousands of hosts, and thousands of
> >>services to read in every time you run status.cgi. No matter how
> >>efficient the program is, reading in and displaying that much data is
> >>going to take a while, and running the same program 15 times
> >>simultaneously is going to affect your performance as you see here.
> >>How many lines is the status.dat file? I only have a few hundred
> >>hosts and services, and the file is 23,000 lines or so, half a meg on
> >>disk.. I would imagine yours is closer to about 50mb and closer to a
> >>million lines.
> >>Some alternatives might be updating the Nagios sidebar so that it
> >>doesn't display ALL hosts by default, maybe just a smaller hostgroup..
> >>(although i suspect the status.cgi needs to read in the whole file) Or
> >>replacing the standard nagios CGI's with something that is more geared
> >>towards handling hundreds of thousands of hosts/services...
> >
> >
> > I agree with you, and i've been reading the nagios-devel list, and saw
> > that the CGI is a problem to a lot of people who need to maintain some
> > BIG nagios configuration, over 10k services. I also watch that there is
> > a patch to improve the performance of the CGIs, but I couldn't find it
> > anywhere.
> >
>
> Browse the list archives. Search for "binary cgi" and stuff like that. I
> haven't tested it myself, but according to the author of the patch he
> noticed a performance increase of factor 30. I had objections to the
> patch because the code was definitely non-trivial and included quite a
> bit of black pointer magic. In short, I didn't like it because it would
> be hard to maintain and wouldn't work too well in certain circumstances.
>
> >>Or perhaps you could have a separate display server, a webserver
> >>running the cgi's which reads in the nagios status.dat file over the
> >>network from the nagios server, and does all the processing away from
> >>the nagios collector.. This would move processing off of the nagios
> >>collector.. You could use rsync to keep the two files in sync, keep a
> >>duplicate on the display server on a local disk (or a tmpfs memory
> >>based filesystem for extra speed)...
> >
> >
> > We are studying the mysql backend, but my first shot was the tmpfs, and
> > the recompilation with those flags you mentioned. Hope that exists
> > something easier than setup a mysql backend,
>
> nagios-db with postgresql is most likely the fastest option available
> today. We're planning on writing a new gui that will, hopefully, be more
> complete than the current nagios-db one and which will also use a
> database backend.
>
> I'll let the list know when there's something to download.
>
> --
> Andreas Ericsson andreas.ericsson at op5.se
> OP5 AB www.op5.se <http://www.op5.se>
> Tel: +46 8-230225 Fax: +46 8-230231
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> ::: Please include Nagios version, plugin version (-v) and OS when
> reporting any issue.
> ::: Messages without supporting info will risk being sent to /dev/null
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20051008/e634f910/attachment.html>


More information about the Users mailing list