Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?

Perrin Harkins <[email protected]>
Newsgroups gmane.comp.apache.mod-perl
Message-ID <CAC0_be02iOYjiZByuRXxu+bNhvqwSj6v5UT-ZFm8xY6L8sZtzA@mail.gmail.com>
On Wed, Oct 10, 2012 at 1:46 PM, Eduardo Arino de la Rubia
<[email protected]> wrote:
> Greetings!

Hi!

> 1) Has anyone on this list actually run a Plack application *inside*
> mod_perl? I don't actually know that I understand how one does that. Can you
> speak to the relative merits of this approach?

I think it's pretty well documented.  If you want to use the PSGI API
directly, you set it up as shown in the synopsis here:
http://search.cpan.org/~miyagawa/Plack-1.0005/lib/Plack/Handler/Apache2.pm

More likely, you will be running something like Mason or Catalyst and
that will tell you how to set it up.

> 2) Do you believe that there are any compelling reasons to pick a mod_perl
> approach over a plack runner approach that we may be missing?

Advantages of a mod_perl approach:
- Access to all the mod_perl stuff on CPAN (auth modules, SizeLimit,
rate-limiting, etc.).
- Ability to use the Apache API when handling requests.
- Sounds like at least some of your team has real-life experience
running a site on mod_perl.

Advantages of a plack runner:
- Automatic restarts in dev without needing to use Apache::Reload or
seting MaxClients to 1.

I don't think there'd be a significant performance difference in any
real application, but if you build your app on PSGI you can run it
both ways and measure it yourself.

> 3) Given the fact that we are not required to maintain any of our legacy
> mod_perl code, would you (given the opportunity), go with a mod_perl
> solution in 2012 (to launch in 2013), or would you pick a different
> approach?

I'd probably make the decision based on whether the application seemed
to need something from the mod_perl CPAN modules and what my team's
experience is.

> I loved the ability to run
> multiple starman instances with totally different codebases and totally
> different process spaces, running totally different perblrews.  This made it
> so a bug in one of my applications did not cause downtime or "action at a
> distance" or difficult to track down errors.

FWIW, I have had no trouble running mod_perl with perlbrew and running
multiple mod_perl backends to separate applications or clients or
whatever.  That may be more of a concern for people who don't have
root on their host, but in this age of virtual machines that seems
like a rare problem.

- Perrin
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.