ASG tweaking

NOTE: the newest version of this guide is UTM Tweaking Guide 2.0.

I have listed here my very personal tweaking tipps for ASGs, which I'm using successfully since a long time, and which gave me in my very personal tests in different (mostly home user ASGs, but also some customer ASGs) good results. Measurements werde not done lab based, they are very subjective "how working through ASG feels", but maybe you like to give them a try...

This is not a official Astaro statement, these are my very personal opinions.

There are a few basic rules, which may help you keeping your ASG reactive and smooth from user view.

Hardware:
As Astaro declares 1GB memory as minimum requirement for ASG since version 7.4, i personally think, that starting from 2GB memory upwards working is fun - at least, if you are using all memory intensive features as IDS/IPS, webproxy, Mailproxy, Reporting. 1GB is ok for partial usage of ASG features.
Do I have to mention, that multicore also helps (Hyperthreading or "real" multicores) ? [:D]
==> minimum hardware requirement is not == recommended hardware [;)]

Basic networking settings:
Basically I recommend to make sure, that the "TCP Window Scaling" feature under "Network Security / Packetfilter / Advanced" is checked. For most scenarios this setting is a good tweak, unless your traffic mainly consists from small packets (serving a public DNS, VOIP etc.), or your ISP or networking infrastructure does not support "TCP Window Scaling" (only seen a few times in the last years). In V8 this setting is checked by default, in V7 not. So if you migrated from V7 to V8 this setting may still be disabled...
==> TCP window scale option - Wikipedia, the free encyclopedia

MTU on interfaces
Usually Ethernet Networks use a MTU of 1500. Make sure if you're using PPPoE/PPPoA (xDSL) for your Internet Uplink, that the MTU value is set lower (usually 1492 for PPPoE, but provider dependent I also already heard from other values as 1454 etc.). This should be done on the PPPoE Interface on the ASG if a xDSL bridge is used, but also on the according standard ethernet interface, if a xDSL router sits before the ASG, which makes the PPPoE connection.

DNS forwarder:
I sometimes have seen, that some people are using their internal domain DNS servers as forwarders for ASG. This is a possible bottleneck, because ASG is very DNS dependent. Better use public DNS servers as forwarder. Please use your ISP's public DNS servers instead of "open" servers as Google DNS or similar, if you're using ASG mailproxy / spamfiltering. Some RBL Providers seems to respond "not listed" for all requests - see for example Spamhaus FAQ (Thanks to William for this hint...)
I also do not recommend to simply put the single DNS servers into the dns forwarder field, because ASG seems to distribute it's requests via round robin across these DNS servers. If one of these servers fail, you may experience very strange behaviour. I usually create a availability group containing my public DNS servers I want to use, and use this availability group as forwarder (advanced settings: Test for UDP53 every 15s, fail after 3 missed tests). Requests to special domains (e.g. you internal AD DNS) should be created via DNS request route. Recommended DNS Setup is Clients use internal DNS/DC as DNS Server, Internal DNS/DC uses UTM as forwarder, UTM uses Public DNS Servers as forwarders).
DO NO MIX INTERNAL AND EXTERNAL DNS IN THE UTM DNS FORWARDER !!! THIS LEADS SOMETIMES TO STRANGE (MIS)BEHAVIOUR !!!

Quality of Service (QoS):
Ok. This one is to handle carefully. QoS can be a nice thing, but you also can mess up your ASGs performance, depending on you mainly traffic usage. In many cases I can live very good with the automatic tuning options, and the rare usage of manual bandwidth pools / traffic selectors (for S2S VPNs or RED traffic for example). I personally found these settings behave very well in most scenarios:
==> First check the QoS Interface speeds for standard Ethernet interfaces. Sometimes ASG seems not to use the right bandwidth for 1Gig Interfaces (102400 kbit/s instead of 1024000 kbit/s).
==> Then check the other interfaces speeds (as internet uplinks, RED interfaces, separate zone WIFI interfaces) and set them to appropriate values (do not forget to check the "limit uplink" setting)
==> For the different Interface usage types I found following settings working well, and keeping the reactivity for all connected systems fairly well distributed:
==> Internet Uplinks (Interfaces connected to Internet) - Only use the "Download Equalizer" setting (against my earlier recommendation using "upload optimizer", the "download equalizer" setting seems to behave better with actual UTM versions)
==> Locally connected Ethernet Interfaces as LAN or DMZ - I found the usage of the "Download Equalizer" setting behaving nicely here. This feature seems to little lower your maximum throughput for a single user, if he is able to saturate the interface bandwidth, but also keeps other connected workstations pretty reactive, if they for example are surfing at the same time. Especially in conjuction with the webproxy surfing fells somehow snappier with this setting.
==> separate zone WIFI interfaces: I personally found here the same settings as for local ethernet interfaces (only "download equalizer") behave nicely. I've set interface speed for AP30 to 144MBit. Maybe lower values would be more realistic, but it work well this way
==> RED interfaces - This depends heavily on RED usage / traffic type. Mostly I use "upload optimizer", because this helps with VOIP and websurfing...But for some scenarios no QoS at all, or the "download equalizer" may be a better setting. Simply try, whic setting behaves best for you.
=> The from ASG used technologies as RED, SFQ etc. are mentioned in the ASG online help. Google ist dein Freund or Wikipedia is you friend to find more detailed informations to these techniques (very interesting stuff to read).

