Re: [Nagios-devel] Hashing, take 2
Nagios network monitoring software is enterprise server monitoring
Brought to you by:
egalstad,
sawolf-nagios
From: Andreas E. <ae...@op...> - 2005-06-29 14:26:18
|
Andre Bergei wrote: >>-----Original Message----- >>From: nag...@li... >>[mailto:nag...@li...] 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 and...@op... >>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 > Nag...@li... > https://lists.sourceforge.net/lists/listinfo/nagios-devel > -- Andreas Ericsson and...@op... OP5 AB www.op5.se Lead Developer |