Re: [OPSAWG] discuss on draft-ietf-opsawg-syslog-msg-mib-06.txt

["David Harrington" <[e-mail]>]

Hi, 

> 2.
> > The SNMP approach has a major guideline:
> > keep the agent simple; move complexity to the manager.
> Yes. And this is what swings it for me.
> I am just left wondering whether an Agent is more loaded by a 
> bulk read of 
> 10,000 entries or maintaining a pointer into the table.
> 
> Clear up this last point, and I'm done.
> 
> Cheers,
> Adrian

Well, I think you have two cases - the initial read and update reads.
I might be surprised to see 10,000 in an initial read, but I
presumably want to get them all on the initial read, so if there are
10,000, then that's what I'll get, whether there is a scalar or not.
Knowing the oldest entry doesn't really help me on the initial read.

Now we'll deal with update reads. I would be surprised to see 10,000
entries in an update. But presuming they're there and I want them all,
I can bulk read them at 100 each time and check for whether I have
duplicates of entries I retrieved earlier (or whether the timestamp
changes significantly or whatever optimization I meet choose to use).
I can stop requesting more once I detect a duplicate. If the table is
actually that large that there are 10,000 update entries in the table,
a bulk read of 100 does not seem like much of a problem, and it would
be nicer to the CPU of the agent device. Worst case, I read 100
duplicate entries, but compared to an update of 10,000 entries I think
this is insignificant. How complex you want to make the algorithm can
be decided by the manager.

I am not certain how a scalar to the oldest helps that much. A pointer
to the latest entry would seem more useful to recognize where to stop.
Of course, the pointer to the oldest is probably 1 greater than the
pointer to the newest. I just don't think it makes that much
difference if you are talking 10,000 entries in an update. 

As I said I don't object to having a scalar. But I don't think it's
going to matter much in your scenario. If you're really concerned
about the load on the agent, remember that if there are 10000 update
entries, the scalar needs to be updated 10,000 times. And for the
manager to know the value of the scalar, it will have to do reads of
the scalar as well as of the table entries.

If you really want to reduce the load from bulk reads, then you might
want to provide filtering INDEXES on common fields, such as facility
(only get the ones for the email server), and severity (only retrieve
the critical errors). I think this might be more useful at reducing
retrieval load than the proposed scalar because these are commonly
used filters.

dbh