Faster web frontend? Using 1000 hosts and 4300 service checks

[Ben]

Well, for what it's worth, the nagios check into cvs is taking me about 
5-10 seconds per page to load, compared to about 20-60 seconds before. 
That's a lot better. It's still not great, but it's a lot better.

>From checkpointing tac.cgi (which is really the only cgi I want to perform 
much better), the time seems to be about 90% in loading the status info. 
It occured to me that making a shared memory segment will help this 
*considerably*. Of course, that's going to require nagios to run on the 
same machine that the cgi's will run on, but that may just be worth the 
performance gains..... Has anybody else been down that road before?

On Tue, 20 Jul 2004, tripping wrote:

> 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
> 




-------------------------------------------------------
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