Slow Throughput after installing v18 EAP

Question

Hi, 
 I upgraded from v17.5.8 to v18 EAP about a week ago and noticed a drop in performance and an increased RAM usage. 
 I do have a XG115 rev2 Appliance installed with the Software Image and a Home Use License. 
 My Internet connection is 100/40. 
 With version 17.5.8 I was able to reach about 80 to 90 Mbit download (I already expected more from the hardware) 
 After the Upgrade I only reach about 50 to 60 Mbit download. There is no DPI or webfiltering activated and it doesn't matter if i activate IPS or not. 
 SSL/TLS Inspection is turned on but there are not any rules. 
 Are there any tweaking options for the software version of Sophos XG running on a HW Appliance? 
 Thank you!

Michael Dunn · Accepted Answer

Billybob said: 
 I would strongly disagree with your assessment. Throughput numbers should be the top priority for sophos. 
 
 Throughput numbers are a top priority. 
 My point is that we have internal testbeds with 1GB and 10GB pipes hooked to a performance harness pushing through traffic on a dozen different hardware boxes of different sizes and producing our own detailed analysis with a per process breakdown that our team is acting on. 
 Getting a report from the forum saying that on their own custom hardware a CPU graph looks bad isn't something that is a useful input to our performance team. It can be useful for different people in the community to talk about, but it is not a report that our developers are going to be using. It can also managers prioritize performance over other existing issues and make sure that they have a minimum threshold before we release. 
 Don't stop reporting performance issues. But realize that all the threads on performance go to the forum readers like myself and do not go to the developers. They are using their own test infrastructure to find the same thing but in much actionable detail. 
 I agree that we should have good throughput numbers in the beta before GA. The problem is like one of cooking a meal and the turkey still needs more time in the oven while the rest of the meal is ready. We decided to go to EAP because we had features ready that we wanted people to try even if the main course was still not ready.

Part of the reason that there are so many threads on performance is due to the fact that everyone has a decent pipe to the internet and most of us utilize that bandwidth even if its just for watching cat videos on youtube. So to have a beta and then completely ignore the throughput numbers and then say that behind the scenes some people are aware and someone is going to tune is not very reassuring. 
 
 There is a balance of never replying and appearing to ignore the issue, replying with enough details to let people know we are on it, or replying with huge amounts of data that give too much away about our development process. Most employees are cautious about replying or don't feel they know the enough of details. But they haven't locked my account yet so I'm still here to give away secrets. :) 
 I'm trying to be reassuring but more than that I want to set an expectation: When EAP3 comes up the performance numbers will not be good enough to go to GA. 
 There are significant performance code changes that are not merged into EAP3. The builds that we are currently testing internally are significantly faster than the EAP3 that you will be testing. The performance tests you are running on EAP2 is code that is over a month old. Even when EAP3 comes out the performance tests you will be running are effectively going to be on old code. There are reasons that the new performance code is not yet integrated, we are waiting for a few more changes and we want to run it internal dogfoods before it is goes out to you guys. The schedule is not what we want it to be. Either we delay all of EAP3 waiting for the performance improvements, or we release EAP3 now and do another release later. I know this isn't anymore more than "trust us" but we are aware of the issue. 
 
 Thanks again for your comments and this post is in no way directed at you personally. 
 
 Your mother was a hamster and your father smelled of elderberries. :) 
 
 Truthfully though, I value the people who are active in the forum more than the people who are silent. I want to thank you for being one of the active, polite people.

Prism · Answer

[deleted]

Michael Dunn · Answer

The quick answer is that we know there are throughput issues. It is not about bugs, or about debug code, it is about tuning. I know that there are also differences in hardware, and I overhear conversations about how different appliances are behaving under different tuning. 
 I cannot say anything specific about EAP3 or any other release. I know there are a bunch of changes, I don't know when they'll make it to public. I would expect that the numbers will be significantly better by the time we get to GA. 
 While there is nothing stopping people from doing performance testing right now, anything measurements people take are not reflective of the real world. I don't believe any measurements people take will be used by the Devs doing the tuning.

SaschaParis · Answer

What is the output of 
 system application_classification show 
 in your device console? If it's on, you might test setting it to off using same command but replace show by off... 
 Not sure about the implication of disabling global app classification in V18, as this command bypasses snort, if no explicit IPS or application control rule is configured in the matching firewall rule. This was a good workaround to get linespeeds up to 17.5. However - I didn't test if this also bypasses the new fast path offloading capability of V18 (will test if I find some time), but as FastPath offloading in my eyes seems not to behave as intended at this specific release, this might help temporarily speed up things until Fast Path behaves as expected. 
 As you mentioned - it's early access..there is time until GA to bring things in shape, so I'm not too worried about in that early stage.