Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15
  1. #11
    Untangle Junkie dmorris's Avatar
    Join Date
    Nov 2006
    Location
    San Carlos, CA
    Posts
    17,486

    Default

    I'm hesitant to post this, as it could be perceived as an investment in time convincing people not to buy a subscription to web cache, however what we see more often than not is people using web cache that shouldn't be while using premium package and having a sub-par performance because of it.

    Here's an analogy I use a lot.
    Pick a task you do almost every day, say commuting to work.
    Ask yourself: Would you drive an extra mile every day if it gave you a 1% chance to skip your commute entirely on any given day?

    Think that through for a minute... (seriously)

    For most people the answer should be no. Lets assume most people commute 10 miles, so they would now be driving 11 miles everyday with the 1% chance to save 10 miles on any given day. For extra 100 miles driven, they'd save 10.

    BUT:
    If you commute over 100 miles a day OR you were going to drive an extra mile out of your way anyway (to go get your morning coffee or something) then you should answer yes, because in this case it SAVES you driving.

    Now, lets tie that back analogy to web cache.
    You should run web cache if your internet is very slow (ie you have >100 mile commute) or you have unspent server resources that are sunk cost that you've paid for that you want to recover (you're driving extra mile to get your coffee anyway).
    In MOST cases, you should not run web cache because you'll end up spending $100 in server resources to save $10 in internet traffic and saved browsing time.

    The problem when people say that web cache is great unilaterally and that it saves time is that they're not accounting for the server resources spent on caching OR the sunk cost they've already spent on server resources that are sitting idly doing nothing. If you have sunk cost in idle server resources, web cache might indeed be able to help you recover SOME of this cost, but this is not money earned, its losses recovered.

    In reality, most often we see large sites, like schools, with decent internet connections 5Mbit+ (ie, with short 10 mile commute) that have extremely busy untangle servers (ie no extra unspent resources) because they are literally running every app untangle offers and have probably cranked up data retention time in reports for some extra load on the disk for good measure. CPU is busy, disk i/o is saturated, memory is being used. In this case you'll save maybe $5 of bandwidth a month but you'll lose much much more in added latency to run the cache and possible downtime (depending on how busy your server is).

    Its important to realize a couple key trends:
    1) Bandwidth is now huge and growing (on the scale of cachable web content)
    2) More and more web content is dynamic (uncachable)
    3) Web content is growing dramatically (making user dupe cache hits less likely)
    4) Chrome/IE/Firewall/Safari/Opera browser speed wars have made browser caches extremely efficient.

    These 4 trends have made stand-alone web cache much less effective.
    This is not 1996 when squid was launched and businesses were running on ISDN lines and most web content was static and browsers were terrible. (hescomingsoon, much less your experience from 1992)

    You should run web cache if meet a few of the following conditions:
    * Your internet is really really slow
    * You have users browsing duplicate content (otherwise the browser cache will do this work for you)
    * Your have plenty of unspent resources on the untangle server (disk i/o and cpu mostly, web cache doesn't require much memory)
    * You have really expensive pay-per-usage bandwidth

    To the OP: the larger your cache size the bigger your investment in hardware and the more competition with other apps requiring server resources. So with a cache size of 1 gig, you may spend $100 in server resources to save $10 in bandwidth, with 2 gig, you map spend $250 in server resources to save $20 in bandwidth. It does not scale linearly. In our experience when you give users a knob that they think turning it up will help, they will turn it all the way up. Unfortunately in this case users' intuition is wrong, turning up the web cache size makes it perform worse. In v9.1, we based the cache size of % of disk free and found that those using expert mode to create big partitions and thus large cache sizes had the worst performance.
    Last edited by dmorris; 03-23-2012 at 07:07 PM.
    mrunkel likes this.
    Attention: Support and help on the Untangle Forums is provided by volunteers and community members like yourself.
    If you need Untangle support please call or email support@untangle.com

  2. #12
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,517

    Default

    Quote Originally Posted by dmorris View Post
    Its important to realize a couple key trends:
    1) Bandwidth is now huge and growing (on the scale of cachable web content)
    2) More and more web content is dynamic (uncachable)
    3) Web content is growing dramatically (making user dupe cache hits less likely)
    4) Chrome/IE/Firewall/Safari/Opera browser speed wars have made browser caches extremely efficient.
    This, plus the reality that transparent proxies have a tendency to break dynamic web services at random intervals, for example, Windows update.

    I was excited at the prospect of using the Web Cache when it was announced, however, the sites where I had it deployed in the first 30 days the reports told me everything I needed to see. I'd have 30-40gb of transfer, and 150-250mb of bandwidth saved. In my case the performance wasn't an issue, because the servers were over allocated. However, the 250mb of saved bandwidth over a month couldn't justify the support issues on the windows update issue alone, much less the random troubles with other sites and services.

    Web Cache is a valuable addition to the premium bundle. However, I haven't found a case where it has value on its own. I think your experience mirrors with this experience. The module however is valuable where Internet costs are high, and bandwidth is at a premium. However, from what I've seen, basically if you're in the US, Canada, or most of Europe, the module just isn't for you.

    The only customers I have that I know are using this module successfully are in Africa. Its simply something that needs to be used as you said, where bandwidth is expensive. Which directly translates into developing areas, this applies to rural applications as well.

    Hescominsoon, don't get upset with MRunkel, heaven knows I've made the same mistake you did often enough. His communication mechanism is blunt, and similar to my own. He knows what he's talking about, and every case where I felt he was hitting me personally after going back and looking a second time has been my fault for simply reading too far into what was typed.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  3. #13
    Untangler
    Join Date
    Nov 2011
    Posts
    37

    Default

    Quote Originally Posted by hescominsoon View Post
    more and more sites are actually generated on the fly with no or little static content. This means caching effectiveness is going to go up or down depending on the sites your users visit.
    I understand that, but we are talking about the span of a few months. I didn't know the web cache had dropped so much performance due to the reporting bug in a previous release that I had to wait on another release to fix it. Once that was fixed, I could compare old and new reports and noticed a really large gap.

    I'm running untangle on basically the bare specs of a machine, nothing high end at all. It's performance with previous web cache settings actually worked great. The new settings are as expected much lower because it's been tuned to cache much less than before. All that I'm asking is for a way to get some control back on Web Cache that doesn't involve getting into the machine OS and changing squid settings manually to what they were previously.

    Web Cache is a paid service and as such I'm not happy with it now. If it were a free module, then I could see the untangle crew wanting to reign in control a little more. There are plenty more ways to hose your untangle machine than changing around some cache values for the web cache, so I have trouble understanding why there would be such a great concern about customer satisfaction of performance.

    I'll put in a request as recommended and the concern about customer satisfaction should really be left up the customer if it's stated right on the control that "use at your own risk of performance issues if not tuned properly"

  4. #14
    Untangler
    Join Date
    Nov 2011
    Posts
    37

    Default

    Quote Originally Posted by dmorris View Post
    You should run web cache if meet a few of the following conditions:
    * Your internet is really really slow
    * You have users browsing duplicate content (otherwise the browser cache will do this work for you)
    * Your have plenty of unspent resources on the untangle server (disk i/o and cpu mostly, web cache doesn't require much memory)
    * You have really expensive pay-per-usage bandwidth

    To the OP: the larger your cache size the bigger your investment in hardware and the more competition with other apps requiring server resources. So with a cache size of 1 gig, you may spend $100 in server resources to save $10 in bandwidth, with 2 gig, you map spend $250 in server resources to save $20 in bandwidth. It does not scale linearly. In our experience when you give users a knob that they think turning it up will help, they will turn it all the way up. Unfortunately in this case users' intuition is wrong, turning up the web cache size makes it perform worse. In v9.1, we based the cache size of % of disk free and found that those using expert mode to create big partitions and thus large cache sizes had the worst performance.
    That fits why we use it. Our untangle box only does one thing, web cache. It's about as bare minimum specs that untangle will allow, a PIV 2GHz PC with 512MB of RAM, and 500GB of disk space. It's setup as a transparent bridge, and every single thing is bypassed from the UVM except for Web Cache. It will pass about 200GB of traffic a day, of which usually 10% to 15% would be pulled from the cache.

    The settings haven't been changed since it was built and set into production, but the new version has a reduced cache size that has brought the cache down to about being less than 1% effective. Out of 200GB of traffic, only 200MB would come from cache that day. It's not just a gradual change, it's a massive change in effectiveness despite how websites and such are evolving.

    My guess is that the cache is just filling up to it's maximum too fast and throwing out old files that then are requested again, but don't live in the cache anymore, thus having to fetch it from the website instead of the cache. I can do this fairly quick just surfing the NASA photo archive because they have large 10MB to 30MB size picture files by the thousands there.

  5. #15
    Master Untangler
    Join Date
    Jan 2011
    Posts
    110

    Default

    Just to add my results to the mix....

    We've been running Untangle premium for a year now in a school setting...... always using web cache. Never once messed with custom settings re:web cache, adjusting disk size, etc.

    Running the latest 9.2 still provides us anywhere from 11%-19% obtained directly from cache on any given work day. Noticeably less on weekends. Have not noticed any drop in cache % across updates. Clients run a mix of Firefox and IE.

    I believe the effectiveness of the web cache% depends largely on what your clients visit, the size of cache-able items and the amount of "repeat business" of sites across your network that gives web cache a chance to shine.

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2