Nagios-devel digest, Vol 1 #807 - 8 msgs

[sean finney]

hey,

On Wed, May 11, 2005 at 10:10:01AM +0200, Andreas Ericsson wrote:
> which hogs as much free cpu as possible. i and x are registers to make 
> contextswitches really expensive. With this one running, I got the 
> following results;
> 
> ---%<---%<---%<---
> dltest/popen with 1000 kids:
> real    0m12.895s
> user    0m0.000s
> sys     0m0.010s
> 
> dltest/dlopen with 1000 kids:
> real    0m31.265s
> user    0m0.000s
> sys     0m0.090s
> 
> ---%<--%<--%<---

i definitely did not see those numbers.  what kind of machine is this on?
when running on my ultra5 (yeah, i know...):

dltest/popen with 100 kids:

real    0m14.674s
user    0m3.190s
sys     0m0.610s

dltest/dlopen with 100 kids:

real    0m11.213s
user    0m0.030s
sys     0m0.200s

which looks a little better, doesn't it?  i'd show the numbers from
the 1000 test, but fork keeps dying with EAGAIN after a couple hundred
calls :/

> This is consistent over several runs, with only minor changes to the 
> timings. As you can see, the gain of not forking is gone at 100 
> instances and for 1000 kids the dlopen approach offers clearly abysmal 
> performance while the popen approach stays roughly the same.

i'm really curious as to why this is.  i'm imagining this is because
waiting on a select behaves better with the scheduler?

> You would do better to abandon this and instead focus on enhancing 
> multithreading/multiplexing support or fixing the plugins. There's lots 
> of work to do there to improve nagios' performance.

well, in any case i'm convinced at this point that the gains are marginal
at best.  i'd still be interested in discussing the multi-threaded
approach further though, as that does sound much more promising.


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20050511/5ee080cb/attachment.sig>