Support has a list of parsers which have performance issue, how they know? Experience?
We're going to develop some custom parsers for customer and customer wants to know the performance impact, any idea how can we check?
Best you can do is check the stats for a decoder via NwAdmin or use a monitoring tool such as Nagios, Zabbix, etc. to pull the stats via SNMP. I personally recommend the latter technique because it's easy to get rolling graphs of stats.
You definitely want to keep a close eye on dropped packets from capture as that's your real enemy. But you'd probably want to look at CPU and memory usage as well, to make sure they aren't running away.
Unfortunately, there's no real way to measure performance of an individual parser.
Generally, yes experience. There were a few flex parsers which could perform poorly. SMB-flex was notorious, due to the fact that it exercised everything flex was bad at. Lua parsers generally haven't shown any performance issues - with a couple exceptions that have already been addressed by updates. SMB_lua is significantly faster than SMB-flex was, no one should be afraid of it.
But some parsers sometimes just have to do a lot of work. So they aren't problematic so much as requiring a trade off between performance and visibility.
There isn't a way to know, "this parser is occupying these resources". Best practice is to make the parser do as little work as possible - which admittedly is more art than science.
Quick tips (all of these are covered in more depth in "The Book"):
As for what to watch for, just as Jeff said,
Also be sure to watch your logs. I'd also suggest if possible to have an independent non-production decoder dedicated to content development and testing. Import pcaps instead of capturing live traffic so that you have a known, consistent, repeatable set of test data. Import, make changes, import again - repeat until ready to deploy the content for production use.
Yes, having a dedicated test decoder/concentrator is invaluable, although expensive and may be hard to justify for some. I'd definitely love to see RSA offer some sort of virtual solution for this sort of scenario, where testing of customizations and configurations could be done safely without having to buy very expensive equipment.
Oh and one last thing about benchmarking parsers, definitely read William Motley's parser book! If you're not following that as your parser bible you're bound to stab yourself in the foot someday. :}
We are fighting this exact battle right now, which parser is sucking the most.
The book, Parsers Book.zip
Brilliant. We somehow missed that back in December.
+1 on a VM decoder/concentrator for testing. You know, that hybrid packet VM license...only I don't have to pay for it b/c it's test.
Retrieving data ...