Re^5: Time to write a "serious" http server in Perl?

[perrin]

Red Hat, and other vendors, ship a general-use product that is suitable for basic work in many areas. The httpd they ship is compiled in a way that makes it friendly to RPM installs of .so packages, not to high-performance or to any specific use. They can't ship a proxy configuration because it wouldn't be the right thing for people using CGI or Java servlets and they have to please everyone.

For a dedicated server, you will nearly always need to compile your own httpd. This is true of Perl too -- the one Red Hat ships has threads compiled, which slows it down significantly for people who don't use threads. A simple recompile of Perl with all defaults will give you a significant speed boost.

Regarding your feelings about the ASF, I can't reason with paranoia, but I can tell you that the ASF includes many cantankerous old-timers and has had large contributions in the past from various other companies without compromising the quality of the projects I pay attention to.

[autarch]

Wow, I've never compiled my own Apache, nor has anybody I've worked with ever suggested we do so. I suppose I can imagine going to the trouble to do so in some situations, but there are a _lot_ of advantages to using the vendor packages.

That said, configuring two apache instances (one backend and one frontend) using stock Ubuntu apache is not terribly hard. I use the vendor-supplied config dir for the frontend, and set up a parallel directory structure for the backend (/etc/apache2-backend, /var/log/apache2-backend, etc). Works great.

[mr_mischief]

If you've never compiled your own Apache, you either haven't been using Apache as long as many of us or you were missing out on a good deal of its better functionality. IMO the vendor binaries from any vendor were not ready for high-volume web hosting just a handful of years ago. In recent years with advances within Apache and in the package management teams for the distributions, prebuilt Apache and addons for it have become a viable option.

There used to be something called Apache Toolkit, which was a menu-driven configurator for Apache, the DSOs, the basic configuration, and more. It was, IME, the most robust way to deploy a strong Apache configuration in a short amount of time. It would apply all the necessary patches, configure the build environment, compile everything, and install it for you. I'm not sure if it's still around, because RedHat/CentOS, Suse, Mandriva, and Debian all seem to have solid enough Apache packages now.

[perrin]

DSO is better than it used to be in apache 1, so there's less reason to do it now, but I still prefer it because I want control over what modules are loading and specific control over how some things (SSL, mod_perl) are compiled. The default one on distros I've seen includes junk you won't use and forces you to use DSO.

The other big problem is that switching versions of apache will usually break mod_perl, so I can't have the OS swapping it out under my feet. I have to be in control of when apache gets upgraded and to what version, much like controlling your CPAN module versions.

[autarch]

Back when Debian had Apache 1 as the default, it offered a separate apache-perl package that had mod_perl statically compiled. You could install the apache and apache-perl packages together side by side. Very nice.

Nowadays, with Apache 2, mod_perl is only a DSO, AFAICT, and I needed to set up my own parallel set of dirs, as I mentioned earlier, but it worked fine.

Since I'm not compiling my own mod_perl2, switching the Apache 2 version isn't an issue, since the packages all get upgraded together.