trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Hedstrom <>
Date Wed, 08 Dec 2010 14:48:16 GMT
On 12/08/2010 05:26 AM, wrote:
> I will continue to use ATS with fixed timeouts and post results later. By now:
> Pros:
> + HTTP11 support (no errors which I saw when I was using squid)
> + Compact binary log
> ++ One big cache-db file instead of lot of small files
> +++ Caching algorithm works just fine out-of-the-box. I mean I don't need to tune "max_object_size",
increase TTL for images and CSS files. Looks like ATS handles this things automatically.

Great! yes, all these features you mention I 100% agree are major "wins" 
with ATS.

> Cons:
> - A lot of config files
> - A lot of irrelevant config options. Why should I care? I want simple proxy. Today is
XXI century, do you think HTTP caching is still so complex? :)

We are painfully aware of this, and it will be addressed further after 
the stable v3.0 release. It will take time though, so hopefully people 
will bear with us (what makes it particularly complicated is that we 
wish to improve/build more on our clustering features, which requires 
configs to be shareable and dynamically reloadable).

That much said, one thing I've been thinking of is to provide either a 
small 'wizard' (command line thing, answer a few questions, and it'll 
set up your configs). Or, ship with a small number of config sets (e.g. 
"Forward proxy", "Reverse proxy" and "Transparent proxy"), which would 
then unpack the required files, perhaps with minimal defaults.

One problem today with eliminating a lot of the "defaults" from 
records.config is that without them, it's difficult to find / know what 
settings you can tweak. As in your case, the timeouts are obviously very 
important. But even so, I think we can provide smaller defaults for 
these three config sets, which might turn records.config into maybe 40 
configs, instead of 400+.

> - Need to compile it. Figuring out that I have to disable "fd_events" (or smth) on debian
system takes time. Binary distribution is what users want, IMHO.

Yes. The hope is that once we have a more stable release, we'll get the 
big distros to pick it up. This is also high on our wish list, maybe we 
should get cracking on this some more, and get some volunteer work. I 
know "ming_zym" has a .spec file he's been using, which he has 
contributed, but we'll need to finish up these things to be at a quality 
where distros would accept them. And we'll obviously need a .deb for 
Ubuntu / Debian.

> - Lack of documentation.

Hmmm, not sure I agree with this one. There's a *lot* of documentation:

These aren't 100% up to date (there are features missing, and there are 
features we don't support), but I think they are both excellent starting 
points. Miles and Igor (and a few others) are also actively working on 
getting docs ready for a v3.0 release.

> Missing features:
> * Proxy authorization. Now the only way is IP-based auth (bypass.config). It is useful
to have Basic HTTP auth for authorizing clients. Of course, LDAP integration is welcome.

Noted. The hope is that we can write a plugin for this at some point.

> IMHO, ATS 2.1.4-unstable is stable enough for basic usage. It deserves to bear the name
"beta" :) I remember that guy who uses 44Gb for in-memory caching and expects bad response
time, but this is HUGE installation. As basic caching proxy, ATS works just fine. However,
config files have to be simplified. I am thinking about writing wiki page "ATS installation
as forward proxy", but I think today this is waste of time. You are reviewing configs, right?
I mean that "log2 ->  log" change. This is right direction.

I'm very to happy to hear that you are having a good experience! And 
thank you so much for the feedback, please keep it coming! The only way 
we can improve and make this a top-notch, production ready software,  is 
with user input like yours.


-- leif

View raw message