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/...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