This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Setting up Apache2 with mod_perl and Apache2::AuthCookieLDAP

On 5/6/2014 11:42, Andrew DeFaria wrote:
I could just switch to a Linux server but I figured I'd try my
Windows laptop first.

Don't neglect the option of running a minimal Linux VM on the laptop. You can shove a headless Linux VMs into a pretty small slice of RAM.

Goal: Set up Apache2 on my Windows laptop with mod_perl

mod_perl has been slowly dying for years. It's not dead yet (*thwack*) but it pretty much only works with Apache 2.2 and older. RHEL7 won't include it at all, because it will ship with Apache 2.4.6. There are third-party patches floating around the net that restore compatibility, but this isn't the sort of thing you want to be building programs against that have to live for many years to come.

Cygwin still ships Apache 2.2, but you'd be betting that either Cygwin Apache will never be updated to 2.4, or that mod_perl will get dragged into the modern world before that happens.

mod_perl is being allowed to die because all the modern web frameworks have moved to PSGI/Plack instead:

PSGI abstracts away the operating environment. You can run PSGI apps standalone as their own web server, or behind a fast reverse proxy, or in a FastCGI environment (e.g. Apache's mod_fcgid). From the software development perspective, it's all the same. (Devops is a different story, of course.)

A common pattern is to run the PSGI app with an internal web server on localhost:3000 or whatever, then put nginx or similar in front of it to carry the static content load and proxy dynamic page requests to the web app.

Since the native Windows nginx port doesn't yet run as a Windows service, it isn't suited for systems that need long uptimes, or which can't be left logged in to an interactive desktop. The native Windows version of Apache is only a smidge slower than nginx for many workloads, it ships with mod_proxy to make it act as a reverse proxy, and it naturally runs as a Windows service:

It is common to use HTTP::Server::PSGI ( for development, and only switch to something more complicated when it comes time to deploy to production. If your web app won't have a high load, you may not have to switch at all. Or, if most of the load is static content, you can push that load off onto the reverse proxy. Single-threaded dynamic page generation is fine for many web apps.

If you really need concurrent dymamic page generation, a lot of people use Starman ( rather than a traditional web server. It is a pure Perl pre-forking web server, compatible with PSGI, and fast enough that a lot of its users don't use a reverse proxy in front of it at all.

If you go Perl-native, your web app can run as a single-instance program, which can have tremendous benefits. A lot of old web frameworks persist session data to disk purely because it assumes it will run under pre-forking Apache, where there are many short-lived children that may contend for access to the session store. When all I/O comes into a single long-lived process, you might not have to persist some things to disk at all, greatly reducing that area of I/O overhead. Single-instance web apps also don't have to pay other penalties associated with periodically killing off an restarting child forks.

You don't have to use PSGI/Plack directly. All of the modern Perl web frameworks -- Catalyst, Mojolicious, Mason/Poet -- will run under it, providing a much nicer usage environment. I've been using Dancer ( for months now, and love it. I just tested, and it does build and run under Cygwin. Install App::cpanminus with cpan, then just say "cpanm Dancer". Done, easy.

(I chose Dancer because it doesn't impose MVC or ORM policies like a lot of other web frameworks do. (Catalyst, Rails, Zope, etc.) You're free to design your web app however it makes sense to you.)

If you do go with Dancer or something like it, you don't need to use Cygwin Apache. The native Windows version of Apache will perform much better, and when used as a reverse proxy, you probably won't need any of the benefits you get from using Cygwin Apache which native Apache wouldn't have, such as the ability to compile and load some of the more esoteric modules that only build on POSIXy systems.

First problem (minor): I can't figure out how to install Apache2 as a
Windows service.

Another reason to native Windows Apache instead.

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]