Day goes well until I get back to the question of performance (Though a bug showed up when it went live...)
Last update on .
Spent the bulk of the day on the counter-history download XMLRPC code. That's now working, but the silly modem-current-value code is failing due to an XMLRPC linearisation problem when run on the live system. Grr. Aside:
Really need to have a decent "trusted" Python-to-Python RPC mechanism that's Twisted and non-Twisted friendly which can just pass the data as Python objects. Trusted in the sense of "you control both ends of the pipe and can trust the data coming across the pipe". Even with PerspectiveBroker, there's far too much fiddling about required to make it properly linearise non-standard objects.After that turned to the query server code. Particularly I started in on hooking up the code to actually work in the system... and then realised that to do any testing I have to do major surgery on the testing framework to let it mock up the "spread" servers. So I decided to do a spike test, namely seeing whether it would be reaonable to add support to TwistedSNMP for using NetSNMP command-line tools in managed processes to do the queries. It was worth a shot, but while PySNMP is slow, it does seem faster than starting up the NetSNMP process, scanning all the MIBs, processing the command line arguments, then parsing them back out (I never even got to that part of it, the queries were already too slow to bother proceeding). May take a look at adding support for other SNMP libraries on Thursday. Tomorrow looks like a write-off as far as getting serious work done. We have a management meeting at some ungodly hour in the morning, then the VexMeet in the evening.
Comments are closed.
Pingbacks are closed.
John Speno on 03/02/2005 7:32 a.m. #
I've got a application that calls out to an external snmp bulkwalk program that I wrote in perl around the NetSNMP.pm stuff that comes with net-snmp.<br />
I had to do that because most of the devices I need to query are speaking SNMPv3. I use PySNMP for everything else though.<br />
I found that the stock snmpbulkwalk from net-snmp doesn't allow you to issue queries with more than one varbind in it, which made for a really inefficient table walk. The perl version gets it right anyway.<br />
I'm really looking forward to having all my SNMP python code done in Python again. *sigh*