Poor performance after upgrade to 8.2

Hello Ian

Please describe, what you exactly wanted to do, and how your QoS Interface Settings, the traffic selector and bandwidth pool are configured...

Sascha

mine are simple in the extreme:

bandwidth pool:  smtp on wan guaranteed 128kbps
traffic selector:
internal
smtp
any

external setting
downlink 60 megabits
uplink 6144
limit uplink checked
using upload optimizer

wifi settings:
downlink: 1024
uplink: 8192
Limit uplink checked
upload optimizer checked

I don't use that list of proxy exceptions because i don't use the caching as it only caches objects less than 1 meg in size.

Further the outgoing QOS no longer appears to work, smtp outgoing is limited to 384kb, but now saturates the link.
Ian

This must be a new development, QoS worked pretty good for me after the initial problems in the beta. I haven't deployed the newer version yet, still running the release candidate from beta and waiting on a new ISO[:(] but I don't know how these new bugs are getting introduced[:S] I remember a few people had problems with guaranteed bandwidth but throttling should not be a problem unless introduced in the soft releases. Maybe its the upgrade from 8.103, don't know but this is turning out to be bad.

mine are simple in the extreme:

bandwidth pool:  smtp on wan guaranteed 128kbps
traffic selector:
internal
smtp
any

My smtp connector is
external/WAN 
smtp 
any

But I don't guarantee any bandwidth for smtp so don't know if its broken or not. The smtp throttling works fine for me using the above configuration atleast in the pre soft release versions.

all of the problems i have posted about happen regardless of upgrade or fresh install.

I remember issues with "Any" in previous versions, so I still try to use the actual traffic source.  If one is using the SMTP Proxy in this case, I would use a source of "External (Address)," but I would use "Internal (Network)" or an actual mail server definition if not using the proxy.  I know other approaches should work, but I prefer to use the one most likely to have been used by the developer in testing.  From that point of view, my choices above are educated guesses rather than actual knowledge of what has occured.

Also, last year, some people reported an issue with having 'Upload optimizer' checked when a 'Bandwidth Pool' was in use on an interface, so I've developed the habit of not using them together.   Since bandwidth pools can't be used to control inbound traffic, I always use 'Download equalizer'.

Cheers - Bob

Actually the QoS in 8.2 is way advanced compared to 8.1. For example you can throttle http with application control and it throttles all traffic including proxy traffic. Throttling proxies with QoS wasn't that simple before this version. 
There are some lingering bugs in this version related to http proxy otherwise it's definitely a step forward if they can sort it out.

I am not talking about the http or http proxy. I am throttling Sling traffic and RDP traffic. 

In either case the QoS in 8.201 doesn't function at all. No matter how we slice it, the 8.2 release is botched big time

Hello All

I do not believe, that QoS is messed up in 8.2x. There was changes as mentioned, that it also works with proxies.

I personally would expect, that most people who are experiencing such problems with their migrated 8.1x QoS settings to 8.2 is, that it probably was misconfigured before, and therefor didn't work at all in the past (so it also could not mess up your performance)

Most misconfigurations I have seen in the past (and I have seen a lot of them) was, that they wanted to make QoS for one of the Astaro proxied Services (example Mail Proxy), and created a traffic selector "internal Mailserver - Mailservices (SMTP and SMTPS) - ANY. This traffic selector never matched in 8.1x, because the proxy sends its mails out of WAN Interface (Source for traffic selector is WAN Interface, not internal Mailserver). With Proxies you had to use the ANY object as Source (or your WAN Interface) to create a working traffic selector rule...With 8.2x this seems to be different, because QoS seems to be aware of the original internal IP - also with proxies services (But I'm not 100% sure about this "internal IP awareness in 8.2,...maybe a developer may enlight us to this question...)

So with 8.2 such traffic selectors started to match, and those in the past not working QoS rules started to work as expected...

Only a assumption from me...

BTW: Using Download Equalizer on a WAN Interface is a bad idea at all IMO. From the two used techniques SFQ and RED the second one isn't work conserving. This means it will start to drop packets of the most consuming streams if bandwidth gets saturated and the waiting queue starts growing. This means furthermore, that you will get retransmissions and will saturate your WAN uplink even more...this will automatically end in a crappy performance under load.

For WAN Side only upload optimizer may be recommended in most cases...and it's also working nice in most cases without having to play around with traffic selectors and bandwidth pools [:)]

Sacha, 

I appreciate the long reply although that is a bunch of baseless assumptions. The QoS in 8.2 is not working or have major problems that I am experiencing on 2 installs. Migrated (Upgraded) 8.103 QoS settings no longer work in 8.201. Freshly created ones do not work either.

I am talking traffic coming in, going out both TCP and UDP. It is like QoS doesn't even exist.

The increased CPU utilization, the increased memory utilization and slower proxy is not even an big issue for me. QoS is.

@Sascha:  Is your 8.200/201 install an upgrade from 8.103 or from the 8.174 beta build?  The reason that I ask is that a significant number of problems currently existing in 8.200/201 only manifest themselves in upgrades from 8.103.  I actually wiped my upgrade from beta install and did a fresh 8.103-->8.200 to experience the same issues that others are reporting.

everything i've posted is there on upgrade or fresh install

everything i've posted is there on upgrade or fresh install

asg-8.102-2.1.iso -> 8.103 -> 8.200 (botched update, had to manually load it) -> 8.201
asg-8.103-18.1.iso -> 8.200 -> 8.201 via up2date

either case, same results for me. went back to 8.103 

this is worse than Windows ME. The bugfix list for 8.202 would be a mile long in my opinion. Bad start for Sophos.

Symantec made me give up PGP, lets see if Sophos will make me give up Astaro [;)]

@hardware:  8.174 (final released beta build)-->8.200 still has issues, but less of them.

FYI:  Sophos has nothing to do with the day to day operations of Astaro at this point, just so you know.  That kind of integration is still many months away from even being a possibility.