RE: [Nagios-devel] Hashing, take 2
Posted: Wed Jul 20, 2005 2:15 pm
> > Hi.
> >=20
> > Does this patch speed up the cgi's?
>=20
> Slightly, yes, but a different amount on different systems=20
> based on the conditions below. The greatest benefit will be=20
> for systems that accept a receive a large amount of passive=20
> checks though.
You mean it will speed up the processing of passive checks?
> On systems where strlen() isn't a compiler intrinsic it will=20
> provide a fairly large boost.
>=20
> If you used to have lots of collisions with the additive hash=20
> previously used you should see a fairly nice improvement=20
> (there's no way of knowing how many collisions you had per=20
> bucket without hashing all of your data with both algorithms=20
> and comparing it). Typically, networks with a proper=20
> naming-standard has many collisions with additive hashes.
>=20
> Systems where strcmp() isn't a compiler intrinsic, or where=20
> 8-bit operations are terribly expensive, will see a vast=20
> improvement, although this depends largely on the condition=20
> above as well as the number of elements monitored.
>=20
> Systems with a large call overhead will benefit greatly as=20
> the hash-functions and some of the hash-comparison functions=20
> are inline.
>=20
> Systems where the compiler does poor branch-prediction should=20
> see some fairly large improvements.
>=20
> Very small installations will notice a very slight=20
> performance degradation (actually, they won't notice it=20
> because pages will appear to load instantaneously anyways).
> > If so i'm willing to take it for a spin and report my findings.
> >=20
>=20
> Please do. The main issue at hand here is stability at first.=20
> If this patch works out well we can start chopping up the=20
> code to be better compartmentalized and each section of it=20
> can then be optimized to the extremes wrt both resources and=20
> speed without having to gamble with stability.
With summer comes spare time, yay
I've finally got around to testing this patch, and I think i've found a
bug.
The deamon starts fine, and nagios -v reports 32616 services and 3033
hosts.
But the cgi's do not show all my services.
>=20
> As for the GUI, it would need a complete re-design that would=20
> also affect the core for it to be noticably faster. Ethan's=20
> not willing to do that (I agree with him) since the effort=20
> would be wasted once the new GUI emerges.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
> >=20
> > Does this patch speed up the cgi's?
>=20
> Slightly, yes, but a different amount on different systems=20
> based on the conditions below. The greatest benefit will be=20
> for systems that accept a receive a large amount of passive=20
> checks though.
You mean it will speed up the processing of passive checks?
> On systems where strlen() isn't a compiler intrinsic it will=20
> provide a fairly large boost.
>=20
> If you used to have lots of collisions with the additive hash=20
> previously used you should see a fairly nice improvement=20
> (there's no way of knowing how many collisions you had per=20
> bucket without hashing all of your data with both algorithms=20
> and comparing it). Typically, networks with a proper=20
> naming-standard has many collisions with additive hashes.
>=20
> Systems where strcmp() isn't a compiler intrinsic, or where=20
> 8-bit operations are terribly expensive, will see a vast=20
> improvement, although this depends largely on the condition=20
> above as well as the number of elements monitored.
>=20
> Systems with a large call overhead will benefit greatly as=20
> the hash-functions and some of the hash-comparison functions=20
> are inline.
>=20
> Systems where the compiler does poor branch-prediction should=20
> see some fairly large improvements.
>=20
> Very small installations will notice a very slight=20
> performance degradation (actually, they won't notice it=20
> because pages will appear to load instantaneously anyways).
> > If so i'm willing to take it for a spin and report my findings.
> >=20
>=20
> Please do. The main issue at hand here is stability at first.=20
> If this patch works out well we can start chopping up the=20
> code to be better compartmentalized and each section of it=20
> can then be optimized to the extremes wrt both resources and=20
> speed without having to gamble with stability.
With summer comes spare time, yay
I've finally got around to testing this patch, and I think i've found a
bug.
The deamon starts fine, and nagios -v reports 32616 services and 3033
hosts.
But the cgi's do not show all my services.
>=20
> As for the GUI, it would need a complete re-design that would=20
> also affect the core for it to be noticably faster. Ethan's=20
> not willing to do that (I agree with him) since the effort=20
> would be wasted once the new GUI emerges.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]