This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

8.301, web filtering still slow

Hi,

8.301 was supposed to fix a few bugs with web filtering. However, with 8.3.01 I still have the following phenomenon which can be reproduced:

- Turn Web filtering on
- Start IE, browse to Blick
- Page takes between 5 and 10 seconds to load completely
- Close IE
- Turn Web filtering off
- Start IE, browse to Blick
- Page takes around 1 second to load completely
- Close IE

The problem is not my browsers cache, I can loop the above test a few times and the results are always the same: With web filtering on that website is slow as hell, with web filtering off it's the way it should be. I'm running 2 ASG220 in active/passive mode, the one that's active hovers below 5% CPU all the time (we have less than 40 users on a 10M/10M line).

Is this still a known bug? I'm getting a bit peeved off, because half the features we're paying for are currently switched off on our firewall because they're buggy.


This thread was automatically locked due to age.
  • first..do you have a support ticket started with your reseller or astaro?

    Secondly how many users and how many features are you using?

    thirdly are you using the cloudy cff database or disk or mem?  if you don't know it's cloudy.
  • Hi William,

    first..do you have a support ticket started with your reseller or astaro?


    We didn't so far, but we did this morning.

    Secondly how many users and how many features are you using?


    We have about 35 users on a 10M/10M line. As for features, there's not that much active anymore. We're not using the virus scanner because it was buggy (supposedly fixed in 8.301, but I haven't checked yet). Not using mail security either at the moment because we have an external provider (symantec). Apart from the packet filter there isn't much else active at the moment (a DHCP and a DNS server, user portal, that's it). The firewall rarely is above 5% CPU.

    thirdly are you using the cloudy cff database or disk or mem?  if you don't know it's cloudy.


    I don't know, so I take it's cloudy? Does that mean the firewall asks an external database every time it needs to verify a URL?
  • Hi William,


    I don't know, so I take it's cloudy? Does that mean the firewall asks an external database every time it needs to verify a URL?


    yes and that craters performance..especially when the cff servers themselves have issues or when thee's inet congestion between you and your nearest cff server.

    http://www.astaro.org/astaro-gateway-products/web-security-web-filtering-application-visibility-control/35399-web-proxy-local-content-filtering-database.html#post164123

    I would advise disk mode for now until we see how your ram usage is going to be with v99which is upcoming).

    Now for some more questions:

    what kind of a/v issues are you experiencing?
  • Hi, and welcome to the User BB!

    Does that mean the firewall asks an external database every time it needs to verify a URL?

    Yes, but that shouldn't cause the slowness you're experiencing.  It sounds to me like your DNS configuration is incomplete.  Try DNS Best Practice.

    These all sound like configuration issues or that one or more of your PostgreSQL databases needs to be re-initialized.  You have enough machine that you should be able to run everything without a problem.  It will be interesting to learn what Astaro Support has to say after they look at your machine.

    Cheers - Bob
  • let's be realistic here...if you are using the cloudy content filter I've proved multiple times one by public testing and two just by logical explanation 90% of the time it is NOT dns. use the disk option and THEN see if it truly is still slow.  if it is then yes you MIGHT have a dns issue.  The second biggest cause if the proprietary proxy they are using isn't fully baked yet. Even with the known issues with the proxy using a local content filter db cache at least gives a signification boost to performance..until astaro either completes the proprietary proxy or goes back to squid.
  • i'll explain how the cloudy system works..
    you ask for hotmail.com
    the astaor has to go to it's fastest cff server(only measrued by pings..it doesn't measure load on that cff server).  so when you hit send every link on that page genreates a query. My fastest ping time to a cff server is usually 35 ms.  so you have a 35 ms transit delay to the cff server. i'll go best case on everything...so let's say best case the cff server is under light load and takes 5 ms to respond...you then have another 35ms delay back to your astaro before your can even begin requesting pages.  That equates to 75ms of delay before you even start transferring data.  This is not insignificant....this is also rarely the real time.  It is usually 100+ ms before you start getting data.  

    let's see the times if you use disk.  Let's say you are using 4500 rpm disks.  Best case if going to be 15ms for the queries with no transit delay.  That's more than half the time cut right there.  Average is going to be about 25.

    Let's talk about ram:  if you store it in ram the query time drops to 30 nanoseconds or less.  That's orders of magnitude faster...that is as close to instant as you can get.

    So just from a logical standpoint you can drastically cut down your query times using the disk option....especially if you are ram limited.  

    Any local cache option is not going to compensate for internet traffic issues of any kind though...[:)]
  • I guess I'm not touching anything until they had a look then. But the idea of having the URL database out in the cloud instead of the local appliance strikes me as a bit odd. Even if everything is absolutely perfect it's an extra roundtrip that needs to be made.

    The DNS servers are fine, I recently tested that with DNSBech (Steve Gibson).

    Thanks for the infos, I'll keep you posted if the support comes up with something.
  • The DNS servers are fine, I recently tested that with DNSBech (Steve Gibson).

    If you look in the Astaro DNS log and confirm that it's not getting DNS from the root name servers, then that's not your problem.  Depending on your settings in the HTTP Proxy, DNS requests may be done by the client or by the Astaro itself.

    Cheers - Bob