This is a very good question indeed. I’ll start out bysaying ASP stands for Advanced Syslog Parser. The ASP parsers are rule-basedwhereas anything none-ASP is code based. The advantages for using ASP overnon-ASP would be performance and the usability.
For example: You set your data source up to use the non-ASPversion and you noticed that some of your logs don’t trigger events or maybesome of the events are mapping incorrectly. Since this is a code-based parseryou would be stuck with what is there until a new release is shipped with theenhancements for the parser.
With the ASP version this isn’t the case at all. Let’sassume your events aren’t mapping or maybe the mappings are incorrect. With theASP version you can log a Product Enhancement Request (https://mcafee.acceptondemand.com/index.jsp)and our rules team could, depeding on the request, correct the issue andrelease new or updated rules. The customer would then just need to get a rulesupdate and they would have the corrected rules in place. This is much fasterthan waiting for an actual code change to be released.
TheASP engine is also far faster when processing rules than the code basedparsers. So, If you ever have a choice between the none-ASP and ASP version,always choose the ASP version.
Time to revive an old thread...
Can you confirm that this is really the case?
I believe code-based parsers would be faster than ASP, being code based... The disadvantage would be that we can't customize our rules.
Can you please confirm that ASP is actually faster than code based? I always prefer ASP but I sometimes chose code-based parsers thinking they were binaries, and thus faster.
Ok, but for a syslog data source, which one would be faster? Say you have 20 rules ASP, 20 rules code based, for the same logs? There should be a clear winner, but the post by Anthony infers that this would be the ASP parser, in terms of performance.
I do not know of a way to test parser performance directly...