host_name and service_description examples

[Andreas Ericsson]

Ethan Galstad wrote:
> Andreas -
> 
> If you can implement Paul's hash function as a drop-in replacement 
> for the current function in Nagios, that would be great.  I'll likely 
> move the hash bucket size out to an option, so it can be tweaked from 
> the main config file.
> 

I can, but some faster options for object lookups are available that 
would use less memory. Perhaps a two-staged implementation then? First I 
can simply replace the hashfunc1 and hashfunc2 with some others and then 
I can implement the hashing API properly later. It's highly re-usable 
code after all, and it would benefit greatly (code-clutter wise) from 
being compartmentalized with just a few public functions.

> I don't want to spend too much time trying to optimize the CGI speed, 
> as I am very much wanting them to disappear and be replaced by a new 
> interface soon.

Yes, but this change also improves performance quite a lot for the core 
as well. I'm more or less forced to implement it because I'm developing 
a loadbalance/redundancy module, and cutting 80% off the object lookup 
time is sort of necessary when handling passive check-results by the score.

>  A DB backend makes the most sense for this, and 
> projects like nagios-db are a good start.  I am also working on a new 
> event broker module which will dump darn near everything from the 
> Nagios daemon, as well as archived log files, into a normalized MySQL 
> database (and possibly PostgreSQL later).

Umm... This sounds fairly much like the nagios-db project. It dumps 
object config and status at module load-time. Adding a bit more to it 
can't really hurt. It also already has support for both mysql and 
postgresql.

As for logfiles, wouldn't it be better to dump the archived logfiles to 
database through an external app? It's a one-time operation, after all, 
or did I misunderstand something?

>  It should provide a good 
> working base for new PHP/Perl interfaces for Nagios.  The code is 
> still relatively new and under a good deal of development, but 
> something public should appear in the next month or two.
> 
> At any rate, the new has function will still provide some speedups in 
> the daemon after the CGIs are gone (although probably much less 
> noticeable to overall performance).  I also plan on tweaking things 
> in version 3, so that after startup, all object references are 
> "normalized" with direct pointers to the objects they reference.
> 

This is most definitely a very good thing. It would keep hash-tables 
small as well, as only objects which are read from external sources 
needs to be hashed after the initial setup.

Another bit of low-hanging fruit is implementing the various boolean 
variables as flags. The check for zero-ness is done by
or eax,eax
anyways, so
or eax,(any-power-of-2-value)
adds zero extra overhead but allows for L1 caching and fewer 
address-calculations which yields a possible improvement of 3 
instructions per check and has between 25 and 50% chance to free up one 
of the CPU pipes for parallell execution. I'm not sure this holds true 
for all compilers and architectures, but it does for i386 with gcc.

> 
> On 13 Jun 2005 at 11:37, Andreas Ericsson wrote:
> 
> 
>>I've made some corrections to the benchmark code, and a couple of
>>cheap optimizations. For those who want to test it for themselves (a
>>whopping 3 downloads so far ;), I suggest you leech the new version
>>from http://oss.op5.se/nagios/nagios-hash.tar.gz and give it a shake.
>>
>>Ethan; If it's allright with you, I'll go ahead and implement Paul
>>Hsie's hash. It looks up 1074600 hostname strings in 358msecs with the
>>current table-size of 1024 buckets (compared to 987msecs for the
>>additive hash currently in use). I'd also suggest wasting some memory
>>here. Upping the hash-table size to 16384 buckets (64Kb on 32-bit
>>archs) cuts another 40% off the average lookup time while staying
>>fairly friendly to the hardware.
>>
>>-- 
>>Andreas Ericsson                   andreas.ericsson at op5.se
>>OP5 AB                             www.op5.se
>>Lead Developer
> 
> 
> 
> Ethan Galstad,
> Nagios Developer
> ---
> Email: nagios at nagios.org
> Website: http://www.nagios.org
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
> a projector? How fast can you ride your desk chair down the office luge track?
> If you want to score the big prize, get to know the little guy.  
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
> 

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20