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

Were IIS written in managed C#, at least some of those problems may not have been introduced.

True, but the close integration to the OS is the only way they were able to achieve the performance numbers they have and add features like session storage. If you try to write an IIS application in a language that Microsoft doesn't support, I doubt you'll be able to take advantage of features like that. They made a trade-off.

Why does one need to understand reverse proxies, ports, networking, system resource balancing, etc, etc, etc - just to set up 2 VirtualHosts running completely independent of one another, so that you could stop/start one and not the other?

It's another trade-off. Rather than limit you to doing what the original developers thought of, Apache provides a very flexible solution which can be used in a variety of ways. That requires users to know something about the problem domain. Hiding those details would limit what you can do with the server.

And yet I have never seen an instance of Apache httpd installed (or set up by default) with mod_perl behind a proxy. Not since Redhat 5, not on Ubuntu 8.04, not on Fedora 9, CentOS or RHEL 5. Not with mod_perl 1.3x or with mod_perl 2.x. Not ever, not even once.

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.

It doesn't work for me anymore, especially with Microsoft's recent donations (and the implied (or my inferred)) influence over what happens with all of the Apache Software Foundation's projects. For all I know the money could be Microsoft's way of saying "Sit. Stay. Good boy."

Ok, this is just FUD and it's offensive. 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.

If your problem with Apache2 is that you don't like the way you configure it, try another server. There are literally hundreds of open source web servers out there, including some serious ones in Perl. There's no reason to start from scratch. Maybe you'll like lighttpd or AxKit2 or perlbal or one of the many others.

  • Comment on Re^3: Time to write a "serious" http server in Perl?

Replies are listed 'Best First'.
OT: MS funding ASF (was Re^4: Time to write a "serious" http server in Perl?)
by doom (Deacon) on Aug 14, 2008 at 18:53 UTC

    "Ok, this is just FUD and it's offensive. 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."

    This is not the way the world works. The way that it goes is that when you least expect it, Microsoft will start requesting some small little changes, and without quite saying it, there'll be a general feeling that the MS money may go away if you're not willing to Be Reasonable on these small, little things.

    Inside the Foundation, you'll then have a split between the people who see no problem with Being Reasonable, and the people who think you should stand on principle.

    Even if the Reasonable people really are just being reasonable, and even if this compromise is no big deal, and even if there are no further compromises down the road, Microsoft will still have managed to cause a rift in the ranks.

    The Apache foundation's reputation has already been slightly damaged by taking the money. Are you surprised that people are wondering what it means? Duh.

[reply]
      You simply don't know what you're talking about. The code is all under a good license and no corporation can force their will on the developers. If they could, Sun and IBM would have done so a long time ago.
[reply]
Re^4: Time to write a "serious" http server in Perl?
by jdrago_999 (Hermit) on Aug 11, 2008 at 06:02 UTC
    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.
[reply]
      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]

In Section Meditations