|
From: Chaim S. <ch...@ch...> - 2018-04-06 18:06:44
|
Guys please remember to be civil. Although I know your intention is to get better performance numbers and improvement, remember that there are a lot of factors going into development of v3. Try to look at the feedback you're giving from Felipe's perspective, it does appear to be slightly aggressive in nature. Just remember that our goal as a whole community is to produce awesome work. On Fri, Apr 6, 2018, 12:51 PM Robert Paprocki < rpa...@fe...> wrote: > Hi, > > On Fri, Apr 6, 2018 at 7:05 AM, Felipe Zimmerle <fe...@zi...> > wrote: > >> >> Hi, >> [ ... ] >> >> I would suggest you to work an real use case. Using a real environment. >> As you said, testing in the loop back is not good thing. >> > > Felipe, with all respect I think you should go into politics :D This is a > disingenuous non-answer. Are you saying that you'd expect to see _better_ > performance in a more complex environment? That's clearly not the goal > here. We're not trying to simulate a realistic production workload. We're > profiling the performance specifically of libmodsecurity. Removing > variables induced by network connections, additional applications, etc., > provides _more_ reliable results when examining libmodsecurity's > performance and behavior. And Andrei's own work and results align very > closely with ours. Are you saying his data is unreliable as well? What > variables do you suggest we adjust to better highlight libmodsecurity's > performance? From what I can tell, lightweight benchmarks have clearly > shown a behavior change based on the libmodsecurity configuration, and > flame graphs have highlighted hot code paths that need > optimization/refactoring. I'm not sure what more you'd like to see. > > I have taken the liberty of opening a few tracking issues on GitHub, since > discussion here is going nowhere: > > https://github.com/SpiderLabs/ModSecurity/issues/1731 > https://github.com/SpiderLabs/ModSecurity/issues/1732 > > > I want to highlight that I don't think Christian or I are trying to > sandbag anyone. But this discussion has been rather frustrating; from our > perspective, we've provided real numbers and done benchmarking/profiling > with modern tooling, and that data has aligned with what Andrei (who works > for Nginx) has shown as well. And apart from vague answers like > "performance is a very import subject which will always be discussed", > there's been no response even acknowledging that our results are > meaningful, or that our expectations about performance and latency are > valid. I understand that Trustwave has it's own priorities (Felipe blink > twice if they won't let you make performance improvements ;) ), but this > really feels like a show-stopper for deploying at any meaningful scale. At > this point I really don't know how to proceed. If I'm completely off-base > then please let me know. > > ------------------------------------------------------------------------------ > 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/ > |
