François Laupretre wrote:
>>Here is a patch I am submitting to your comments. The purpose
>>of this patch is to bring a solution to the CGI performance
>>problem met on configuration with several thousands of hosts/services.
>>...
>
>
> Hello everybody,
>
> As I didn't have any reply, do I have to consider that it does not interest
> anybody ?
>
Yes and no. The comments were in french, much of the code wasn't
indented and mnemonic identifiers doesn't appear to be in the
programming style you use, so it took a while to grok all of it.
> Sorry to insist but I thought that it could be a solution (good or bad...)
> to a real issue. And, as more and more people switch to Nagios V 2, this
> problem will become more important.
>
A simpler solution to the same problem would be to implement real
hashing instead of the algorithm in current use. Presently it generates
worse hashes than an internet checksum function and the
compare_hashdata* functions (called from find_*) are extremely expensive.
> If you consider that nagios-db is THE ultimate solution, I don't agree, but
> let me know, and I won't disturb you any more.
>
nagios-db isn't the ultimate solution, although using a database is far
superior to flat-files (regardless of format).
I'm not so sure about this patch you've proposed though. By necessity it
involves a fair deal of pointer voodoo. Code such as that is always hell
to maintain, and it gets increasingly difficult to ensure support for
various compilers and architectures. F.e., gcc aligns components of
datastructures on sizeof(register) boundaries with certain optimization
options, and squeezes them with others, making pointer-hopping using
anything but relative offsets a debugging nightmare. Other compilers
have similar symptoms.
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Lead Developer
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]