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 ------------------------------------------------------------------------- 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
