Faster web frontend? Using 1000 hosts and 4300 service checks

tripping tripping at gmail.com
Wed Jul 21 01:36:04 CEST 2004


On Tue, 20 Jul 2004 13:41:37 -0700 (PDT), Ben <bench at silentmedia.com> wrote:
> I'm suffering from the exact same problem, and yes, after applying the
> chained hash patch that introduces the cgis to glib, the biggest
> bottleneck is the constant repulling of all the status data.
> 
> Apparently the nagios 2.0 code in cvs caches object data, but I'm not
> convinced that's going to be good enough. Does anybody know about the
> status of keeping, er, status data in a database in 2.0? It seems that
> database support has been yanked, for some reason....
> 

Yeah, I'm not sure that a database will necessarily help.  When I look
at the server when it's running the cgi's it's totally cpu bound, so
I'll give the chained has patch a try and will report back.

The problem, even with the patch, at least for me, will be that it's
not just one person looking at the html pages.  Replacing the default
index.html with a static version of the status.cgi output using cron
and curl resulted in dramatically decreased at least for the first
glance.

If there are 5 or 10 people each with their particular hostgroup
refreshing in their browser, then the UI bottleneck is more serious.

The two areas that really eat the cpu are:

1) reading/parsing the configuration
2) generating the html based on that configuration and the current statuses

In theory, step 1) only needs to be performed on start/restart/HUP. 
Step 2) needs to occur either when the cgi request is made, or when a
new alert occurs.

Part of the elegance of nagios is the seperation of nagios from the
cgi's.  That not withstanding, I have a possible idea, please shoot it
down.


When nagios starts/restarts/HUPs:
a) reads in configuration file
b) update directory structure in /var/www/nagios/state to reflect the
configuration (whatever that may mean)
c) populates directory structure with info from status.sav, if so desired

>From this point on, whenever a nagios alert is received, in addition
to being logged, something is twiddled in /var/nagios/state.

When a user visits http://blah/nagios, the php pages generate
essentially static pages from static content on the disk, which should
be orders of magnitude faster, and in theory, should be just as up to
date.


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
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





More information about the Users mailing list