On Wed, Oct 10, 2012 at 1:46 PM, Eduardo Arino de la Rubia
<ear...@gmail.com> 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

Reply via email to