Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Apache 2.2.0 Released

Posted by CowboyNeal on Thu Dec 01, 2005 11:12 PM
from the whole-new-bag dept.
ikewillis writes "According to an announcement on apache.org, Apache 2.2.0 has been released. From the announcement: 'This version of Apache is a major release and the start of a new stable branch. New features include Smart Filtering, Improved Caching, AJP Proxy, Proxy Load Balancing, Graceful Shutdown support, Large File Support, the Event MPM, and refactored Authentication/Authorization.' View the ChangeLog or check out the new feature list."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Apache 2.2.0 Released 25 Comments More | Login /

 Full
 Abbreviated
 Hidden
More | Login
Keybindings Beta
Q W E
A S D
Loading ... Please wait.
  • the wild west! (Score:3, Funny)

    by griffster (529186) * on Thursday December 01 2005, @11:15PM (#14163480)
    I'm waiting for Microsoft to rename IIS "Cowboy 1.0" :)
  • How does 2.2 stack up to 1.3? (Score:4, Interesting)

    by green pizza (159161) on Thursday December 01 2005, @11:17PM (#14163485) Homepage
    I read the feature list and changelog earlier today but without taking the time to set up a test server and experiment with it I really have no idea how it compares to 1.3. For the most part we have stuck with 1.3.x for it's stability, performance on our older hardware (from 256MB dual 75MHz SPARCstation 20 to 1 GB 440 MHz Netras), and rock solid compatibility with mod_perl and Perl 5.6.

    I'll be willing to try upgrading in the near future in hopes of experimenting with and making use of the some of the newer featues, but I would like to hear some first-hand information from those who have recently made the leap to 2.2, if at all possible.
    • I would be more curious if this now means the apache people are actively suggesting 2.0 on full-on production servers. Even a few months ago I briefly looked at switching my web cluster to 2.0, and I found posts saying "if there is no specific feature you
    • Do you really need to change? (Score:5, Insightful)

      by CyricZ (887944) on Thursday December 01 2005, @11:54PM (#14163656)
      What are the newer features that you're planning on using?

      Indeed, it sounds like you have what may be the perfect situation. Even if your servers are somewhat older, and not the most powerful, they are still very solid Sun systems. They will basically last forever. You suggest that mod_perl is working very well for you at the moment, too.

      Perhaps an upgrade would be the worst thing you could do. Sticking with older, proven systems is many times a very wise idea.

      [ Parent ]
    • Re:How does 2.2 stack up to 1.3? (Score:4, Interesting)

      by Not The Real Me (538784) on Friday December 02 2005, @01:59AM (#14164100)
      Slashdot is still running "Apache/1.3.33 Unix mod_gzip/1.3.26.1a mod_perl/1.29"

      In the meantime, you should upgrade to 2.2, post a link, tell us what happens to your server.
      [ Parent ]
  • Great Job ASF (Score:5, Insightful)

    by webperf (560195) on Thursday December 01 2005, @11:29PM (#14163541)
    A round of thanks to all the hard work done by the HTTPD team.

    you guys ROCK

    and special thanks to paul who pushed this through!
  • Inertia (Score:5, Interesting)

    by code65536 (302481) on Thursday December 01 2005, @11:33PM (#14163559) Homepage Journal
    That's interesting how they jumped from the 2.1.x beta versions to 2.2.0. They didn't do this when they went from the 2.0.x beta to the 2.0.x stable (hence the large .55 attached to 2.0.x right now). It's kinda like what Perl does with having devel and stable versions have odd and even numbers, respectively.

    Anyway, I guess the big question is, how many people will actually adopt 2.2.0. I still remember when 2.0 came out to mostly a yawn as most people kept using 1.3.x. Even today, most of the servers that I come across or administer are still using 1.3.x because unless you were running Windows, 2.x didn't really offer spectacular improvements over 1.3.x, and looking at the changes for 2.(1|2).x (anyone who's going to transfer a >2GB file over HTTP is crazy ;)), I have this feeling that we might see the same 1.3->2.0 inertia.
    • Re:Inertia (Score:5, Informative)

      by Floody (153869) on Friday December 02 2005, @03:24AM (#14164322) Homepage
      Anyway, I guess the big question is, how many people will actually adopt 2.2.0. I still remember when 2.0 came out to mostly a yawn as most people kept using 1.3.x. Even today, most of the servers that I come across or administer are still using 1.3.x because unless you were running Windows, 2.x didn't really offer spectacular improvements over 1.3.x, and looking at the changes for 2.(1|2).x (anyone who's going to transfer a >2GB file over HTTP is crazy ;)), I have this feeling that we might see the same 1.3->2.0 inertia.


      The change from 1.3 -> 2.0 was a very major one. The entire api was retooled; and for good reason, ap 1.3 had some rather serious deficiencies in the extensibility department (module load order significance, etc). 2.0 saw the birth of the exceedingly well designed APR (Apache Portable Runtime), a module-participation-driven abi ("hooks") and fast stack-unwinding i/o handling ("fitlers"). All good stuff, but slightly less able performance-wise on low-cpu-count hardware (extensibility always comes with a pricetag) and completely imcompatible with any module of even moderate complexity that had previously been written.

      Times have changed though. The robustness of the abi design combined with the APR has led to some outstanding modules, such as extensive state awareness and dynamic load-balance adjustment without even USR1-style interruption. None of these capabilities are even remotely plausible under 1.3.

      The point is: 2.2 is still the same core api design. Certainly, it contains some enhancements, but the bridge that must be crossed is miniscule in comparison to the 1.3/2.0 transition.

      There is still much room for improvement (when isn't there?). For example, mpm looks like a good idea on paper, but how well does it really work in terms of abstracting the process/thread semantics into fairly "pluggable" components? How well can it really work? Thread-based design requires a completely different approach or the end result (treating threads like processes) simply nets you more "accounting" overhead and few significant gains to offset that (yes, I realize it wins on win32 which does not have a light-weight process model).

      [ Parent ]
    • Re: Version numbers (Score:5, Informative)

      by rbowen (112459) on Friday December 02 2005, @08:43AM (#14165160) Homepage
      In the mean time (ie, since the 2.0 release) we've changed the versioning model to the "odds are dev, evens are stable" model. So as soon as 2.2 released, development moved to the 2.3 branch, which will release as 2.4. So, yes, like Perl and Linux and many other things.

      As for transferring >2GB files, this comes up many times every day on #apache, and fairly frequently on the mailing lists, so people do actually want to do this.

      Folks that are still using 1.3 are missing out on enormous strides forward. The "it still works fine, why should I upgrade" crowd are completely welcome to remain where they are, and we're not going to compel to move, but they are going to miss out on all sorts of cool things, in the name of "it's good enough already." Their loss, not ours.
      [ Parent ]
  • Combining mod_proxy with mod_cache (Score:5, Interesting)

    by paulproteus (112149) <slashdot@a[ ]esh ... m ['she' in gap]> on Thursday December 01 2005, @11:52PM (#14163644) Homepage
    I've been struggling with setting up a mirrors server for our computing club [jhu.edu] here. I'd like to mirror all of Debian, for example, but I'm finding that storing (and, worse, updating) 80 gigs only to serve a tiny fraction of the files to our users is a dismal trade-off. I had been experimenting with ProxyPass, but since it didn't cache the results locally, it wasn't really providing a speed benefit.

    mod_disk_cache plus mod_proxy's ProxyPass seems like just the ticket - I could give it a few servers to proxy for, give it a few hundred gigs of cache, and it would then automatically intelligently cache for those servers. This would be a great, easy plug-in solution.

    Has anyone used mod_proxy and mod_cache in this fashion? It'd be great to hear about others' experiences or configuration examples.
    • Re:Combining mod_proxy with mod_cache (Score:5, Informative)

      by gleam (19528) on Friday December 02 2005, @12:11AM (#14163719) Homepage
      I'd suggest going with Squid 3.0 (beta, but very stable in my experience) acting as a caching reverse proxy instead of Apache.

      use cache_peer to setup multiple debian mirrors as parents and it'll share the load between them.

      In my testing with squid 3.0 vs squid 2.5 vs apache 2.1.9 (the last beta version before 2.2.0), squid vastly outperformed apache when it came to this type of application.

      I'm sure someone will explain to me that apache 2.2 is actually far faster than squid, but in my experience, it's not.

      If you want to provide the mirror as a subdirectory of your current site, instead of giving it its own IP and domain, just set up squid to reverse proxy your entire site. You can configure different paths in the url to go to different parent servers, so /debian/ will be your debian mirror parent servers but everything else will be localhost:81, or whatever.

      YMMV etc etc, but that's what I'd do.
      [ Parent ]
  • Thank god for LFS. (Score:4, Insightful)

    by Anonymous Coward on Friday December 02 2005, @12:10AM (#14163709)
    For those of you saying you don't need to transfer >2GB it reminds me of comments like, "640k is enough for anybody", "64-bit isn't needed on the desktop", "no advantage to dual core" etc etc.

    This will finally mean I can wget DVD ISO images! Work with large files over WebDAV and it will also mean my logs can grow over 2GB which is cool.

    HTTP works where FTP has problems when dealing with complex networks (firewalls/NAT etc etc).
      • Re:Thank god for LFS. (Score:4, Insightful)

        by Slashcrap (869349) on Friday December 02 2005, @04:53AM (#14164518)
        No it doesn't unless you try and run a server from behind a firewall.

        And who the hell would want to run a server from behind a firewall? What a ridiculous idea.

        Just use passive mode and it will just work just as well as http.

        I see you've never configured a firewall then.

        Claiming that http servers need to support over 2gb is like claiming that DNS servers need to. And show me a real reason to go for 64-bit on the desktop.

        He gave some perfectly valid reasons for wanting LFS - WebDAV for one. You ignored them, probably because you didn't understand them. And then you called him an idiot. At least your sense of irony is well developed.
        [ Parent ]
    • Re:Bid Update? (Score:4, Insightful)

      by Coneasfast (690509) on Thursday December 01 2005, @11:29PM (#14163543)
      I don't get the feeling that this is a very significant update!

      any project in it's mature stages wont change much, at least not noticeable by most users.
      if bash creates a new release, you aint gonna notice the difference.
      if linux creates a new release, you aint gonna notice either (unless it's a major release, but in comparison, this apache release is not)

      [ Parent ]
    • wtf? (Score:4, Interesting)

      by Anonymous Coward on Friday December 02 2005, @12:06AM (#14163703)
      Storing state in the server and retrieving it via cookies, etc., is not CPS, it's just saving and retrieving state. And who still uses CGI anyway?

      And who says continuations are a valid way to write web apps? I prefer to use request/response because that's the model of the underlying architecture. I also want my URLs to represent named entry points, not continuations within some arbitrary program.

      And how the heck would Apache know how to save a continuation in any arbitrary programming language? Or is Apache supposed to turn into a set of libraries, one for Smalltalk, one for Ruby, one for Lisp.. ?

      Explain what you mean, son....
      [ Parent ]
    • Re:GUI? (Score:5, Insightful)

      by code65536 (302481) on Friday December 02 2005, @01:56AM (#14164093) Homepage Journal
      I've used the IIS GUI once because I was curious. *shudder* GUIs are useful only when well-designed.

      1/ There are Apache GUIs. Google them up. Some are free, some are not.

      2/ Opening the config file in a GUI text editor and navigating around with a mouse should be fairly easy, especially with the copious amount of documenation in the config.

      3/ It's very difficult to express the rich level of complexity of Apache configurations in a GUI. Just imagine how on Earth a GUI can be made to handle nested VirtualHosts, Directorys, and Files. Throw in some regexp, and suddenly, you are faced with a situation where it becomes a heck of a lot easier to just edit the config file. To say that a GUI is always easier than text is incorrect; it depends on the situation, and Apache configs are one of those situations where this is the case (kinda like how when dealing with non-photographic web graphics, you need to use PNG or GIF and avoid JPG like the plague and how when dealing with photographic web graphics, you have to use JPG... each rules over their own niche of strength).

      4/ If a GUI is made, it is highly likely that it won't be as powerful as just using a text editor; it's not as expressive (see above). But there's really not much to do with the basic configuration, either. For the most part, the default configuration works just fine, and if someone needs to edit the settings, it's mostly for the complicated stuff that would be a bloody mess to do in a GUI.

      5/ Compactness and portability.
      [ Parent ]