> On 18 Dec 2017, at 13:41, Christian Folini <christian.fol...@netnea.com> > wrote: > > Mark, > > Latency is an issue and the amount depends on the server. Factor 5 is a bit > steep, but still possible. > > My mileage is usually a 5-10% hit on the throughput of a reverse proxy. If > your server serves only static files and no backend connection, then your > numbers could be real. > > I would want to look at the individual requests, though. > Is 40 ms the mean? Is it some requests or all of them? If some, which ones? > > The tutorials at https://www.netnea.com come with an extended Apache Access > Log format that lets you gauge the performance impact a bit better. Once you > have the data, you can dig down and identify the individual requests / rules > that cause the delay. Raising the debug-log-level on individual requests let > you identify the individual rule of an individual request with a high > performance impact quite easily. And then tune them away. > > Also, CRS3 comes with a feature called Sampling Mode that allows you to run > the rules only on a percentage of the requests. This allows you to test / tune > with real world data without bringing the whole service down. This is > specifically aimed at services where the performance impact is unclear > and a potential risk. > > Performance issues are generally solvable with a compromise between > performance and security. And ModSec gives you a ton of performance > information so it is generally possible to nail down the problem. > > Hope this helps for a start. If you need more infos, then just ask.
Thanks, as an update, a second round of testing where logging was reduced and where we used a more proven httpd configuration resulted in more sensible results, typically 2 ms for a request without scanning and 4 ms for a request with scanning. We’re using version 2.9, but I wonder how much improvement you might expect for version 3.0 and is version 3.0 considered production ready yet? Finally, does mod_security use any kind of hashing to cache results? On the assumption that computing a digest of request is faster than running a large series of regexes over it. In other words, there’s no point repeatedly running the same rules over the same request line when it comes in each time. Alternately, can mod_security exploit Apache server-side caching to cache results? Regards, Mark _______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
