Plack
Has anyone here played with Plack yet ? ( http://plackperl.org/ ) It's about a week old or so publicly, but I'm sure a few of you folks here were privvy to a preview... // Jonathan Vanasco e. jonat...@2xlp.com w. http://findmeon.com/user/jvanasco blog. http://destructuring.net | - - - - - - - - - - | Founder/CEO - FindMeOn, Inc. | FindMeOn.com - The cure for Multiple Web Personality Disorder | - - - - - - - - - - | CTO - ArtWeLove, LLC | ArtWeLove.com - Explore Art On Your Own Terms | - - - - - - - - - - | RoadSound.com - Tools for Bands, Stuff for Fans | - - - - - - - - - -
Re: Plack
Whaddaya know... Ironically, this might have saved Plone at my workplace had I known that this was on the way. We were looking at writing custom WSGI components in Python and shuddering (well, I was shuddering) Jonathan Vanasco wrote: > > Has anyone here played with Plack yet ? ( http://plackperl.org/ ) > > It's about a week old or so publicly, but I'm sure a few of you folks > here were privvy to a preview... > > > > // Jonathan Vanasco > > e. jonat...@2xlp.com <mailto:jonat...@2xlp.com> > w. http://findmeon.com/user/jvanasco > blog. http://destructuring.net <http://destructuring.net/> > > | - - - - - - - - - - > | Founder/CEO - FindMeOn, Inc. > | FindMeOn.com - The cure for Multiple Web Personality Disorder > | - - - - - - - - - - > | CTO - ArtWeLove, LLC > | ArtWeLove.com - Explore Art On Your Own Terms > | - - - - - - - - - - > | RoadSound.com - Tools for Bands, Stuff for Fans > | - - - - - - - - - - >
Re: Plack
On Oct 15, 2009, at 10:01 AM, Issac Goldstand wrote: Whaddaya know... Ironically, this might have saved Plone at my workplace had I known that this was on the way. We were looking at writing custom WSGI components in Python and shuddering (well, I was shuddering) I'm 80% Python now, so that would be exiciting to me ;) I can't stand plone though, I do everything in Pylons... which is actually a lot like ModPerl Porting WSGI to Perl is really awesome though. And MP is already supported out of the box !
Re: Plack
Jonathan Vanasco wrote: Has anyone here played with Plack yet ? ( http://plackperl.org/ ) It's about a week old or so publicly, but I'm sure a few of you folks here were privvy to a preview... I haven't played with it, but i have read a bunch of Miyagawa's blog posts about it. I do know that Jeff Horwitz is planning to support WSGI in mod_parrot / mod_perl 6, but i don't know exactly what that means ;) Adam
Re: Plack
On Oct 15, 2009, at 1:36 PM, Adam Prime wrote: I haven't played with it, but i have read a bunch of Miyagawa's blog posts about it. I do know that Jeff Horwitz is planning to support WSGI in mod_parrot / mod_perl 6, but i don't know exactly what that means ;) Yeah I heard about that too. Unfortunately, I seriously doubt I'll ever use Perl6. The PSGI spec is really neat. It's just a perl version of WSGI. I'm hoping to play around with it on some spare time next month, and see if it can get around some of the weird stuff I've had to do with libapreq in the past.
Re: Plack
I've been - in my spare time - trying to figure this PSGI thing out. I'm a Windows guy you see, and I realised there's no PPM for Plack. Is Strawberry the only alternative? Jonathan Vanasco wrote: On Oct 15, 2009, at 1:36 PM, Adam Prime wrote: I haven't played with it, but i have read a bunch of Miyagawa's blog posts about it. I do know that Jeff Horwitz is planning to support WSGI in mod_parrot / mod_perl 6, but i don't know exactly what that means ;) Yeah I heard about that too. Unfortunately, I seriously doubt I'll ever use Perl6. The PSGI spec is really neat. It's just a perl version of WSGI. I'm hoping to play around with it on some spare time next month, and see if it can get around some of the weird stuff I've had to do with libapreq in the past.
Coupling Plack/PSGI with mod_perl, or an alternate architecture?
Greetings!
I know this may be a biased audience, it being the mod_perl mailing list,
but I since I don't have a plan, I'm trying to crowdsource one :-)
At $employer, we have chosen to build our next revision of our application
using a Plack/PSGI stack. We have been sold on Plack/PSGI as a "next
generation" architectural approach. We like the way it provides layering,
it allows you to build middleware which solves generalized problems, and
overall it's relatively clear that the Perl community is embracing this.
First and foremost, if you believe this to be a fundamental error, I would
love to hear from you.
However, the real question is one of *deployment platform* for our
Plack/PSGI application. We have two seperate camps at $employer, one that
believes that given our Plack/PSGI approach, we should run in a dedicated
Plack/PSGI container (such as Starman today, but potentially something else
in the future), and another camp which believes that we should deploy our
application in a mod_perl container.
So here are my questions:
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?
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?
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 feel it's only fair to speak to my personal bias. I have developed
mod_perl applications for a long time, and feel that historically this has
been the absolute "top of the line" in extracting performance out of my
lamp stack. However, given the migration of the community towards perlbrew,
and the slowness of distros to provide modern perl, I started looking at
other options. At $employer->previous I deployed applications using Apache
and nginx as a proxy, and Starman on the back end. 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. I felt it made my
development and maintenance easier, even if I did sacrifice performance
slightly.
Thanks for your time!
--
int getRandomNumber() {
return 4; // Chosen by dice throw.
// guaranteed to be random...
}
Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?
On Wed, Oct 10, 2012 at 1:46 PM, Eduardo Arino de la Rubia 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
Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?
> Has anyone on this list actually run a Plack application *inside* > mod_perl? Yes. > how one does that. <http://p3rl.org/Plack::Handler::Apache2> > relative merits of this approach? It is very similar to the way traditional mod_perl apps are deployed and therefore familiar. > reasons to pick a mod_perl approach over a plack runner approach Requires no proxying. More reasons in <http://www.catalystframework.org/calendar/2007/17#Motivation>; don't get confused about the deployment notes, that was before the switch-over to PSGI. > would you pick a different approach? Catalyst main mindshare is that if decoupling is desired, to achieve it through mod_fastcgi/FastCgiExternalServer. <http://wiki.catalystframework.org/wiki/deployment> signature.asc Description: PGP signature
Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?
On Wed, Oct 10, 2012 at 12:39 PM, Perrin Harkins wrote: >> 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. - Knowledge that the base Apache httpd codebase is used by many other websites, and has been through security audits, performance tuning, and is composed of a set of developers who are committed to the long term health of the codebase. - A stable history of distribution packaging. Odds are the platform you are using has mod_perl / Apache rpms/deb/ebuilds/etc for quite some time. - Knowledge that mod_perl has been proven in large scale deployments. The biggest I've worked on is about 500 servers if I recall correctly.
Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?
On Wed, Oct 10, 2012 at 3:57 PM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote: >> reasons to pick a mod_perl approach over a plack runner approach > Requires no proxying. Isn't Starman normally run with a proxy in front of it? If not, it should be. Otherwise, you'd be tying up large processes sending bytes to slow remote clients, just like you would with a standard mod_perl app. - Perrin
Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?
--- On Fri, 10/12/12, Fred Moyer wrote: > On Wed, Oct 10, 2012 at 12:39 PM, Perrin Harkins wrote: > >> 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. > > - Knowledge that the base Apache httpd codebase is used by many other > websites, and has been through security audits, performance tuning, > and is composed of a set of developers who are committed to the long > term health of the codebase. Not all of them. Using the duck principle, some of them are just shills. After the recent DNT fiasco https://github.com/apache/httpd/commit/a381ff35fa4d50a5f7b9f64300dfd98859dee8d0 I don't believe apache can be trusted. (Or the W3C, who permitted their version of the standard to magically change at a single editor's whim 11 days ago, a month after his patch submission.) Phil
Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?
On Fri, Oct 12, 2012 at 12:26 PM, Perrin Harkins wrote: > On Wed, Oct 10, 2012 at 3:57 PM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote: >>> reasons to pick a mod_perl approach over a plack runner approach >> Requires no proxying. > > Isn't Starman normally run with a proxy in front of it? If not, it > should be. Otherwise, you'd be tying up large processes sending bytes > to slow remote clients, just like you would with a standard mod_perl > app. I think Lars meant no proxy required with *mod_perl* rather than plack stuff, but yes, Starman is recommended to put behind proxy otherwise your precious worker process is bound to slow networked clients, and gets even worse if you run Starman with keepalive support (which you can turn off with the options). -- Tatsuhiko Miyagawa
Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?
On Fri, Oct 12, 2012 at 11:59 AM, Fred Moyer wrote: > > - A stable history of distribution packaging. Odds are the platform > you are using has mod_perl / Apache rpms/deb/ebuilds/etc for quite > some time. These days more developers want to build (and even deploy) their own perl using tools such as perlbrew, not the one that comes with the distribution, and building perl _and_ mod_perl is certainly doable as mentioned elsewhere in this thread, but is a separate step that's not required in most PSGI perl-based server setup. > - Knowledge that mod_perl has been proven in large scale deployments. > The biggest I've worked on is about 500 servers if I recall correctly. PSGI based deployment has been used and deployed in many online services, small to large, personal to enterprise to PaaS, such as: DeNA/ngmoco, livedoor, NHN, BBC, mixi, Booking, Stackato, dotcloud, just to name a few (that I know). Also: search.cpan.org and metacpan.org both run on top of PSGI (Starman and Twiggy), so does cpanmetadb.plackperl.org, the backend of cpanminus - although it serves about millions of requests per day, it isn't considered a large scale deployment since it runs as one process on one server :) -- Tatsuhiko Miyagawa
AW: Coupling Plack/PSGI with mod_perl, or an alternate architecture?
Hi Tatsuhiko, which proxy do you use in front? Best regards McA -Ursprüngliche Nachricht- Von: Tatsuhiko Miyagawa [mailto:miyag...@gmail.com] Gesendet: Sonntag, 14. Oktober 2012 20:57 An: modperl@perl.apache.org Betreff: Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture? On Fri, Oct 12, 2012 at 11:59 AM, Fred Moyer wrote: > > - A stable history of distribution packaging. Odds are the platform > you are using has mod_perl / Apache rpms/deb/ebuilds/etc for quite > some time. These days more developers want to build (and even deploy) their own perl using tools such as perlbrew, not the one that comes with the distribution, and building perl _and_ mod_perl is certainly doable as mentioned elsewhere in this thread, but is a separate step that's not required in most PSGI perl-based server setup. > - Knowledge that mod_perl has been proven in large scale deployments. > The biggest I've worked on is about 500 servers if I recall correctly. PSGI based deployment has been used and deployed in many online services, small to large, personal to enterprise to PaaS, such as: DeNA/ngmoco, livedoor, NHN, BBC, mixi, Booking, Stackato, dotcloud, just to name a few (that I know). Also: search.cpan.org and metacpan.org both run on top of PSGI (Starman and Twiggy), so does cpanmetadb.plackperl.org, the backend of cpanminus - although it serves about millions of requests per day, it isn't considered a large scale deployment since it runs as one process on one server :) -- Tatsuhiko Miyagawa
Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?
i would use nginx but lighttpd or apache (mod_proxy), squid, varnish, anything would do. On Sun, Oct 14, 2012 at 12:31 PM, Andreas Mock wrote: > Hi Tatsuhiko, > > which proxy do you use in front? > > Best regards > McA > > > -Ursprüngliche Nachricht- > Von: Tatsuhiko Miyagawa [mailto:miyag...@gmail.com] > Gesendet: Sonntag, 14. Oktober 2012 20:57 > An: modperl@perl.apache.org > Betreff: Re: Coupling Plack/PSGI with mod_perl, or an alternate > architecture? > > On Fri, Oct 12, 2012 at 11:59 AM, Fred Moyer wrote: >> >> - A stable history of distribution packaging. Odds are the platform >> you are using has mod_perl / Apache rpms/deb/ebuilds/etc for quite >> some time. > > These days more developers want to build (and even deploy) their own perl > using tools such as perlbrew, not the one that comes with the distribution, > and building perl _and_ mod_perl is certainly doable as mentioned elsewhere > in this thread, but is a separate step that's not required in most PSGI > perl-based server setup. > >> - Knowledge that mod_perl has been proven in large scale deployments. >> The biggest I've worked on is about 500 servers if I recall correctly. > > PSGI based deployment has been used and deployed in many online services, > small to large, personal to enterprise to PaaS, such as: > DeNA/ngmoco, livedoor, NHN, BBC, mixi, Booking, Stackato, dotcloud, just to > name a few (that I know). > > Also: search.cpan.org and metacpan.org both run on top of PSGI (Starman and > Twiggy), so does cpanmetadb.plackperl.org, the backend of cpanminus - > although it serves about millions of requests per day, it isn't considered a > large scale deployment since it runs as one process on one server :) > > > > -- > Tatsuhiko Miyagawa > -- Tatsuhiko Miyagawa
Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?
On Sun, Oct 14, 2012 at 2:56 PM, Tatsuhiko Miyagawa wrote: > I think Lars meant no proxy required with *mod_perl* rather than plack > stuff, but yes, Starman is recommended to put behind proxy otherwise > your precious worker process is bound to slow networked clients, and > gets even worse if you run Starman with keepalive support (which you > can turn off with the options). I would just add that a proxy is always recommended in front of mod_perl for the same reasons. It also cuts down on the number of DBI handles you have open if you're using persistent connections. - Perrin
