Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 13 replies
  • Subscribers 1 subscriber
  • Views 4164 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

HTTP Proxy and CFFS (Categorization Servers) slowdown

x-cimo
I spent some time today to experiment with the Astaro Proxy server, looking for why the feeling of web browsing snappiness is gone when using astaro. As many pointed out it has to do with Astaro Categorization servers (CFFS).

I setup a SafeSquid Proxy, with URL filtering (just like astaro), and according to my test, Browsing with safesquid it twice faster than with Astaro, for example a page would take 3 sec to load took between 6 and 10 seconds to load with astaro. A 2 sec page took 4 sec with astaro. This is with a single user.

The wrose is this was with all security feature of the proxy turned OFF, (AV, URL filter etc)

I`ve also set my safesquid as a parent proxy for astaro to see what it does.  Basically even if you turn off all Astaro proxy feature, it still make 1 connection to its CFFS server for each request that the proxy process.

Over a few minutes, Astaro make 7316 request to its CFFSXX.astaro.com server!!

Now, what happen if you block thoses. I blocked the cffs server in the squid proxy, and things only gets wrose.. Page are even slower to load when using the Astaro proxy because all its connection to cffs server time out.. (See log below)

Finally, my ping to my closest cffs is not bad, so imagine how bad this gets for user with very high ping to the best of the cffs server list.

My ping is currently reported at 85 in the proxy log, and about 40 when using ping.

So basically, I believe there is a great area for improvement there. 

1) Why does Astaro still look for categoriezation even if all Feature of the proxy are turned off (including all URL filter), even if a host is white listed ???????????? This makes no sense to me
2) Why are the categorization not cached for some time? Currently it seem that 1Request = 1CFFS Request
3) Local replication would definatly be lightning fast, but probably have issues assosiated with.


This is what happen when you block all cffs(even if URL filtering if OFF), and start using the proxy:

2010:09:20-20:15:21 plasmashield httpproxy[651]: id="0003" severity="info" sys="SecureWeb" sub="http" request="0xf1850878" function="sc_categorize_url" file="scr_scanner.c" line="941" message="no categorization received for url: www.nationalpost.com/.../btn-next.gif"
2010:09:20-20:15:21 plasmashield httpproxy[651]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="sc_decrypt" file="scr_scanner.c" line="438" message="EVP_DecryptFinal failed"
2010:09:20-20:15:21 plasmashield httpproxy[651]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="sc_server_cmd" file="scr_scanner.c" line="631" message="cffs04.astaro.com: decrypt failed"
2010:09:20-20:15:21 plasmashield httpproxy[651]: id="0003" severity="info" sys="SecureWeb" sub="http" request="0xd735ae00" function="sc_categorize_url" file="scr_scanner.c" line="941" message="no categorization received for url: www.nationalpost.com/.../comments-logo.gif"
2010:09:20-20:15:22 plasmashield httpproxy[651]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="sc_decrypt" file="scr_scanner.c" line="438" message="EVP_DecryptFinal failed"
2010:09:20-20:15:22 plasmashield httpproxy[651]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="sc_server_cmd" file="scr_scanner.c" line="631" message="cffs03.astaro.com: decrypt failed"
2010:09:20-20:15:22 plasmashield httpproxy[651]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="sc_decrypt" file="scr_scanner.c" line="438" message="EVP_DecryptFinal failed"
2010:09:20-20:15:22 plasmashield httpproxy[651]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="sc_server_cmd" file="scr_scanner.c" line="631" message="cffs07.astaro.com: decrypt failed"
2010:09:20-20:15:22 plasmashield httpproxy[651]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="sc_decrypt" file="scr_scanner.c" line="438" message="EVP_DecryptFinal failed"
2010:09:20-20:15:22 plasmashield httpproxy[651]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="sc_server_cmd" file="scr_scanner.c" line="631" message="cffs06.astaro.com: decrypt failed"
 


So it does look for categorization even if it's not necessary.

Thoses who care about this, should speak: http://feature.astaro.com/forums/17359-astaro-security-gateway-feature-requests/suggestions/178336-websecurity-local-content-filter-database?ref=title


This thread was automatically locked due to age.
Parents
  • 0
    [FONT=Verdana][SIZE=2]Hi,

    I'd like to take the time to answer this, for the clarity of operations-sake. To answer your main question, why there are content filter lookups even with URL filtering off, is quite easy. With using JUST the http/s proxy "framework", even with no checks enabled, you are still getting one main benefit, logging and reporting. Reporting means the categories of the sites surfed need to be known, so as such the servers are still consulted where necessary.

    Caching is explained in good depth within the 7.500 release notes, but for your info, where you see cached in the logs, there is a flag which indicates the nature of the hit:
     ·  Cached=0: Object is new and not currently cached, and its nature cannot be handled by the cache for this hit, so it was served directly from the target server. 
    ·  Cached=1: Object is known and cached and has been served to the user via the cache directly.
    ·  Cached=2: Object is known to the cache but was past its server-configured expiry time. Object was revalidated (but not re-downloaded), and since no change was made to the object, it was issued to the user via the cache directly. 
    ·  Cached=4: Object was not present in the cache but it cacheable. As such, the object was downloaded and inserted in the cache while being served to the user.

    So depending on the site and many factors, mileage will vary there. With anything like browsing, the speed slowdown with checking each object (which we do in order to have the best and most accurate classification, vs. an inferior solution which would just check the main page url and not all of its objects which are rendered as part of it), the main speed factor will be the distance to the server, the ping to the closest CFF server, and the amount of objects. From there it is just simple math. A large site with many objects, how long each object is fetched by the users browser/Astaro, and a delay of 80milliseconds all times'd together can add up. Further, different browsers will have HUGE differences in how fast they can render a site purely by their architecture.

    However we DO indeed plan to offer a local download/copy of the categorization database, currently this is roadmapped (and reflected in the feature portal at feature.astaro.com) for 8.200.  It will take a fair amount of RAM, which is still being worked on, probably in the realm of 400-800 megabytes depending on the final implementation, which puts it outside of the lower end appliances reach. However for larger boxes or software installations, especially with the new V8 kernel supporting 64-bits and gargantuan amounts of installed memory, it will provide an alternative.


    Thanks a lot for your feedback, hopefully that answers some of your questions!     
     
    [/SIZE][/FONT]
Reply
  • 0
    [FONT=Verdana][SIZE=2]Hi,

    I'd like to take the time to answer this, for the clarity of operations-sake. To answer your main question, why there are content filter lookups even with URL filtering off, is quite easy. With using JUST the http/s proxy "framework", even with no checks enabled, you are still getting one main benefit, logging and reporting. Reporting means the categories of the sites surfed need to be known, so as such the servers are still consulted where necessary.

    Caching is explained in good depth within the 7.500 release notes, but for your info, where you see cached in the logs, there is a flag which indicates the nature of the hit:
     ·  Cached=0: Object is new and not currently cached, and its nature cannot be handled by the cache for this hit, so it was served directly from the target server. 
    ·  Cached=1: Object is known and cached and has been served to the user via the cache directly.
    ·  Cached=2: Object is known to the cache but was past its server-configured expiry time. Object was revalidated (but not re-downloaded), and since no change was made to the object, it was issued to the user via the cache directly. 
    ·  Cached=4: Object was not present in the cache but it cacheable. As such, the object was downloaded and inserted in the cache while being served to the user.

    So depending on the site and many factors, mileage will vary there. With anything like browsing, the speed slowdown with checking each object (which we do in order to have the best and most accurate classification, vs. an inferior solution which would just check the main page url and not all of its objects which are rendered as part of it), the main speed factor will be the distance to the server, the ping to the closest CFF server, and the amount of objects. From there it is just simple math. A large site with many objects, how long each object is fetched by the users browser/Astaro, and a delay of 80milliseconds all times'd together can add up. Further, different browsers will have HUGE differences in how fast they can render a site purely by their architecture.

    However we DO indeed plan to offer a local download/copy of the categorization database, currently this is roadmapped (and reflected in the feature portal at feature.astaro.com) for 8.200.  It will take a fair amount of RAM, which is still being worked on, probably in the realm of 400-800 megabytes depending on the final implementation, which puts it outside of the lower end appliances reach. However for larger boxes or software installations, especially with the new V8 kernel supporting 64-bits and gargantuan amounts of installed memory, it will provide an alternative.


    Thanks a lot for your feedback, hopefully that answers some of your questions!     
     
    [/SIZE][/FONT]
Children
  • 0 in reply to AngeloC
    [FONT=Verdana][SIZE=2]Hi,

    I'd like to take the time to answer this, for the clarity of operations-sake. To answer your main question, why there are content filter lookups even with URL filtering off, is quite easy. With using JUST the http/s proxy "framework", even with no checks enabled, you are still getting one main benefit, logging and reporting. Reporting means the categories of the sites surfed need to be known, so as such the servers are still consulted where necessary.

    Caching is explained in good depth within the 7.500 release notes, but for your info, where you see cached in the logs, there is a flag which indicates the nature of the hit:
     ·  Cached=0: Object is new and not currently cached, and its nature cannot be handled by the cache for this hit, so it was served directly from the target server. 
    ·  Cached=1: Object is known and cached and has been served to the user via the cache directly.
    ·  Cached=2: Object is known to the cache but was past its server-configured expiry time. Object was revalidated (but not re-downloaded), and since no change was made to the object, it was issued to the user via the cache directly. 
    ·  Cached=4: Object was not present in the cache but it cacheable. As such, the object was downloaded and inserted in the cache while being served to the user.

    So depending on the site and many factors, mileage will vary there. With anything like browsing, the speed slowdown with checking each object (which we do in order to have the best and most accurate classification, vs. an inferior solution which would just check the main page url and not all of its objects which are rendered as part of it), the main speed factor will be the distance to the server, the ping to the closest CFF server, and the amount of objects. From there it is just simple math. A large site with many objects, how long each object is fetched by the users browser/Astaro, and a delay of 80milliseconds all times'd together can add up. Further, different browsers will have HUGE differences in how fast they can render a site purely by their architecture.

    However we DO indeed plan to offer a local download/copy of the categorization database, currently this is roadmapped (and reflected in the feature portal at feature.astaro.com) for 8.200.  It will take a fair amount of RAM, which is still being worked on, probably in the realm of 400-800 megabytes depending on the final implementation, which puts it outside of the lower end appliances reach. However for larger boxes or software installations, especially with the new V8 kernel supporting 64-bits and gargantuan amounts of installed memory, it will provide an alternative.


    Thanks a lot for your feedback, hopefully that answers some of your questions!     
     
    [/SIZE][/FONT]


    That's great news Angelo!

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    Indeed!

    Btw, I am sure Astaro do their best to keep their focus where it matters, Security. But I felt like that area was a big drawback to performance, and it was something that could be improved [[[:)]]]

    I am testing Beta since v7.0 and so far, I am quite impressed by the quality and feature set

    This new "local caching" features, coming "hopefully" in 8.2 will be well welcomed and should produce quite a boost in performance for the proxy especially for large entreprise (I am only a picky Home user).

    This stuff is very welcome in my Ram, which is quite under used right now [[[:)]]]

    Thanks for the feedback! [[[:)]]]