Hi
Thank you very much. I think whatever information you have given
is of great help.
Regards
Jenny
Dave Shield wrote:
On 21/08/06, Jenny Paul <[EMAIL PROTECTED]> wrote:
The information I need is purely
internal to my application. But I
can also have the other approach as Dave mentioned. (status file,
/proc-style interface, socket etc). Will it affect the performance of
my
application if I use any of these approaches.
*Any* form of management instrumentation will affect the performance
of your application.
Whether this be breaking off from what you're doing to answer silly
questions from your boss (sockets, AgentX), or wasting time writing
reports that you're convinced no-one will ever read (status file).
Life is so much easier when management just leaves you alone to get on
with things!
But we all know that this is a style of working that has all but
disappeared (even in academia!), and it's a necessary evil that you
have to be accountable to somebody. Good management will try to
ensure that this overhead is as small as possible, but it's non-zero.
The same holds here. Your application shouldn't have to spend a lot
of time providing management information, but it will be non-zero so
will inevitably take away from doing the real work. None of the
interfaces mentioned above should be particularly onerous -
particularly if your application already has some form of main
event-loop. That's the obvious place for any of the
interruption-based approaches - check whether a management request has
been received, process it if need be, then get back to work,
The status file approach is probably a higher "idle-time" overhead
(writing this file regularly,
whether it's needed or not), but this is a constant overhead - once
you've produced the file, then that's it. All the rest of the
processing is handled elsewhere. With the interruption approaches,
it's much faster to simply check whether a management request was
received (and most of the time, the answer will be no. Hopefully!).
But then you've got to respond to that request, which would typically
take a bit longer.
Also I didn't clearly understand
the problem David explained.
The issue here is what interface you should choose for reporting
management information out to an external application.
The advantage of AgentX is that it's a clearly defined, standard
interface - so it could be used by various different external
applications, with little or no extra coding needed. You (or your
customers) could manage your application via *any* AgentX-capable
system, not just Net-SNMP. Using any of the other approaches, you'd
have to write a new MIB module implementation for each of the SNMP
agents you wanted to support.
The disadvantage of AgentX is that it's designed for extending SNMP
agents, so isn't very well suited as a general-purpose management
interface. That's fine if you'll be mostly querying your application
via SNMP, less so if you might have other, non-SNMP-based management
requirements as well.
I think David is overstating the problems slightly - it *would*
still be possible to use AgentX as a general-purpose management
interface, even if the external application didn't actually use SNMP.
But there's no question that this would be less convenient than (say)
a text-based /proc-style interface or status file.
There's No One Right Way To Do This.
Anyone who says different is selling something :-)
Dave
--
Thanks
& Regards,
Jenny Paul
------------------------------------
Teles Computer Systems India Pvt Ltd
Indiranagar
Bangalore - 560008
--
This message has been scanned for viruses and
dangerous content and is believed to be clean.
|
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
