Thread: Re: [mod-security-users] Performance benchmarking
Brought to you by:
victorhora,
zimmerletw
From: Marc S. <mar...@ap...> - 2010-03-25 16:02:12
|
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 Marc -------- Original Message -------- Subject: [mod-security-users] Performance benchmarking Date: Wed, 24 Mar 2010 12:32:29 +0100 From: Marc Stern <mar...@ap...> Reply-To: mar...@ap... Organization: Approach To: mod...@li... 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 |
From: yersinia <yer...@gm...> - 2010-03-25 17:22:35
|
On Thu, Mar 25, 2010 at 5:02 PM, Marc Stern <mar...@ap...> 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 <mar...@ap...> > Reply-To: mar...@ap... > Organization: Approach > To: mod...@li... > > > > 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® 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...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Appliances, Rule Sets and Support: > http://www.modsecurity.org/breach/index.html > |
From: Marc S. <mar...@ap...> - 2010-03-26 09:02:32
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <font face="Trebuchet MS">I never checked with "</font>SecResponseBodyAccess off".<br> <font face="Trebuchet MS">We have 50 rules</font> on the response body.<br> <div class="moz-signature"><span style="font-size: 80%; color: gray;"></span><span style="color: black;"><br> Regards,<br> <br> <b><i>Marc</i></b></span> </div> <br> On 25/3/2010 18:22, yersinia wrote: <blockquote cite="mid:b08...@ma..." type="cite"> <meta http-equiv="Context-Type" content="text/html; charset=ISO-8859-1"> <div>On Thu, Mar 25, 2010 at 5:02 PM, Marc Stern <span><<a moz-do-not-send="true" href="mailto:mar...@ap...">mar...@ap...</a>></span> wrote:<br> <blockquote>Additional info about the config:<br> <br> Apache version 2.2.4 (modified build)<br> <br> Loaded modules:<br> mod_rewrite.so<br> mod_security2.so (+ additional filters)<br> mod_ssl_error.so<br> mod_define.so<br> mod_macro.so<br> mod_deflate.so<br> mod_env.so<br> mod_include.so<br> mod_log_config.so<br> mod_mime.so<br> mod_proxy.so<br> mod_proxy_http.so<br> mod_setenvif.so<br> mod_unique_id.so<br> <br> Performance related directives:<br> MaxRequestsPerChild 1000<br> <br> SecRequestBodyAccess On<br> SecResponseBodyAccess On<br> <br> </blockquote> <blockquote type="cite">Have you clear indication of the performance impact of SecResponseBodyAccess ? have any rule ?<br> </blockquote> <blockquote> <div> <div><br> -------- Original Message --------<br> Subject: [mod-security-users] Performance benchmarking<br> Date: Wed, 24 Mar 2010 12:32:29 +0100<br> From: Marc Stern <<a moz-do-not-send="true" href="mailto:mar...@ap...">mar...@ap...</a>><br> Reply-To: <a moz-do-not-send="true" href="mailto:mar...@ap...">mar...@ap...</a><br> Organization: Approach<br> To: <a moz-do-not-send="true" href="mailto:mod...@li...">mod...@li...</a><br> <br> <br> <br> As a lot of ModSecurity users (or potential users) are a bit stuck with<br> performance evaluation, I'll share a personal benchmarks we did. This<br> one does not encompass all possibilities and is not representative of<br> all environments, but it will give a rough idea to start with.<br> <br> We set up a test server (low end) with a reference configuration and the<br> environment we use in production (very big ones, and very secure -<br> military level). We then used the new Google vulnerability testing tool<br> (skipfish) to test the configuration (actually we did it the other way<br> around: we tested the tool, and took the opportunity to benchmark the<br> config). This tool sends small requests, and small answers are also<br> returned; most production environments use bigger requests/answers.<br> <br> Hardware:<br> CPU: 2 x Pentium 4 2.80GHz<br> RAM: 512 MB<br> OS: Centos 5.1 32 bits (kernel 2.6.18)<br> Client: workstation loaded with lots of tools on the same LAN as server<br> <br> ModSecurity configuration<br> reverse proxy<br> lot of proxying processing (rewriting of URL, inside HTML, etc.)<br> 1500 complex rules (usually a bit less complex than the core rules)<br> <br> Results:<br> 500 requests/s (HTTPS)<br> CPU peak: 85%<br> RAM peak: 230 MB<br> We were still able to use the reverse proxy to connect to other<br> applications, no delays noticed.<br> <br> Although the results are very limited, I think we can conclude that a<br> small server can easily supports the peak load of most usual<br> applications - I do not speak here about mega applications with millions<br> of users.<br> Obviously, a lot of requests were blocked, thus all rules were not<br> triggered (different approach as the core rules).<br> <br> By comparison, here is the result of a test on genuine pages with the ab<br> utility for 1000 requests (200 concurrent ones) in HTTPS:<br> CPU peak: 95%<br> RAM peak: 230 MB<br> Requests: 37/s (mean)<br> Time/request: 26.5 ms (mean)<br> We were still able to use the reverse proxy to connect to other<br> applications, but it responded slowly<br> <br> Hope this will help.<br> <br> Marc Stern<br> Security Expert - Head of Security Consulting Division<br> Approach Belgium - <a moz-do-not-send="true" href="http://www.approach.be">http://www.approach.be</a><br> Avenue Einstein, 2A - B-1348 Louvain-la-Neuve - Belgium<br> <br> </div> </div> <br> ------------------------------------------------------------------------------<br> Download Intel&#174; Parallel Studio Eval<br> Try the new software tools for yourself. Speed compiling, find bugs<br> proactively, and fine-tune applications for parallel performance.<br> See why Intel Parallel Studio got high marks during beta.<br> <a moz-do-not-send="true" href="http://p.sf.net/sfu/intel-sw-dev">http://p.sf.net/sfu/intel-sw-dev</a><br> _______________________________________________<br> mod-security-users mailing list<br> <a moz-do-not-send="true" href="mailto:mod...@li...">mod...@li...</a><br> <a moz-do-not-send="true" href="https://lists.sourceforge.net/lists/listinfo/mod-security-users">https://lists.sourceforge.net/lists/listinfo/mod-security-users</a><br> Commercial ModSecurity Appliances, Rule Sets and Support:<br> <a moz-do-not-send="true" href="http://www.modsecurity.org/breach/index.html">http://www.modsecurity.org/breach/index.html</a><br> </blockquote> </div> <br> </blockquote> </body> </html> |