Re: [Nagios-devel] host_name and service_description examples
Posted: Mon Jun 13, 2005 8:49 pm
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 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. 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). 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.
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 [email protected]
> OP5 AB www.op5.se
> Lead Developer
Ethan Galstad,
Nagios Developer
---
Email: [email protected]
Website: http://www.nagios.org
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
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 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. 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). 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.
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 [email protected]
> OP5 AB www.op5.se
> Lead Developer
Ethan Galstad,
Nagios Developer
---
Email: [email protected]
Website: http://www.nagios.org
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]