https://redmine.openinfosecfoundation.org/https://redmine.openinfosecfoundation.org/favicon.ico?17011170022014-07-21T08:23:51ZOpen Information Security FoundationSuricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=44712014-07-21T08:23:51ZVictor Julienvictor@inliniac.net
<ul></ul><p>I suspect that one or more of these rules have |00| or |00 00| as a fast pattern. As each data byte of the stream is 00, it will trigger the more expensive 'match'-patch for each packet (and even more often in the AC matcher I think).</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=44722014-07-21T09:54:47ZAndreas Herzoisf@herzandreas.de
<ul></ul><p>Victor Julien wrote:</p>
<blockquote>
<p>I suspect that one or more of these rules have |00| or |00 00| as a fast pattern. As each data byte of the stream is 00, it will trigger the more expensive 'match'-patch for each packet (and even more often in the AC matcher I think).</p>
</blockquote>
<p>I parsed several of the rules (see pastes) that where called and didn't see thoe pattern.</p>
<p>In the meantime i could also confirm the test via ftp also has the 4:1 difference, but downloading the files via http didn't show such a 4:1 difference.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=44732014-07-22T03:33:25ZAndreas Herzoisf@herzandreas.de
<ul></ul><p>Andreas Herz wrote:</p>
<blockquote>
<p>Victor Julien wrote:</p>
<blockquote>
<p>I suspect that one or more of these rules have |00| or |00 00| as a fast pattern. As each data byte of the stream is 00, it will trigger the more expensive 'match'-patch for each packet (and even more often in the AC matcher I think).</p>
</blockquote>
<p>I parsed several of the rules (see pastes) that where called and didn't see thoe pattern.</p>
<p>In the meantime i could also confirm the test via ftp also has the 4:1 difference, but downloading the files via http didn't show such a 4:1 difference.</p>
</blockquote>
<p>I don't understand why it's so much better with HTTP:</p>
<pre>
while true; do { echo -e 'HTTP/1.1 200 OK\r\n'; cat testfile; } | nc -l -p 8000; done
</pre>
<p>and</p>
<pre>
wget http://10.0.20.89:8000/
</pre>
<p>Don't have the gap although in the sniffer it's always just zeros :/ (execept the initial connect). It's also unrelated to the port i use, since i tried also ports not in $HTTP_PORTS. Using $HTTP_PORTS for simple tcp connection still result in the decrease. So it looks like that it's decreasing with every tcp connection except HTTP.<br />In Profiling i also see, that the rules are still read and have kinda the same ticks.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=44742014-07-22T03:45:23ZAndreas Herzoisf@herzandreas.de
<ul></ul><p>Andreas Herz wrote:</p>
<blockquote>
<p>In Profiling i also see, that the rules are still read and have kinda the same ticks.</p>
</blockquote>
<p>I deactivated emerging-current_events.rules and emerging-scan.rules and now i see no rule ticks in the rule_perf.log but the decrease is still there, so i doubt that it's related to specific rules.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=44752014-07-22T05:08:52ZAndreas Herzoisf@herzandreas.de
<ul><li><strong>File</strong> <a href="/attachments/1040">packet_stats.log.http</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1040/packet_stats.log.http">packet_stats.log.http</a> added</li><li><strong>File</strong> <a href="/attachments/1039">packet_stats.log.nc</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1039/packet_stats.log.nc">packet_stats.log.nc</a> added</li></ul><p>Andreas Herz wrote:</p>
<blockquote>
<p>Andreas Herz wrote:</p>
<blockquote>
<p>In Profiling i also see, that the rules are still read and have kinda the same ticks.</p>
</blockquote>
<p>I deactivated emerging-current_events.rules and emerging-scan.rules and now i see no rule ticks in the rule_perf.log but the decrease is still there, so i doubt that it's related to specific rules.</p>
</blockquote>
<p>As asked, the packet_stats for "fast" HTTP and "slow" TCP with the same file.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=44882014-07-29T07:52:24ZAndreas Herzoisf@herzandreas.de
<ul></ul><p>I did the same test with real hardware now and this is what i got:</p>
<p>CPU: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz<br />RAM: 2GB<br />NETWORK: intel e1000e and igb cards</p>
<p>I get 7.5MB/s (60Mbit/s) with the /dev/zero traffic and 48MB/s (384Mbit/s) with the /dev/urandom traffic.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=44892014-07-29T09:19:41ZVictor Julienvictor@inliniac.net
<ul></ul><p>Can you try narrowing down the ruleset? It could be that there are just a few rules causing this.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=44902014-07-29T09:33:45ZAndreas Herzoisf@herzandreas.de
<ul></ul><p>Victor Julien wrote:</p>
<blockquote>
<p>Can you try narrowing down the ruleset? It could be that there are just a few rules causing this.</p>
</blockquote>
<p>I narrowed it down to "emerging-scan.rules" and "emerging-trojan.rules", with those 2 active it's still the huge gap. Although using only one of them doesn't result in the gap, so it's only the case with both active.<br />In the next step i would start with deleting some rule block within the files, unless you have a better idea :)</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=44932014-07-30T04:08:57ZAndreas Herzoisf@herzandreas.de
<ul><li><strong>File</strong> <a href="/attachments/1041">zero.rules</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1041/zero.rules">zero.rules</a> added</li></ul><p>Andreas Herz wrote:</p>
<blockquote>
<p>In the next step i would start with deleting some rule block within the files, unless you have a better idea :)</p>
</blockquote>
<p>See attached rule file with 200 rules with "00" in them.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=44942014-07-30T07:00:13ZAndreas Herzoisf@herzandreas.de
<ul><li><strong>File</strong> <a href="/attachments/1042">foobar.rules</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1042/foobar.rules">foobar.rules</a> added</li></ul><p>Andreas Herz wrote:</p>
<blockquote>
<p>Andreas Herz wrote:</p>
<blockquote>
<p>In the next step i would start with deleting some rule block within the files, unless you have a better idea :)</p>
</blockquote>
<p>See attached rule file with 200 rules with "00" in them.</p>
</blockquote>
<p>And after some annoying testing i can narrow it down to 4 rules:<br /><pre>
2017935
2010827
2014600
2018167
</pre><br />I attached the 4 rules in the foobar.rules, with only those 4 rules active the test above (with /dev/zero) you can see the huge difference.</p>
<p>But now i would like to know, why suricata has such problems to deal with those rules.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=44952014-07-30T07:05:31ZVictor Julienvictor@inliniac.net
<ul></ul><p>Engine analysis results</p>
<p>Rules:<br /><pre>
-------------------------------------------------------------------
Date: 30/7/2014 -- 14:02:27
-------------------------------------------------------------------
== Sid: 2014600 ==
drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Win32/Nitol.A Checkin"; flow:from_client,established; dsize:1028; content:"|01 00 00 00|"; depth:4; content:!"|00|"; distance:0; within:1; content:"|00|"; distance:1; within:1; content:"|00|"; distance:61; within:1; content:"Windows|20|"; distance:0; content:"|00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|"; distance:0; content:"|00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|"; distance:12; within:20; classtype:trojan-activity; sid:2014600; rev:5;)
Rule matches on packets.
Rule contains 7 content options, 0 http content options, 0 pcre options, and 0 pcre options with http modifiers.
Fast Pattern "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" on "payload" buffer.
No warnings for this rule.
== Sid: 2017935 ==
drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Backdoor family PCRat/Gh0st CnC traffic (OUTBOUND) 12 SET"; flow:to_server,established; dsize:8; content:"|00 00|"; offset:2; depth:2; content:"|00 00|"; distance:2; within:2; flowbits:set,ET.gh0stFmly; flowbits:noalert; reference:url,www.securelist.com/en/descriptions/10155706/Trojan-GameThief.Win32.Magania.eogz; reference:url,www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Backdoor%3AWin32%2FPcClient.ZR&ThreatID=-2147325231; reference:md5,3b1abb60bafbab204aeddf8acdf58ac9; classtype:trojan-activity; sid:2017935; rev:3;)
Rule matches on packets.
Rule contains 2 content options, 0 http content options, 0 pcre options, and 0 pcre options with http modifiers.
Fast Pattern "\x00\x00" on "payload" buffer.
No warnings for this rule.
== Sid: 2010827 ==
drop tcp $HOME_NET any -> $EXTERNAL_NET 8392 (msg:"ET TROJAN Torpig CnC Connect on port 8392"; flowbits:isset,ET.torpig.init; flow:established,to_server; content:"|00 00|"; depth:2; content:"|00 00 00|"; distance:2; within:5; flowbits:set,ET.torpig.fosure; reference:url,doc.emergingthreats.net/2010827; classtype:trojan-activity; sid:2010827; rev:3;)
Rule matches on packets.
Rule matches on reassembled stream.
Rule contains 2 content options, 0 http content options, 0 pcre options, and 0 pcre options with http modifiers.
Fast Pattern "\x00\x00\x00" on "payload and reassembled stream" buffer.
Warning: Rule has depth/offset with raw content keywords. Please note the offset/depth will be checked against both packet payloads and stream. If you meant to have the offset/depth checked against just the payload, you can update the signature as "alert tcp-pkt..."
== Sid: 2018167 ==
drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Generic CnC"; flow:established,to_server; content:" Mini BackDoor|00|"; offset:9; depth:20; reference:md5,398b6622a2c86d472a4340d3e79e654b; classtype:trojan-activity; sid:2018167; rev:1;)
Rule matches on packets.
Rule matches on reassembled stream.
Rule contains 1 content options, 0 http content options, 0 pcre options, and 0 pcre options with http modifiers.
Fast Pattern " Mini BackDoor\x00" on "payload and reassembled stream" buffer.
Warning: Rule has depth/offset with raw content keywords. Please note the offset/depth will be checked against both packet payloads and stream. If you meant to have the offset/depth checked against just the payload, you can update the signature as "alert tcp-pkt..."
</pre></p>
<p>Fast-pattern:<br /><pre>
-------------------------------------------------------------------
Date: 30/7/2014 -- 14:02:27
-------------------------------------------------------------------
== Sid: 2014600 ==
drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Win32/Nitol.A Checkin"; flow:from_client,established; dsize:1028; content:"|01 00 00 00|"; depth:4; content:!"|00|"; distance:0; within:1; content:"|00|"; distance:1; within:1; content:"|00|"; distance:61; within:1; content:"Windows|20|"; distance:0; content:"|00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|"; distance:0; content:"|00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|"; distance:12; within:20; classtype:trojan-activity; sid:2014600; rev:5;)
Fast Pattern analysis:
Fast pattern matcher: content
Flags: Distance
Fast pattern set: no
Fast pattern only set: no
Fast pattern chop set: no
Original content: \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
Final content: \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
== Sid: 2017935 ==
drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Backdoor family PCRat/Gh0st CnC traffic (OUTBOUND) 12 SET"; flow:to_server,established; dsize:8; content:"|00 00|"; offset:2; depth:2; content:"|00 00|"; distance:2; within:2; flowbits:set,ET.gh0stFmly; flowbits:noalert; reference:url,www.securelist.com/en/descriptions/10155706/Trojan-GameThief.Win32.Magania.eogz; reference:url,www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Backdoor%3AWin32%2FPcClient.ZR&ThreatID=-2147325231; reference:md5,3b1abb60bafbab204aeddf8acdf58ac9; classtype:trojan-activity; sid:2017935; rev:3;)
Fast Pattern analysis:
Fast pattern matcher: content
Flags: Offset Depth
Fast pattern set: no
Fast pattern only set: no
Fast pattern chop set: no
Original content: \x00\x00
Final content: \x00\x00
== Sid: 2010827 ==
drop tcp $HOME_NET any -> $EXTERNAL_NET 8392 (msg:"ET TROJAN Torpig CnC Connect on port 8392"; flowbits:isset,ET.torpig.init; flow:established,to_server; content:"|00 00|"; depth:2; content:"|00 00 00|"; distance:2; within:5; flowbits:set,ET.torpig.fosure; reference:url,doc.emergingthreats.net/2010827; classtype:trojan-activity; sid:2010827; rev:3;)
Fast Pattern analysis:
Fast pattern matcher: content
Flags: Within Distance
Fast pattern set: no
Fast pattern only set: no
Fast pattern chop set: no
Original content: \x00\x00\x00
Final content: \x00\x00\x00
== Sid: 2018167 ==
drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Generic CnC"; flow:established,to_server; content:" Mini BackDoor|00|"; offset:9; depth:20; reference:md5,398b6622a2c86d472a4340d3e79e654b; classtype:trojan-activity; sid:2018167; rev:1;)
Fast Pattern analysis:
Fast pattern matcher: content
Flags: Offset Depth
Fast pattern set: no
Fast pattern only set: no
Fast pattern chop set: no
Original content: Mini BackDoor\x00
Final content: Mini BackDoor\x00
</pre></p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=44962014-07-30T07:10:35ZVictor Julienvictor@inliniac.net
<ul></ul><p>I suspect one of the things that is so costly here is that we store each AC match with an offset. For the 2-byte pattern that would mean we store it payloadlen-1 times. This has to be costly. Also, this mechanism currently doesn't take the depth of the pattern into account. It's probably not easy to have the AC matcher take depth into account, but it I think it would be possible to not store these offsets beyond the depth/dsize.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=44972014-07-30T07:43:36ZAndreas Herzoisf@herzandreas.de
<ul></ul><p>Victor Julien wrote:</p>
<blockquote>
<p>I suspect one of the things that is so costly here is that we store each AC match with an offset. For the 2-byte pattern that would mean we store it payloadlen-1 times. This has to be costly. Also, this mechanism currently doesn't take the depth of the pattern into account. It's probably not easy to have the AC matcher take depth into account, but it I think it would be possible to not store these offsets beyond the depth/dsize.</p>
</blockquote>
<p>So your suggestion for now is to take a look at the code?<br />Or is there anything als i could do? Changing the rules for example.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=44992014-07-30T09:55:30ZKen Steeleken@tilera.com
<ul></ul><p>For this signature:</p>
Sid: 2014600 <br />drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Win32/Nitol.A Checkin"; flow:from_client,established; dsize:1028; content:"|01 00 00 00|";
<p>Adding "fast_pattern;" after content:"|01 00 00 00|"; would use that as the pattern, which is more unique than all zeros.</p>
<p>So:<br /> Sid: 2014600 <br />drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Win32/Nitol.A Checkin"; flow:from_client,established; dsize:1028; content:"|01 00 00 00|"; fast_pattern;</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=45002014-07-30T09:56:01ZKen Steeleken@tilera.com
<ul></ul><p>Have you tried rule profiling? That should point out which rules are taking the most time.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=45012014-07-30T09:57:06ZKen Steeleken@tilera.com
<ul></ul><p>This signature should not be firing with all zero data:</p>
Sid: 2018167 <br />drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Generic CnC"; flow:established,to_server; content:" Mini BackDoor|00|"; offset:9; depth:20; reference:md5,398b6622a2c86d472a4340d3e79e654b; classtype:trojan-activity; sid:2018167; rev:1;)<br /> Rule matches on packets.<br /> Rule matches on reassembled stream.<br /> Rule contains 1 content options, 0 http content options, 0 pcre options, and 0 pcre options with http modifiers.<br /> Fast Pattern " Mini BackDoor\x00" on "payload and reassembled stream" buffer. Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=45022014-07-30T10:02:02ZKen Steeleken@tilera.com
<ul></ul><p>For this signature:</p>
Sid: 2017935 <br />drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Backdoor family PCRat/Gh0st CnC traffic (OUTBOUND) 12 SET"; flow:to_server,established; dsize:8; content:"|00 00|"; offset:2; depth:2; content:"|00 00|"; distance:2; within:2; flowbits:set,ET.gh0stFmly; flowbits:noalert; reference:url,<a class="external" href="http://www.securelist.com/en/descriptions/10155706/Trojan-GameThief.Win32.Magania.eogz;">www.securelist.com/en/descriptions/10155706/Trojan-GameThief.Win32.Magania.eogz;</a> reference:url,<a class="external" href="http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Backdoor%3AWin32%2FPcClient.ZR&ThreatID=-2147325231;">www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Backdoor%3AWin32%2FPcClient.ZR&ThreatID=-2147325231;</a> reference:md5,3b1abb60bafbab204aeddf8acdf58ac9; classtype:trojan-activity; sid:2017935; rev:3;)<br /> Rule matches on packets.<br /> Rule contains 2 content options, 0 http content options, 0 pcre options, and 0 pcre options with http modifiers.<br /> Fast Pattern "\x00\x00" on "payload" buffer.<br /> No warnings for this rule.
<p>The content of "|00 00|" is not a good filter and on input data that is all zero, it will trigger on all but the first byte.</p>
<p>In this case, the dsize:8 would be a better filter to eliminate packets, as it should check the payload size is 8 bytes.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=45032014-07-31T02:50:30ZAndreas Herzoisf@herzandreas.de
<ul></ul><p>Ken Steele wrote:</p>
<blockquote>
<p>This signature should not be firing with all zero data:</p>
Sid: 2018167
</blockquote>
<p>I thought so, but if i have just this rule active there is still a drop from 120mb/s down to 90mb/s, so it's at least checked.</p>
<blockquote>
<p>Adding "fast_pattern;" after content:"|01 00 00 00|"; would use that as the pattern, which is more unique than all zeros.</p>
</blockquote>
<p>Perfect, that helped to make this rule much faster, with this addition the performance drop down to 20mb/s (with only this rule active) got back to 120mb/s. I guess i will send this to ET, unless you want since you found this.</p>
<blockquote>
<p>Have you tried rule profiling? That should point out which rules are taking the most time.</p>
</blockquote>
<p>I tried but that still brings me to those 4 rules. The rules are not good as we see but still shouldn't suricata try to handle such rules faster? I'm not sure what snort does different with them.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=45052014-08-05T11:14:00ZKen Steeleken@tilera.com
<ul></ul><p>Andreas Herz wrote:</p>
<blockquote>
<p>Ken Steele wrote:</p>
<blockquote>
<p>This signature should not be firing with all zero data:</p>
Sid: 2018167
</blockquote>
<p>I thought so, but if i have just this rule active there is still a drop from 120mb/s down to 90mb/s, so it's at least checked.</p>
<blockquote>
<p>Adding "fast_pattern;" after content:"|01 00 00 00|"; would use that as the pattern, which is more unique than all zeros.</p>
</blockquote>
<p>Perfect, that helped to make this rule much faster, with this addition the performance drop down to 20mb/s (with only this rule active) got back to 120mb/s. I guess i will send this to ET, unless you want since you found this.</p>
<blockquote>
<p>Have you tried rule profiling? That should point out which rules are taking the most time.</p>
</blockquote>
<p>I tried but that still brings me to those 4 rules. The rules are not good as we see but still shouldn't suricata try to handle such rules faster? I'm not sure what snort does different with them.</p>
</blockquote>
<p>Yes, please report it to ET. You are welcome to mention my name, since I know several of them.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=45062014-08-05T11:55:36ZWill Metcalfwilliam.metcalf@gmail.com
<ul></ul><p>We can add a set of Nulls preceding the windows match which should improve perf. Seems present in all samples.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=45072014-08-06T02:39:59ZAndreas Herzoisf@herzandreas.de
<ul></ul><p>Will Metcalf wrote:</p>
<blockquote>
<p>We can add a set of Nulls preceding the windows match which should improve perf. Seems present in all samples.</p>
</blockquote>
<p>Can you describe this a little bit more :)?</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=60362016-01-01T18:22:27ZAndreas Herzoisf@herzandreas.de
<ul><li><strong>Assignee</strong> set to <i>Andreas Herz</i></li><li><strong>Target version</strong> set to <i>TBD</i></li></ul> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=64272016-02-20T18:09:04ZAndreas Herzoisf@herzandreas.de
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Closed</i></li></ul><p>Diff is still there with 3.0 but much much closer, so IMHO just normal behaviour in this case. Closing for now.</p> Suricata - Optimization #1242: Huge performance decrease with /dev/zero traffichttps://redmine.openinfosecfoundation.org/issues/1242?journal_id=64372016-02-21T03:02:14ZVictor Julienvictor@inliniac.net
<ul><li><strong>Assignee</strong> deleted (<del><i>Andreas Herz</i></del>)</li><li><strong>Target version</strong> deleted (<del><i>TBD</i></del>)</li></ul>