Hey Stewart,
The caching is so far just an idea - as yet I only thought about
updating it periodically, and only for the 3 tables in the SNMP tree
(processlist, ndb node status, and database/table status). The show
variables/globals are fairly straightforward, but during a debug cycle I
discovered that netsnmp iterates through the entire processlist/node
status/table status for every single line/column. That adds up pretty
nicely. Caching the result would be nice, there. Perhaps add an age
counter so that the cache is not updated if the request is repeated
within a second or so (which is very likely to happen during a
snmpwalk). That alone should give a significant performance gain, as
well as lessen the number of requests to the database.
A second alternative as mentioned before is a few threads which
periodically (or given a certain event) update the 'cached' values.
Might even have them get the average row size (a problem I mentioned
earlier).
Cheers,
Michel
Stewart Smith wrote:
> On Wed, 2006-08-16 at 07:21 +0200, Michel Stam wrote:
>
>> I'm still thinking of ways to improve the code (which is basically also
>> limited by the time I can spend on it).
>> Something thats been on my mind is improving speed by having one or two
>> threads retrieve the data for the tables into memory periodically, so
>> SNMP queries can be served instantly. This should also significantly
>> reduce the number of times MySQL is bothered by the agent.
>> I'll have to look into the threading as MySQL provides it, I saw MySQL
>> has a few wrapper functions for it.
>>
>
> for the ndb status information you could keep a cached copy and only
> update when you get an event (using the mgm events mechanism for node
> start/stop events).
>
> ndb_mgm doesn't currently do it this way.
>
> a recent change i made is that when you call ndb_mgm_get_status (IIRC
> that's what it's called) it forces a heartbeat between the DB nodes so
> that the status is always up to date (unless the heartbeat takes too
> long, then it could be out of date... but you're probably going to have
> nodes being kicked out of the cluster by then).
>
