in reply to Re^3: Time to write a "serious" http server in Perl?
in thread Time to write a "serious" http server in Perl?

You're talking about default packages shipped by OS vendors? No one running a serious site on mod_perl would use those. I've never seen a mod_perl site getting real traffic that runs without a proxy or uses vendor binaries.
Yes I am talking about the defaults. How many "serious" sites run IIS without requiring the web dev team to "compile from source" and apply special proxy setups? Plenty, I'm sure. For that matter, why shouldn't someone trust that the vendor-supported version binary be suitable for a "serious" site? Should we call RHEL "Redhat Non-Serious Linux?" or "Linux for Dummies?"

If the vendor says (or even implies) than their product can perform some task, it should be capable of doing just that. I am aware of the disclaimer portions of EULA's that will say something to the effect that "this software is not guaranteed to perform anything or do whatever you thought it should." However, wouldn't it be a bit like purchasing a new automobile, then having to take it apart and put it back together before you can do any "serious" driving? If the manufacturer says it goes the speed limit and has a 5-star safety rating, it better measure up in the real world.

That said, I usually compile Apache httpd (and libapreq and mod_perl) from source, downloaded from a mirror linked to from the Apache httpd, libapreq and mod_perl websites. The main reason is that finding a compatible libapreq2 RPM or DEB is nigh impossible. Just as simple to install from source.

As for proxies being the recommended configuration for mod_perl (yes I've read this in several places) - the config file that ships with the source doesn't come with a proxy setup either. Never has from what I can tell. I've read "Writing Apache Modules with Perl and C" and "Practical mod_perl" - proxies barely warranted a mention.

Ok, this is just FUD and it's offensive.
Yes it is. Fear, Uncertainty and Doubt. I have all three at this point. And I'll have it regarding any group willing to take money off of Microsoft's hands.

Although I don't work on the httpd project, I am a member of the ASF (through work on mod_perl) and I can assure you that I don't have any plans to change my behavior due to Microsoft's contribution.
I commend your principle (and your long track record of holding it as well). It's not the individual developers like yourself that I wonder about. It's the addiction to the money hand-outs that worry me. Organizations bloat after receiving money. Only Hunger can drive groups like the ASF forward. Necessity is the mother of invention, not pandering to multi-national mega-corps for more donations.
  • Comment on Re^4: Time to write a "serious" http server in Perl?

Replies are listed 'Best First'.
Re^5: Time to write a "serious" http server in Perl?
by perrin (Chancellor) on Aug 11, 2008 at 17:39 UTC
    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.

[reply]

      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.

[reply]
        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.

[reply]
        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.

[reply]

In Section Meditations