Re: How do you use mod_perl for your web application?
We are using Mason 1.x, a (little) modified version of MasonX::WebApp together with Apache2 and mod_perl2 running behind a lightweight Apache as frontend-server. We use mod_perl for Mason and Apache2::UploadProgress , no other mod_perl handlers. Session management is done with MasonX::WebApp and Apache::Session::Wrapper. I've been playing around with Mason2, Plack, Catalyst and Dancer, where I liked the easier data passing to my templates than with MasonX::WebApp in Catalyst, which leads to a stricter separation from HTML and Perl code. Yet I haven't made any tests with file uploading in combination with a progress-meter on the client side and some other aspects that are important for us, so there is no decision yet, if we will using Apache and mod_perl for this or switch to a PSGI Server or even nginx. The current standing is to switch to Catalyst with Mason2, but this is a long way to go. There is one point that I would like to see in mod_perl that would help me a lot: Currently, I can use on Perl instance in all virtual hosts or add a separate instance with +Parent for a virtual host. Yet , if I have some virtual hosts running with version A , some with Version B, some with Version C I have to add +Parent for each vhost and I,m running out of memory. So , I would like to make instance pools one for each version , and tell each vhost just, which pool to use. So, memory usage is a con for mod_perl, or in other words , if I would found a PSGI based solution which allows something like this this would be an argument for me to switch! Rolf Schaufelberger
Re: How do you use mod_perl for your web application?
We use mp2 + httpd in prefork mode to translate between JSON/SOAP to proprietary CORBA (via opalORB - the 100% painless CORBA interface) on dedicated servers . We've run 100's of requests a second through a single server. So long as httpd is configured sensibly the performance is excellent. A word too on stability. One installation has been chugging away for about 4 years now without a single defect report. I also use it for internal testing - using virtual hosts to serve a proprietary in-house socket protocol, which is then reconstituted inside perl. The advantage of this is that I can use Apache::Test to drive the tests. So far the need for frameworks of any sort has not arisen. The ones I have played with, Mason,Catalyst,Gantry, Dancer are all very capable. Probably it is due to the limited use I've put them to but I tend to find that Text::Perlate (or even just some quick and dirty regex-based text mutations), and maybe a bit of javascript gets me there quicker than the frameworks. That said - I have an uncomfortable suspicion that sophisticated technology leads to sophisticated solutions, whether the problems at hand deserve such sophistication or not. Just to reinforce Randolf's enthusiasm - mod_perl is fantastic. Combined with httpd's remarkable flexibility and stability I can't see why we don't brainwash our children into using it as soon as they can hit a keyboard.
Re: How do you use mod_perl for your web application?
On Mon, Jun 20, 2011 at 11:00 PM, Randolf Richardson rand...@modperl.pl wrote: I have encountered some people (not just in the DBIx::Class community) who have told me things like you should be using FastCGI instead, or you're crazy to not run mod_perl behind a proxy, etc. Well, this is a sidetrack, but the proxy advice is just about separating the processes delivering bytes to browsers from the ones doing the perl work. Proxies are not the only way to achieve it, but the general concept is sound. It cuts down on the number of processes needed to server a given number of clients. One argument that I see come up a lot is it hasn't been updated in years as if regular updates are an important measurement. Besides the pointlessness of this criticism, it's also not true. There have been recent updates to mod_perl, httpd, and perl. I doubt that mod_fastcgi is getting a lot more updates, and I doubt that the alternative servers for FastCGI or PSGI are getting a lot more updates than the combined total of httpd (which is mod_perl's server) and its modules. When you use mod_perl, you get a huge number of people maintaining and testing all the components that come together in the form of apache modules like mod_deflate and mod_ssl. You'll always get better performance from straight DBI than from ORMs like DBIx::Class or Rose::DB::Object. They just save you some repetitive code for simple things. Yes, but I'm wondering if the caching being shut off in the ORM might be a major contributing factor as well because the difference is very noticeable (plus, for certain things I see a lot of extra SQL queries in the logs when I'm using the ORM), although it also wasn't performing poorly before switching to DBI (which I think is an excellent testimonial for mod_perl2's performance). ORMs just can't be as intelligent about which data to retrieve as custom code can. SQL is too powerful a tool to be fully captured in the limited APIs they have. They are very useful for cutting down on boilerplate code though. - Perrin
Re: How do you use mod_perl for your web application?
On Tue, Jun 21, 2011 at 2:25 AM, Rolf Schaufelberger r...@plusw.de wrote: We are using Mason 1.x, a (little) modified version of MasonX::WebApp Us too! Glad to know someone else is using it. Currently, I can use on Perl instance in all virtual hosts or add a separate instance with +Parent for a virtual host. Yet , if I have some virtual hosts running with version A , some with Version B, some with Version C I have to add +Parent for each vhost and I,m running out of memory. So , I would like to make instance pools one for each version , and tell each vhost just, which pool to use. My approach to this problem would be to run separate httpd servers for each version of the code you need to support and use a proxy in front to do the dispatching. - Perrin
Re: apache2 or mod_perl2 oddball error
According to Perrin Harkins per...@elem.com on Tue, 06/21/11 at 11:57: Maybe I'm the one confused now, but I thought you said that when you removed that the application started and those errors about the modules went away. You said that instead you got errors about unreferenced scalar stuff when apache shut down. Have you checked to see if the application works at that point? I may have mis-spoken. A lot of different tests and hair pulling here... When the -compile parameters are removed, I get this: Syntax OK. Attempt to free unreferenced scalar: SV 0x28be1014 during global destruction. Attempt to free unreferenced scalar: SV 0x28bda578 during global destruction. Attempt to free unreferenced scalar: SV 0x28bda7d0 during global destruction. Attempt to free unreferenced scalar: SV 0x28d1b3e8 during global destruction. Attempt to free unreferenced scalar: SV 0x28d1b050 during global destruction. Attempt to free unreferenced scalar: SV 0x28bda730 during global destruction. Attempt to free unreferenced scalar: SV 0x28bda4b0 during global destruction. Attempt to free unreferenced scalar: SV 0x28d1b3d4 during global destruction. Attempt to free unreferenced scalar: SV 0x28be176c during global destruction. Attempt to free unreferenced scalar: SV 0x28bda6cc during global destruction. Attempt to free unreferenced scalar: SV 0x28be15dc during global destruction. and the server does not start. I am becoming more and more convinced that I will have to revert to 5.12.3 version of Perl... Regards, web... -- William Bulley Email: w...@umich.edu 72 characters width template -|
Re: How do you use mod_perl for your web application?
On Thu, 16 Jun 2011 06:01:03 +0200, Fred Moyer f...@redhotpenguin.com wrote: I'm interested in hearing about what application frameworks (Catalyst, CGI::App, Mojolicious) are used here with mod_perl. A bit late to the party. In Opera we have lots of systems running modperl 2, ranging from 1 server to moderately large and critical apps. For the most part we use an in-house framework started many years ago. Recently we have seen two friendly factions struggling for power :), one moving towards Catalyst/DBIx/TT2 and another testing Plack/PSGI. Latest new project I deployed in production is a psgi single sign on server that uses Plack::Handler::Apache2. ... emerging Perl based webservers on CPAN Yes, very interesting. I'm planning to compare raw modperl 2, Plack::Handler::Apache2 and starman for the same application and extract some performance data. Performance of mod_perl2 has never been an issue to date Yeah, also wrt stability. For medium and large scale systems we usually deploy frontends as reverse proxies using any of apache, nginx, varnish, perlbal or pound. -- Cosimo
Re: apache2 or mod_perl2 oddball error
According to Andr? Warnier a...@ice-sa.com on Tue, 06/21/11 at 12:05: Right, but what that page is showing, is the syntax of the perl use some::module; directive, as used /inside of a perl program/. Here we are talking about the PerlModule directive, as used in a httpd.conf file (or another file included in it). I got that. Although the effect of each of these instructions is quite similar, the allowable syntax in each case may be different. Referring again to the page http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlModule_ One sees there an example of a PerlModule directive with several parameters after the PerlModule directive itself. But these additional parameters are, all and each of them, names of perl modules (aka libraries) to be loaded. They are /not/ additional parameters to the first named module. Damn, this is probably obscure for a non-perl practitioner. Let me try again : in a line like use Apache2::Const -compile = ':common'; (which you would use in a perl script, not in an Apache configuration file) - the use Apache2::Const part means : load the module Apache2::Const - and the -compile = ':common' part means : /in addition/ to loading the Apache2::Const module itself, also prepare a set of symbols from that module, so as to make them easier to use in the program which executes the use directive. (*) I think the person who wrote these lines: PerlModule Apache2::Const -compile = ':common' PerlModule APR::Const -compile = ':common' was trying to say: I'm only interested in those symbols associated with the ':common' tag, so please load only those (in addition to the module). But this is neither here nor there, since when I reduce those two lines to: PerlModule Apache2::Const PerlModule APR::Const and re-run # apachectl -t the syntax is clean, but the server fails to start (which was my original complaint): Syntax OK Attempt to free unreferenced scalar: SV 0x28be1014 during global destruction. Attempt to free unreferenced scalar: SV 0x28bda578 during global destruction. Attempt to free unreferenced scalar: SV 0x28bda7d0 during global destruction. Attempt to free unreferenced scalar: SV 0x28d1b3e8 during global destruction. Attempt to free unreferenced scalar: SV 0x28d1b050 during global destruction. Attempt to free unreferenced scalar: SV 0x28bda730 during global destruction. Attempt to free unreferenced scalar: SV 0x28bda4b0 during global destruction. Attempt to free unreferenced scalar: SV 0x28d1b3d4 during global destruction. Attempt to free unreferenced scalar: SV 0x28be176c during global destruction. Attempt to free unreferenced scalar: SV 0x28bda6cc during global destruction. Attempt to free unreferenced scalar: SV 0x28be15dc during global destruction. On the other hand, in an Apache configuration file, you cannot use the use directive, you must use the PerlModule directive. But this PerlModule directive has no valid syntax to allow the second part (-compile = ':common'). Ok so far ? I got that. So how would you find a way to tell Apache and mod_perl to load the Apache2::Const module, but /also/ do the -compile = ':common' part ? Fortunately, in Perl there is always more than one way to do it. That's where the already-named startup.pl script comes into play, along with the PerlRequire directive. The include file in question has a Perl.../Perl section. So I tried putting the use...-common = ':common' inside there (two lines). Then running the apachectl(8) command, I got the same results as above. Still no joy. I got farther along just by renaming the include file so that apache2 could not see it (but of course this screws the pooch for the application in question). After the renaming, # apachectl start succeeded. By using the Apache/mod_perl configuration directive PerlRequire /path/to/some/script.pl you tell Apache and mod_perl to also compile and run the named script, /during the Apache configuration phase/. And in this script, you can use the line : use Apache2::Const -compile = ':common'; (because in a Perl script the use directive /can/ be used, with the additional parameters and all). See above. (Note: the name of this script is often startup.pl, but that is only a convention, and you can use any script name you like, as long as the PerlRequire directive points to it). I do this for Perl applications that I write. (Note also that it does not matter that the rest of the application never references this script; it is executed /once/ during the configuration phase of Apache, and just sets things up for the rest of the life of this Apache/mod_perl server). I got that. In other words, to summarise (and this is only a repeat of what someone else wrote earlier), do as follows : - create a simple perl script, for example as /etc/apache2/mod_perl_startup.pl, as Fred Moyer told you how to in a reply dated 17/06 22:22. - remove the corresponding PerlModule
RE: apache2 or mod_perl2 oddball error
Getting back to basics... Are you sure that your build of Apache and perl went well? Have you scrutinized the logs you created when you built perl and apache for any surprising error messages? -James -Original Message- From: William Bulley [mailto:w...@umich.edu] Sent: Tuesday, June 21, 2011 12:51 PM To: Andr? Warnier Cc: mod_perl list Subject: Re: apache2 or mod_perl2 oddball error According to Andr? Warnier a...@ice-sa.com on Tue, 06/21/11 at 12:05: Right, but what that page is showing, is the syntax of the perl use some::module; directive, as used /inside of a perl program/. Here we are talking about the PerlModule directive, as used in a httpd.conf file (or another file included in it). I got that. Although the effect of each of these instructions is quite similar, the allowable syntax in each case may be different. Referring again to the page http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlModule_ One sees there an example of a PerlModule directive with several parameters after the PerlModule directive itself. But these additional parameters are, all and each of them, names of perl modules (aka libraries) to be loaded. They are /not/ additional parameters to the first named module. Damn, this is probably obscure for a non-perl practitioner. Let me try again : in a line like use Apache2::Const -compile = ':common'; (which you would use in a perl script, not in an Apache configuration file) - the use Apache2::Const part means : load the module Apache2::Const - and the -compile = ':common' part means : /in addition/ to loading the Apache2::Const module itself, also prepare a set of symbols from that module, so as to make them easier to use in the program which executes the use directive. (*) I think the person who wrote these lines: PerlModule Apache2::Const -compile = ':common' PerlModule APR::Const -compile = ':common' was trying to say: I'm only interested in those symbols associated with the ':common' tag, so please load only those (in addition to the module). But this is neither here nor there, since when I reduce those two lines to: PerlModule Apache2::Const PerlModule APR::Const and re-run # apachectl -t the syntax is clean, but the server fails to start (which was my original complaint): Syntax OK Attempt to free unreferenced scalar: SV 0x28be1014 during global destruction. Attempt to free unreferenced scalar: SV 0x28bda578 during global destruction. Attempt to free unreferenced scalar: SV 0x28bda7d0 during global destruction. Attempt to free unreferenced scalar: SV 0x28d1b3e8 during global destruction. Attempt to free unreferenced scalar: SV 0x28d1b050 during global destruction. Attempt to free unreferenced scalar: SV 0x28bda730 during global destruction. Attempt to free unreferenced scalar: SV 0x28bda4b0 during global destruction. Attempt to free unreferenced scalar: SV 0x28d1b3d4 during global destruction. Attempt to free unreferenced scalar: SV 0x28be176c during global destruction. Attempt to free unreferenced scalar: SV 0x28bda6cc during global destruction. Attempt to free unreferenced scalar: SV 0x28be15dc during global destruction. On the other hand, in an Apache configuration file, you cannot use the use directive, you must use the PerlModule directive. But this PerlModule directive has no valid syntax to allow the second part (-compile = ':common'). Ok so far ? I got that. So how would you find a way to tell Apache and mod_perl to load the Apache2::Const module, but /also/ do the -compile = ':common' part ? Fortunately, in Perl there is always more than one way to do it. That's where the already-named startup.pl script comes into play, along with the PerlRequire directive. The include file in question has a Perl.../Perl section. So I tried putting the use...-common = ':common' inside there (two lines). Then running the apachectl(8) command, I got the same results as above. Still no joy. I got farther along just by renaming the include file so that apache2 could not see it (but of course this screws the pooch for the application in question). After the renaming, # apachectl start succeeded. By using the Apache/mod_perl configuration directive PerlRequire /path/to/some/script.pl you tell Apache and mod_perl to also compile and run the named script, /during the Apache configuration phase/. And in this script, you can use the line : use Apache2::Const -compile = ':common'; (because in a Perl script the use directive /can/ be used, with the additional parameters and all). See above. (Note: the name of this script is often startup.pl, but that is only a convention, and you can use any script name you like, as long as the PerlRequire directive points to it). I do this for Perl applications that I write. (Note also that it does not matter that the rest of the application never references this script; it is executed /once/ during the configuration phase of Apache, and just sets things up
Re: How do you use mod_perl for your web application?
On Jun 21, 2011, at 9:33 AM, Cosimo Streppone wrote: Recently we have seen two friendly factions struggling for power :), one moving towards Catalyst/DBIx/TT2 and another testing Plack/PSGI. To be clear, these two factions are orthogonal. FWIW, Catalyst is being updated to run on Plack. Best, David
