|
From: Jai H. <jai...@mu...> - 2018-04-05 20:07:02
|
"Yes of course. Again, what I'm highlighting here is the very substantial
difference between Nginx with and without ModSecurity. A two-order of
magnitude drop is simply unacceptable for operators that need to handle
requests at any significant scale. If there was a 10-20% drop in
performance, that would be completely understandable. But the current
benchmarks highlight a much larger gap. This is the key point I'm trying to
drive home. I apologize if I'm failing to make this clear."
Using the data from the results I previously attached, I see a slowdown
factor of 35-140 times, depending on the size of the request body. For
example, with ModSecurity disabled, I am able to process a single Json
request with 32M body in ~11 ms. With ModSecurity v3.0.1 enabled, it takes
~1476 ms to process this same request. That's 140 times as long with
ModSecurity enabled vs disabled.
On Thu, Apr 5, 2018 at 2:25 PM, Robert Paprocki <
rpa...@fe...> wrote:
> Hi,
>
> On Thu, Apr 5, 2018 at 11:28 AM, Felipe Zimmerle <fe...@zi...>
> wrote:
>
>> Hi,
>>
>> Not sure if i understood but, that sounds about right to me. That is also
>> valid for any script language.
>>
>> [a] for (i = 0; i < 10; i++) { echo "a"; }
>> [b] for (i = 0; i < 100; i++) { echo "b"; }
>> [c] for (i = 0; i < 10; i++) { for (j = 0; j < 10; j++) { echo "b"; } }
>>
>> In that case, [a] will be faster than [b]. [b] is likely to run on the
>> same time of [c].
>>
>> The response time is directly proportional to the task that needs to be
>> computed. That is pretty much it from anything that runs on computer.
>>
>
>
> Yes. I'm not saying this is unexpected behavior. I'm simply highlighting
> the nature of my (very quick and imperfect) tests. I'm also highlighting
> the fact that the contents of the rule itself (like a very complex regex
> with many transformations) is not necessarily a major burden; it's simply
> the introduction of more rules that has a considerable impact on
> performance. And libmodsecurity's performance is so limited in these cases
> that it's worth this discussion. Of course, more complex rules will induce
> more performance delay. But the base processing of rules, regardless of
> their design, is a major bottleneck in libmodsecurity. Quite frankly I
> would expect a very simple rule like
>
> SecRules ARGS:test "@streq foo" "id:12345,phase:1,deny,t:none"
>
> To not perform so very poorly. And it doesn't. When you run many dozens or
> hundreds of these rules though, that's when things slow to a crawl. And
> that is a result of the design of the core libmodsecurity code, not the
> rule itself.
>
>
>
>> I think you meant that nginx by its own can delivery more content than
>> nginx with ModSecurity. Which can be considered true regardless how good or
>> bad the performance of ModSecurity is. Considers ModSec load "B" and nginx
>> load "A".
>>
>> A < A + B.
>>
>> Please correct me if I understood it wrong.
>>
>
>
> Yes of course. Again, what I'm highlighting here is the very substantial
> difference between Nginx with and without ModSecurity. A two-order of
> magnitude drop is simply unacceptable for operators that need to handle
> requests at any significant scale. If there was a 10-20% drop in
> performance, that would be completely understandable. But the current
> benchmarks highlight a much larger gap. This is the key point I'm trying to
> drive home. I apologize if I'm failing to make this clear.
>
>
>
>> [...]
>>>
>>
>
>
>> As a matter of fact, there are a lot of room for improvements. Myself,
>> and [i think] everybody which uses ModSecurity will be very happy and
>> welcome to receive your contribution. As we already receive a lot of
>> contributions from Andrei. You just have to send the patches. As I
>> mentioned before, I am anxious for that. I think everybody that you
>> mentioned wants to see those improvements as well.
>>
>> When do you think you can share something with us?
>>
>> Is that anything that I can do to help you?
>>
>
>
> Unfortunately I'm not in a position to make significant contributions at
> this time. I can chat, build some simple tests, write small patches here
> and there. I have a full time job that does not allow me to do meaningful
> development for functionality like this. And I have two small children and
> home responsibilities that preclude me from investing significant personal
> time (though I would love to be able to do that). I love that
> libmodsecurity continues to remain an open source project. I truly wish I
> had more personal time to invest in it.
>
> TBH it would be great if you could review the flamegraphs I've left in
> this thread, and let me know if those are of any use. I would also be very
> interested in hearing from other ModSecurity operators their experiences
> with libmodsecurity's performance. Perhaps I've just made a giant error and
> the simple test harness results I see are not an accurate reflection of
> reality.
>
> And if I need to adjust my expectations, then we should settle on that. My
> expectation is coming from an environment where running Nginx (OpenResty)
> on moderate hardware and leveraging the logic made available by the CRS
> allowed for ~15000 req/s (https://github.com/p0pr0ck5/l
> ua-resty-waf#performance; this was an older test but should still old
> up). I assumed that, without a Lua/OpenResty abstraction layer, we would
> see even better performance with a native Nginx module + integration.
> Running the same ruleset with libmodsecurity 3.0.2, I see roughly 1/10th
> the performance. If this is what we should expect from libmodsecurity, then
> I will not make any more noise here :)
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>
>
|
