|
From: Robert P. <rpa...@fe...> - 2018-04-05 19:25:54
|
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/
lua-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 :)
|