Webproxy 
==> I use webcaching. BUT - I personally believe, that some content makes no sense to be cached (as most graphics, flash banners etc.) as most todays websites are dynamic, and the content changes a lot, which will lead to a low cache hit rate. Furthermore it may lower your disk I/O - especially on a heavily used webproxy. I will list below a list of content in perl regex notation, from which I belive this helps me to avoid unnecessary disk caching. Furthermore in my eyes small content as pics as 3-4KB GIFs or a favicon.ico will usually be delivered faster via Internet from the webservers memory cache compared to the local diskcache ;o)

Under Web Security / Webfilter / Advanced I have caching activated, and all checkboxes marked (HTTP, HTTPS and content from sites with cookies)

Local Content Filter Database:
==> This is a nice feature, but makes in my eyes only sense in a few scenarios, where heavy web usage makes categorization noticeable slower. I personally know 2-3 such sites, where the local CFDB helped to solve this issue under 8.1x ;o) But there was ~3500 concurrent Users surfing...
==> My opinion here is to test first without local CFDB, after applying all these mentioned tweaks in this thread. Especially on lower memory boxes no local CFDB performs way better than a local CFDB which may swap as hell...
==> Local CFDB in MEM may make sense starting from a 4GB+ Appliance, where without local CFDB maybe 50-60% of the mem already are in use
==> Local CFDB on DISK may make sense on boxes from 2...4GB memory, if there are fast disks installed. For VM Appliances in my eyes also not always recommended (test for your own). For Appliances with 1GB not recommended too - it works, but the heavy usage of swap makes it in my eyes not recommendable for those small appliances...in best case useable, if a 1GB Appliance is solely used as webproxy.
==> Local CFDB Howto can be found here

==> Caching Exceptions: Creating a exception in the webproxy to skip chaching for following URLs:
[EDIT 17-10-2011: New Regex for exceptions. using now the "$" to read the string from the end backwards, instead as before from start of the string using the caret "^". Seems to be faster / using less ressources]

Edit 13-4-2012: minimized the exception list - seems to behave better (lower cpu usage for regex pattern matching ?)

^https?\://.*\.google\.[a-z|A-Z]
\.smil$
\.xml$
\.html$
\.htm$
\.swf$

Manual URL blocklists
Edit 13-09-2012: I used since long time manual blocklist entries to block some widespread ad/tracker and other sites. Seems, that this was a bad idea performancewise. I had only those 14 listed URL's (Regex'es) in the blocklist, but removing them completely greatly improved website loading times. Seems somehow to be logic, as every Regex has to be checked against EVERY item loaded within a website.

So my new recommendation is "DO NOT USE MANUAL BLOCKLISTS", at least as far as possible. Every manual URL / regex will slow down website loading. Probably using URL's instead of regex with wildcards may behave better (not tested...)

Edit 29.01-2014: changed regex from 
^https?://.*\.
to 
^https?://([A-Za-z0-9.-]*\.)?
as second version uses nearly 2/3 less iterations for longer URL's than the previous one. And since changes in the UTM 9.2 regex handling the previous regex also may lead to PCRE errors.

Valid up to UTM 9.1

^https?://([A-Za-z0-9.-]*\.)?econda-monitor.de
^https?://([A-Za-z0-9.-]*\.)?hurra.com
^https?://([A-Za-z0-9.-]*\.)?adtech.de
^https?://([A-Za-z0-9.-]*\.)?wemfbox.ch
^https?://([A-Za-z0-9.-]*\.)?econda.de
^https?://([A-Za-z0-9.-]*\.)?eloqua.com
^https?://([A-Za-z0-9.-]*\.)?twitter.com
^https?://([A-Za-z0-9.-]*\.)?webtrekk.net
^https?://([A-Za-z0-9.-]*\.)?chartbeat.com
^https?://([A-Za-z0-9.-]*\.)?google-analytics.com
^https?://([A-Za-z0-9.-]*\.)?addthis.com
^https?://([A-Za-z0-9.-]*\.)?sharethis.com

Since UTM9.2 you can choose to enter own regex, or only domains with the option to include subdomains, which is since UTM9.2 the recommended simple version.


IPS (Intrusion Prevention System):
Network Security>>Intrusion Prevention>>Advanced Tab>>Performance Tuning. Add the applicable servers within your network to this section to avoid unnecessary false positives and blocked connections. Will also help to lower load from IPS. (Thanks to Scott Klassen to remind this one...)

Hope these tweaking settings may be helpful to anyone giving it a try. Please comment your personal findings, if using any of these tweaks.