Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 1 subscriber
  • Views 1241 views
  • Users 0 members are here
Options
Suggested
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

wildcard
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.
Parents
  • 0
    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...[:)]
  • 0 in reply to William Warren
    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.
Reply
  • 0 in reply to William Warren
    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.
Children
No Data