Sorry for replying to my own topic, but I've figured out what's causing
it to go so slow.
It's the rules in sa-blacklist.current.uri.cf from
http://www.sa-blacklist.stearns.org/sa-blacklist/sa-blacklist.current.uri.cf.
This ruleset works fine in 3.1, I'm not sure why it doesn't in 3.2, any
insight?
Thanks,
Sean
Sean Kennedy wrote:
I recently upgraded from v3.1.9 to v3.2.4 and I've noticed a substantial
increase in scan times. The general average scantime with v3.1 was
about 1.2s and now with v3.2 it's about 2.2s. It's enough of a slow
down so that my mail queue backs quite easily now.
So I'm trying to debug SA and figure out whats going on by doing -D
--lint and I've got a couple questions about some of the output.
1) Why am I getting lines like the following and how do I correct it?
[14896] dbg: rules: SARE_HTML_ALT_WAIT1 merged duplicates:
SARE_HTML_ALT_WAIT2 SARE_HTML_A_NULL SARE_HTML_BADOPEN
SARE_HTML_BAD_FG_CLR SARE_HTML_COLOR_NWHT3 SARE_HTML_FONT_INVIS2
SARE_HTML_FSIZE_1ALL SARE_HTML_GIF_DIM SARE_HTML_H2_CLK
SARE_HTML_HTML_AFTER SARE_HTML_INV_TAGA SARE_HTML_JSCRIPT_ENC
SARE_HTML_JVS_HREF SARE_HTML_MANY_BR10 SARE_HTML_NO_BODY
SARE_HTML_NO_HTML1 SARE_HTML_P_JUSTIFY SARE_HTML_URI_2SLASH
SARE_HTML_URI_AXEL SARE_HTML_URI_BADQRY SARE_HTML_URI_BUG
SARE_HTML_URI_FORMPHP SARE_HTML_URI_HREF SARE_HTML_URI_MANYP2
SARE_HTML_URI_MANYP3 SARE_HTML_URI_NUMPHP3 SARE_HTML_URI_OBFU4
SARE_HTML_URI_OBFU4a SARE_HTML_URI_OPTPHP SARE_HTML_URI_REFID
SARE_HTML_URI_RID SARE_HTML_URI_RM SARE_HTML_USL_MULT
2) It hangs for like 30 seconds on the following line, what exactly is
it doing and is it necessary?
[14924] dbg: rules: running uri tests; score so far=1.5
It takes about 5s to run -D --lint on my boxes running v3.1, but about
50s to 1m10s using v3.2 (same hardware on all boxes).
Any info is greatly appreciated!
Sean
