Nagios 2.0 performance

[Ben]

I do agree, keep code trees in sync sucks. When I analyzed status.cgi 
performance before under nagios 1, it spend about 10 parts reading the 
nagios conf file, 50 parts walking lists, and about 1 part doing 
everything else. After applying the chained hash patch, the 50 parts 
pretty much went away, but the remaining 11 parts still took about 5 
seconds. (I have about 4500 services.)

Out of the box, Nagios 2 still takes about 5 seconds to load 
status.cgi.... which is still too long. My hope is that introducing 
(intelligent) database usage will speed up the cgis so dramatically for 
large installs that it will be integrated into the main tree. :) But we 
will see how it goes.

On Sep 11, 2004, at 9:30 AM, Marc Powell wrote:
>
> I'm not exactly sure of the problem you're trying to solve by putting 
> db
> support back into 2.0 that the event broker can't handle but I 
> certainly
> wish you the best of luck with that project now and going forward. It
> seems to me that trying to keep your code in sync with Nagios releases
> would be problematic.



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
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