On Thu, Mar 25, 2010 at 5:02 PM, Marc Stern <marc.stern@approach.be> wrote:
Additional info about the config:

Apache version 2.2.4 (modified build)

Loaded modules:
  mod_rewrite.so
  mod_security2.so (+ additional filters)
  mod_ssl_error.so
  mod_define.so
  mod_macro.so
  mod_deflate.so
  mod_env.so
  mod_include.so
  mod_log_config.so
  mod_mime.so
  mod_proxy.so
  mod_proxy_http.so
  mod_setenvif.so
  mod_unique_id.so

Performance related directives:
  MaxRequestsPerChild  1000

  SecRequestBodyAccess On
  SecResponseBodyAccess On

Have you clear indication of  the performance impact of SecResponseBodyAccess ? have any rule ?

Thanks
Marc


-------- Original Message --------
Subject:        [mod-security-users] Performance benchmarking
Date:   Wed, 24 Mar 2010 12:32:29 +0100
From:   Marc Stern <marc.stern@approach.be>
Reply-To:       marc.stern@approach.be
Organization:   Approach
To:     mod-security-users@lists.sourceforge.net



As a lot of ModSecurity users (or potential users) are a bit stuck with
performance evaluation, I'll share a personal benchmarks we did. This
one does not encompass all possibilities and is not representative of
all environments, but it will give a rough idea to start with.

We set up a test server (low end) with a reference configuration and the
environment we use in production (very big ones, and very secure -
military level). We then used the new Google vulnerability testing tool
(skipfish) to test the configuration (actually we did it the other way
around: we tested the tool, and took the opportunity to benchmark the
config). This tool sends small requests, and small answers are also
returned; most production environments use bigger requests/answers.

Hardware:
CPU: 2 x Pentium 4 2.80GHz
RAM: 512 MB
OS: Centos 5.1 32 bits (kernel 2.6.18)
Client: workstation loaded with lots of tools on the same LAN as server

ModSecurity configuration
reverse proxy
lot of proxying processing (rewriting of URL, inside HTML, etc.)
1500 complex rules (usually a bit less complex than the core rules)

Results:
500 requests/s (HTTPS)
CPU peak: 85%
RAM peak: 230 MB
We were still able to use the reverse proxy to connect to other
applications, no delays noticed.

Although the results are very limited, I think we can conclude that a
small server can easily supports the peak load of most usual
applications - I do not speak here about mega applications with millions
of users.
Obviously, a lot of requests were blocked, thus all rules were not
triggered (different approach as the core rules).

By comparison, here is the result of a test on genuine pages with the ab
utility for 1000 requests (200 concurrent ones) in HTTPS:
CPU peak: 95%
RAM peak: 230 MB
Requests: 37/s (mean)
Time/request: 26.5 ms (mean)
We were still able to use the reverse proxy to connect to other
applications, but it responded slowly

Hope this will help.

Marc Stern
Security Expert - Head of Security Consulting Division
Approach Belgium - http://www.approach.be
Avenue Einstein, 2A - B-1348 Louvain-la-Neuve - Belgium

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
mod-security-users mailing list
mod-security-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html