Hi,
You are right. I also test with my real production configuration (7000
services) and the load averege of the server was 5 time less that my
Nagios server. I also try to bench with a "echo; sleep 0.5; exit" and
it was still very high. I will try the "random 1 ->10".
In realm world the perf will be slower than my ideal test environment,
but at least, the performances will be limited by the checks we
launch, not by the scheduler.
Gab=E8s Jean
On Tue, Dec 1, 2009 at 9:43 PM, Martin Melin wrote:
> I don't want to sound negative, but the performance of your clone with
> "echo; exit;" checks isn't really interesting. In a real-world Nagios
> installation, checks take a *long* time to execute because they are
> dependent on so many factors external to the local machine.
>
> To get more realistic numbers, I would suggest using a plugin that does a
> random-length sleep, between 0 and 10 seconds long.
>
> The reason why your numbers are not realistic is because you're testing f=
or
> the wrong thing: in your test environment, the system spends most of its
> time spawning and handling processes, reporting back data etc. Of course
> you'll get better performance by drastically reducing the total populatio=
n
> of processes on the machine. But in a real-world Nagios environment, ther=
e
> will be a lot of time spent waiting on the network & remote machines - th=
is
> time is simply not present in your test case.
>
> This is not to say that I don't believe that your solution may be an
> improvement or have better performance - it is saying that nobody knows,
> because your test parameters are not anything like the real world.
>
> All the best and looking forward to seeing your code,
>
> Martin Melin
>
> On Tue, Dec 1, 2009 at 8:07 PM, William Leibzon wro=
te:
>>
>> Go and program it but don't hope that this will ever become nagios4 -
>> nagios name is trademark and its entirely up to Ethan what it gets used =
for.
>> But that does not mean its bad to have different compatible (as far as
>> config and database and frontened).
>>
>> Nagios has very long history so chances of rewrite in different language
>> are very low although I kind-of hope people would open up to at least C+=
+.
>> But as far as language for something alike nagios, but new, python is no=
t
>> bad but its rather inflexible in how it forces you to write (both good a=
nd
>> bad, don't start pointless discussion here) and does not give you quite =
as
>> much flexibility for memory and few other ops. Also looking at your
>> architecture I immediately see that best language for it is probably Erl=
ang,
>> but then finding people to support and develop it further would be a lot
>> more difficult. So if you want to do it in python go for it, just don't =
hope
>> that id would become nagios4 but do report back on your progress time-ti=
me
>> if you like (this would call for plugins written in python too, and
>> preferred language is actually perl). Personally if I'm to consider
>> rewriting nagios in interpreted language I'd wait for Perl6 to come out,
>> it'd be taken a lot better by nagios users.
>>
>> On Tue, Dec 1, 2009 at 9:09 AM, nap wrote:
>>>
>>> Hi list,
>>>
>>> I would like to have your feed back about a (unfinished)
>>> reimplementation of Nagios named "Shinken" I wrote in Python that is
>>> faster and more modular than the current Nagios implementation in C
>>> (yes faster, you read correctly. I was the first surprised by that).
>>>
>>> =3D=3D The Shinken's history =3D=3D
>>> Few months, I start to work on a proof of concept for Nagios focus on
>>> distributed environments and performances. The main goal was to look
>>> for a distributed and high availability architecture. I was also
>>> thinking that Nagios' performances were quite good, but we can have
>>> more.
>>>
>>> For quick test and development, I used Python. I thought a process
>>> pool can make Nagios be quicker instead of forking a new process to
>>> kill it few seconds after for each checks. I also bypass the reaping
>>> way of N
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]