Re: Perl in shared hosting environments
On Thu, Sep 22, 2011 at 05:18:52PM -0700, Tatsuhiko Miyagawa wrote: > http://www.reddit.com/r/perl/comments/h6qqr/the_psgi_is_the_limit/ has > an amusing comment thread about the performance and benefit of PSGI > over existing wrappers like CGI.pm, started by "shi4" - you might need > to click the thread to collapse to read the whole thread. I read that, and while shi4 got a lot of downvotes and kinda looks like he's arguing for argument's sake, this was excellent. His questions really dig into what you can do with PSGI w/wo Plack... instead of letting it get buried into reddit history, it ought to get copied somewhere that talks about Plack/PSGI since it answers so much. This guy was apparently willing to take downvotes to push his initial view that he didn't see how all this was in any way better than CGI.pm etc. Surely there are dozens of others who thought the same but wouldn't post. At least, I can see in the later posts where the guy really learned something, and had had some misconceptions cleared up. -Mallory
Re: Perl in shared hosting environments
On Wed, Sep 21, 2011 at 8:49 AM, Randal L. Schwartz wrote: >> "Dirk" == Dirk Koopman writes: > > > Dirk> Reason include: > > You forgot: > > * My application only requires content generation, and I can completely > ignore the other 14 phases of serving, because I don't want custom > redirects, authentication, authorization, mime interpretation, and/or > logging and other things written in the language of my choice: Perl. This is where PSGI stands out. If you write a couple of mod_perl handlers that work on these 14 phases of serving, then it will *only* work with mod_perl, putting aside the fact that mod_perl1 handlers won't work with mod_perl 2. If you write PSGI middleware that does URL rewrites, authentication, authorization, custom redirects, logging etc. as PSGI middleware, then you can use that with ANY of PSGI supported web servers (Starman, mod_perl, FastCGI etc.) and ANY of PSGI supported frameworks (Catalyst, Dancer, Mojolicious etc.) You can see the examples of middleware by searching on CPAN: https://metacpan.org/search?q=plack%3A%3Amiddleware > Seriously... *nothing* can compete with mod_perl as far as its reach > into Apache. *Nothing*. With mod_perl, you can inject new behavior at > every level of decision making that Apache does. FastCGI is replacing > just *one* of those 14 stages. True: you can further its reach into *Apache* and nothing else. -- Tatsuhiko Miyagawa
Re: Perl in shared hosting environments
On Wed, Sep 21, 2011 at 4:04 AM, Dirk Koopman wrote: >> Check out Plack: >> >> http://plackperl.org/ - https://metacpan.org/module/Plack >> >> >> http://blog.plackperl.org/2011/08/plack-basics-for-perl-websites-yapceu-2011.html >> >> Then you can switch between mod_perl / FastCGI / Starman / Twiggy to your >> hearts content (we found Starman is REALLY fast). > > I am happy to be educated, but I found Plack introduced a load of > dependencies that I did not want, Plack is the reference implementation of PSGI handlers and middleware, and it only has a few dependencies that could potentially be already dependent in most cases if you're doing a web development in perl (such as URI and LWP), but that mileage might vary. The nice thing about Plack/PSGI however is that you *decouple* your application code from the runtime environment such as mod_perl and FastCGI - you write your application to target the PSGI interface, then your app will run on any environments that supports PSGI (via Plack handlers) such as mod_perl, FastCGI, Starman etc. with absolutely zero changes. > it *is* another layer which cannot help > but reduce speed - which may not matter - but did to me at the time. Switching to Plack/PSGI actually gives better performance in many cases, particularly because PSGI uses Perl's native data types such as hash reference, array reference instead of objects with hundreds of method calls. Wrapping the interface with a nice OO is the job of framework, not PSGI. It does *not* get in the way. For my simple (and naive) Hello World application testing, Starman, Starlet and Feersum web servers got a better performance than CGI.pm (with mp2 wrapper) + mod_perl, for example. http://www.reddit.com/r/perl/comments/h6qqr/the_psgi_is_the_limit/ has an amusing comment thread about the performance and benefit of PSGI over existing wrappers like CGI.pm, started by "shi4" - you might need to click the thread to collapse to read the whole thread. >> >> You also get a lot (160+ modules) of nice middleware available. >> > > More software to, at least potentially, "get in the way" or add unnecessary > dependencies or unwanted constraints. PSGI interface and middleware works consistent as an interface between the application and servers. It doesn't get in the way. -- Tatsuhiko Miyagawa
Re: Perl in shared hosting environments
Hello. 2011/09/21 12:04:47 +0100 Dirk Koopman => To l...@cuckoo.org : DK> > Then you can switch between mod_perl / FastCGI / Starman / Twiggy to your DK> > hearts content (we found Starman is REALLY fast). DK> DK> I am happy to be educated, but I found Plack introduced a load of DK> dependencies that I did not want, it *is* another layer which cannot DK> help but reduce speed - which may not matter - but did to me at the time. Then you may find FCGI::Spawn https://github.com/petr999/fcgi-spawn/tree/devel -- Peter Vereshagin (http://vereshagin.org) pgp: A0E26627
Re: Perl in shared hosting environments
On 21 Sep 2011, at 16:49, Randal L. Schwartz wrote: You forgot: * My application only requires content generation, and I can completely ignore the other 14 phases of serving, because I don't want custom redirects, authentication, authorization, mime interpretation, and/or logging and other things written in the language of my choice: Perl. Seriously... *nothing* can compete with mod_perl as far as its reach into Apache. *Nothing*. With mod_perl, you can inject new behavior at every level of decision making that Apache does. FastCGI is replacing just *one* of those 14 stages. This is spot on. There are no magic bullets. :) The main advantage of mod_perl is that you can completely mess with apache, at every level (including turning it into an SMTP server, if you so desire). This _is_ useful. The main disadvantage of mod_perl is that people have (ab)used/do (ab)use this a lot for _simple cases_ where you really only want to generate web pages. A pile of blocks dispatching into discrete mod_perl handlers works - but not adding the appropriate abstraction here leads to code that is non-modular, hard to test & debug and generally crappy (everyone has a crawing-horror mod_perl app story or two!) Having the level of separation implied by using fcgi (or proxying, or whatever - generally making your app a .psgi (these days) no matter how you deploy it) is generally massively superior to test and develop on, and very few cases actually want or need the power of mod_perl.. Cheers t0m
Re: Perl in shared hosting environments
On 21/09/11 16:49, Randal L. Schwartz wrote: "Dirk" == Dirk Koopman writes: Dirk> Reason include: You forgot: * My application only requires content generation, and I can completely ignore the other 14 phases of serving, because I don't want custom redirects, authentication, authorization, mime interpretation, and/or logging and other things written in the language of my choice: Perl. Seriously... *nothing* can compete with mod_perl as far as its reach into Apache. *Nothing*. With mod_perl, you can inject new behavior at every level of decision making that Apache does. FastCGI is replacing just *one* of those 14 stages. And these are advantages or reasons to avoid mod_perl? I agree with your last paragraph, but I have to utter a very politely meant, but heartfelt, "so what". Nothing written, so far, would cause me to stop avoiding Apache with every fibre of my being. It is a hateful security_hole^Hprogram and mod_perl is an unfortunate part of that. Also once perl is embedded into any thing and one uses perl extensively within, the speed of the thing will tend toward the speed of the perl part. In the case of a (web)server, these days, one may as well use one of the perl (web)server modules/frameworks and do the whole lot in perl. Maybe using some of the newer XS support modules. All stages of a request are available. It isn't significantly slower than mod_perl (and maybe quicker). The memory requirements seem to stabilise very quickly and are reasonable. I have perl servers of one kind or another that stay up for years at a time even under some aggressive attempts to DoS / exceed limits. The joy of "infinite" buffer sizes and garbage collection. And it's easier to debug (although it would be nice not to have Carp::Heavy crash on errors quite so frequently). Dirk
Re: Perl in shared hosting environments
> "Dirk" == Dirk Koopman writes: Dirk> Reason include: You forgot: * My application only requires content generation, and I can completely ignore the other 14 phases of serving, because I don't want custom redirects, authentication, authorization, mime interpretation, and/or logging and other things written in the language of my choice: Perl. Seriously... *nothing* can compete with mod_perl as far as its reach into Apache. *Nothing*. With mod_perl, you can inject new behavior at every level of decision making that Apache does. FastCGI is replacing just *one* of those 14 stages. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion
Re: Perl in shared hosting environments
On Wed, Sep 21, 2011 at 11:21:06AM +0100, Dirk Koopman wrote: > * mod_perl processes seem(ed) to get bigger and bigger and need(ed) > to be killed every few 10s of requests to keep memory usage in > bounds. We needed many more (bigger) machines to run mod_perl v > other webservers and FastCGI. This is why I stopped using mod_perl for CPANdeps. By leaving no memory for anything else, it actually made things slower than CGI. -- David Cantrell | even more awesome than a panda-fur coat [OS X] appeals to me as a monk, a user, a compiler-of-apps, a sometime coder, and an easily amused primate with a penchant for those that are pretty, colorful, and make nice noises. -- Dan Birchall, in The Monastery
Re: Perl in shared hosting environments
On 21/09/11 11:38, Leo Lapworth wrote: On 21 September 2011 11:21, Dirk Koopman wrote: For what it is worth, I stopped using mod_perl (as well as Apache) several years ago and moved onto other webservers and FastCGI. As long as your not completely integrated to mod_perl hooks, e.g. your mostly using it for precompile speed up... Check out Plack: http://plackperl.org/ - https://metacpan.org/module/Plack http://blog.plackperl.org/2011/08/plack-basics-for-perl-websites-yapceu-2011.html Then you can switch between mod_perl / FastCGI / Starman / Twiggy to your hearts content (we found Starman is REALLY fast). I am happy to be educated, but I found Plack introduced a load of dependencies that I did not want, it *is* another layer which cannot help but reduce speed - which may not matter - but did to me at the time. You also get a lot (160+ modules) of nice middleware available. More software to, at least potentially, "get in the way" or add unnecessary dependencies or unwanted constraints. But I will look at it again soon. Dirk
Re: Perl in shared hosting environments
On 21 September 2011 11:21, Dirk Koopman wrote: > > For what it is worth, I stopped using mod_perl (as well as Apache) several > years ago and moved onto other webservers and FastCGI. > As long as your not completely integrated to mod_perl hooks, e.g. your mostly using it for precompile speed up... Check out Plack: http://plackperl.org/ - https://metacpan.org/module/Plack http://blog.plackperl.org/2011/08/plack-basics-for-perl-websites-yapceu-2011.html Then you can switch between mod_perl / FastCGI / Starman / Twiggy to your hearts content (we found Starman is REALLY fast). You also get a lot (160+ modules) of nice middleware available. Welcome to the future :) Leo
Re: Perl in shared hosting environments
On 21/09/11 09:55, Tomas Doran wrote: On 21 Sep 2011, at 09:22, Philip Newton wrote: And I agree with Lesley in assuming the answer is "no" - I doubt that you can modify Apache that way to "inject" a module into it from your section of a shared hosting environment. Oh, yes, of course! Your perl script isn't going to be able to extend apache without apache collaborating in this :) For what it is worth, I stopped using mod_perl (as well as Apache) several years ago and moved onto other webservers and FastCGI. Reason include: * Apache seems to be the sendmail of the webserving world. Does anybody other than me note the frequency of critical bugs, ongoing, that Apache has? * Other webservers can be run, more easily, on non-privileged ports and users, chrooted etc etc to reduce the attack surface even more (obviously one redirects traffic from port 80 etc either via the operating system or load balancers). * Stuff has to be "stitched into" mod_perl. This is unnecessarily tedious -> difficult and probably increases the attack surface as well. * Added (completely) new stuff into the same mod_perl environment is next to impossible (i.e. forget "shared hosting"). * mod_perl processes seem(ed) to get bigger and bigger and need(ed) to be killed every few 10s of requests to keep memory usage in bounds. We needed many more (bigger) machines to run mod_perl v other webservers and FastCGI. * Stuff designed with FastCGI in mind is much easier to test and debug. * FastCGI does not have to be on the same machine as the webserver, nor even on the same architecture. * The difference in speed between mod_perl and an established FastCGI set of processes is minimal. In some cases I have found FastCGI faster than mod_perl. * Other webservers can be run, more easily, on non-privileged ports and users, chrooted etc etc to reduce the attack surface even more (obviously one redirects traffic from port 80 etc either via the operating system or load balancers). I may simply be biased, but it is based on bitter (but now old) experience. YMMV (and probably does) Dirk
Re: Perl in shared hosting environments
On 21 Sep 2011, at 09:22, Philip Newton wrote: And I agree with Lesley in assuming the answer is "no" - I doubt that you can modify Apache that way to "inject" a module into it from your section of a shared hosting environment. Oh, yes, of course! Your perl script isn't going to be able to extend apache without apache collaborating in this :) Cheers t0m
Re: Perl in shared hosting environments
On Wed, Sep 21, 2011 at 09:28, Tomas Doran wrote:
>
> On 21 Sep 2011, at 07:51, lesleyb wrote:
>>
>> I'm just left wondering how far one could exploit this? I'm guessing
>> mod_perl
>> would still be out of the question. And probably mod_fcgi.
>
> Taking fastcgi first - fastcgi just runs a perl script, so there is nothing
> stopping the first line of your script being BEGIN { push(@INC
[snip]
> Nothing in this stops the technique from working in mod-perl per-se
I interpreted the "how far one could exploit this... mod_perl,
mod_fcgi" to mean, "This technique makes it possible to use modules
that aren't installed globally on the shared hosting environment.
Would it be possible to make use of mod_perl even though that's not
installed globally on the shared hosting environment? What about
mod_fcgi?"
And I agree with Lesley in assuming the answer is "no" - I doubt that
you can modify Apache that way to "inject" a module into it from your
section of a shared hosting environment.
Cheers,
Philip
--
Philip Newton
Re: Perl in shared hosting environments
On 21 Sep 2011, at 07:51, lesleyb wrote:
The end effect is to prepend the directories in @INC with the
directory
$b__dir, which may or may not be the user's home directory, pushing
two new
ones on the front of @INC and including the original @INC as the
last set of
directories to be searched for modules etc.
I'm just left wondering how far one could exploit this? I'm
guessing mod_perl
would still be out of the question. And probably mod_fcgi.
No, also no?
Taking fastcgi first - fastcgi just runs a perl script, so there is
nothing stopping the first line of your script being BEGIN
{ push(@INC
And as each fastcgi app has it's own perl interpreter and etc, then
this technique works well..
mod_perl is a less simple case, as often (although not necessarily)
the perl interpreter is shared by the entire apache instance, ergo you
can only have one version of each module loaded.
Nothing in this stops the technique from working in mod-perl per-se,
however it's likely that perl modules will have been pre-loaded before
your code is ever called, or alternatively if you override module
loading and load newer versions of things and some other site is
relying on the (older) system versions of a module, then you could
wreck things for them.
So someone using such a script would still be restricted to CGI but
able to
install modules they wish to use?
See local::lib for a less gross (or at least more standard) solution?
Cheers
t0m
