Re: [Nagios-devel] Hashing, take 2
Posted: Wed Jun 29, 2005 6:26 am
Andre Bergei wrote:
>>-----Original Message-----
>>From: [email protected]
>>[mailto:[email protected]] On Behalf
>>Of Andreas Ericsson
>>Sent: Wednesday, June 29, 2005 10:51 AM
>>To: nagios-devel
>>Subject: [Nagios-devel] Hashing, take 2
>>
>>I've decided to drop the massive hashing code changes I
>>submitted last time. This new patch is minimally intrusive
>>and seems to work nicely. I haven't tested this in production
>>very much, but it seems sound enough (cgi's run OK from
>>command-line, nagios -v has no problems).
>>
>>This is much less intrusive. Please test/use this patch instead.
>>
>>--
>>Andreas Ericsson [email protected]
>>OP5 AB www.op5.se
>>Lead Developer
>
>
> Hi.
>
> Does this patch speed up the cgi's?
Slightly, yes, but a different amount on different systems based on the
conditions below. The greatest benefit will be for systems that accept a
receive a large amount of passive checks though.
On systems where strlen() isn't a compiler intrinsic it will provide a
fairly large boost.
If you used to have lots of collisions with the additive hash previously
used you should see a fairly nice improvement (there's no way of knowing
how many collisions you had per bucket without hashing all of your data
with both algorithms and comparing it). Typically, networks with a
proper naming-standard has many collisions with additive hashes.
Systems where strcmp() isn't a compiler intrinsic, or where 8-bit
operations are terribly expensive, will see a vast improvement, although
this depends largely on the condition above as well as the number of
elements monitored.
Systems with a large call overhead will benefit greatly as the
hash-functions and some of the hash-comparison functions are inline.
Systems where the compiler does poor branch-prediction should see some
fairly large improvements.
Very small installations will notice a very slight performance
degradation (actually, they won't notice it because pages will appear to
load instantaneously anyways).
> If so i'm willing to take it for a spin and report my findings.
>
Please do. The main issue at hand here is stability at first. If this
patch works out well we can start chopping up the code to be better
compartmentalized and each section of it can then be optimized to the
extremes wrt both resources and speed without having to gamble with
stability.
As for the GUI, it would need a complete re-design that would also
affect the core for it to be noticably faster. Ethan's not willing to do
that (I agree with him) since the effort would be wasted once the new
GUI emerges.
> Best
> Andrè
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
> _______________________________________________
> Nagios-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/lis ... gios-devel
>
--
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]
>>-----Original Message-----
>>From: [email protected]
>>[mailto:[email protected]] On Behalf
>>Of Andreas Ericsson
>>Sent: Wednesday, June 29, 2005 10:51 AM
>>To: nagios-devel
>>Subject: [Nagios-devel] Hashing, take 2
>>
>>I've decided to drop the massive hashing code changes I
>>submitted last time. This new patch is minimally intrusive
>>and seems to work nicely. I haven't tested this in production
>>very much, but it seems sound enough (cgi's run OK from
>>command-line, nagios -v has no problems).
>>
>>This is much less intrusive. Please test/use this patch instead.
>>
>>--
>>Andreas Ericsson [email protected]
>>OP5 AB www.op5.se
>>Lead Developer
>
>
> Hi.
>
> Does this patch speed up the cgi's?
Slightly, yes, but a different amount on different systems based on the
conditions below. The greatest benefit will be for systems that accept a
receive a large amount of passive checks though.
On systems where strlen() isn't a compiler intrinsic it will provide a
fairly large boost.
If you used to have lots of collisions with the additive hash previously
used you should see a fairly nice improvement (there's no way of knowing
how many collisions you had per bucket without hashing all of your data
with both algorithms and comparing it). Typically, networks with a
proper naming-standard has many collisions with additive hashes.
Systems where strcmp() isn't a compiler intrinsic, or where 8-bit
operations are terribly expensive, will see a vast improvement, although
this depends largely on the condition above as well as the number of
elements monitored.
Systems with a large call overhead will benefit greatly as the
hash-functions and some of the hash-comparison functions are inline.
Systems where the compiler does poor branch-prediction should see some
fairly large improvements.
Very small installations will notice a very slight performance
degradation (actually, they won't notice it because pages will appear to
load instantaneously anyways).
> If so i'm willing to take it for a spin and report my findings.
>
Please do. The main issue at hand here is stability at first. If this
patch works out well we can start chopping up the code to be better
compartmentalized and each section of it can then be optimized to the
extremes wrt both resources and speed without having to gamble with
stability.
As for the GUI, it would need a complete re-design that would also
affect the core for it to be noticably faster. Ethan's not willing to do
that (I agree with him) since the effort would be wasted once the new
GUI emerges.
> Best
> Andrè
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
> _______________________________________________
> Nagios-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/lis ... gios-devel
>
--
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]