On 12/08/2010 05:26 AM, [email protected] 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:
http://trafficserver.apache.org/docs.html
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.
Cheers!
-- leif
