Re: How do you use mod_perl for your web application?
On 6/15/2011 9:01 PM, Fred Moyer wrote: I'm interested in hearing about what application frameworks (Catalyst, CGI::App, Mojolicious) are used here with mod_perl. Given the number of emerging Perl based webservers on CPAN (in addition to Nginx, lighty, etc), it seems like there are many more Perl web application and webservers out there now than there were five years ago. One-page app. using Ajax/JSON. Server side is mod_perl 2.x, Apache (configured variously for proxy, static content and mod_perl) and MySQL. Code is OO and uses persistent objects. No frameworks or much use of CPAN modules other than DBI. Cient interface is assembled entirely on client, using JavaScript and DOM. This frees up server from having to do any interface generation. Regardless of request type (POST/GET etc), the server response is in the form of JavaScript object(s) (really just a plain text string), which is 'eval'ed by JavaScript on the client.
Re: How do you use mod_perl for your web application?
On 2 Jul 2011, at 08:38, Max Kanat-Alexander wrote: > (which is why I frequently talk/ask > about SizeLimit on this list) And I will frequently say that this is the Wrong Answer. MaxClients and a proxy on the front is more often the right answer. A fat Apache is an application server, treat it as such.
Re: How do you use mod_perl for your web application?
On 06/15/2011 09:01 PM, Fred Moyer wrote: > I'm interested in hearing about what application frameworks (Catalyst, > CGI::App, Mojolicious) are used here with mod_perl. Given the number > of emerging Perl based webservers on CPAN (in addition to Nginx, > lighty, etc), it seems like there are many more Perl web application > and webservers out there now than there were five years ago. There are probably several thousand installations of our application running under mod_perl. (We guess that there are roughly 10,000 installations of Bugzilla, some large number of which are running under mod_perl.) We don't really have a web framework (unless you count CGI.pm, which I don't), we just have a bunch of raw CGI files. The application dates originally from 1998 and is developed on an entirely volunteer basis, so we have a legacy from that era. The exact same code also runs under mod_cgi for users who have trouble installing mod_perl (or want to run multiple installations on one machine with different code). We require only mod_perl 1.999022, but nowadays also require Apache2::SizeLimit 0.93, which may raise the effective minimum mod_perl requirement. The performance and configuration ease of mod_perl have been generally excellent for us--our only serious problems have been with people having their servers' memory exhausted (which is why I frequently talk/ask about SizeLimit on this list) and the occasional problem with a CPAN module that doesn't work right in mod_perl. -Max -- Max Kanat-Alexander Chief Architect, Community Lead, and Release Manager Bugzilla Project http://www.bugzilla.org/
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
On Jun 27, 2011, at 4:20 PM, Dave Morgan wrote: > What's the point of it? First of all, what Perrin said. :-) > As far as I can see the author claims to have issues with Apache::DBI and > does not > like the hidden aspect. FWIW, I am the author. > I have never experienced his "issues" and the hidden > aspect is the good part. Apache::DBI can be deployed by an admin without > consulting the developers, without affecting their code. It does not require > any "use" statements in the source code. Yeah, too magical. I removed support for it in Bricolage years ago, though I can't remember the details of why anymore. connect_cached() worked much better for me (though it's kind of a PITA to set up). > He claims that it does no caching across threads. Why not? If the thread uses > the same connection/session state then why not use a cached connection. If > it doesn't then it is the developers responsibility. Most database handles are not thread-safe. > Transaction management: I cannot see the point of it, however, I can see the > utility to others. My personal viewpoint is that a > if good commit, else rollback > make what's happening explicit which when dealing with a db is extremely > useful. Yeah, that interface is a convenience. I think it's much nicer to scope things within a subref. > Mind you I believe AutoCommit is a bad thing and should never have been made. I don't think AutoCommit was a mistake. These days I always connect with AutoConnect explicitly set to true, as otherwise I might have a transaction running for a long time until the first connection comes in. > My shop also use stored procs for almost everything. Wish DBD::Pg would let > me read cursors, like DBD::Oracle, that's what I really need. I don't understand. PostgreSQL supports cursors, and you can read from them using FETCH. http://www.postgresql.org/docs/current/static/sql-fetch.html Might be my lack of knowledge of Oracle at work here, though. > I suppose it is all a matter of personal preference but I have found that the > further removed the developer is from the database the worse they are at > accessing > it. DBIx::Class is the perfect example. Please spare me the hassle of trying > to debug/explain/improve any code that uses that. I am sure that high quality > code can be written using DBIx::Class but I have yet to see it. Yes, I'm not a fan of ORMs because they tend to create bad queries, among other things. This is why DBIx::Connector is much more focused on adding interfaces to a connection, and not to querying the database. > Oops, just realized you are the author :). :-) > Please don't take anything above > personally, I just think that if you wanted transaction management, it would > have been better to write a module that just does that and nothing else. > Then, if a developer in my shop wanted to use it I could load it without > having to worry about apache managing two connection pools. Well, DBIx::Connector does not do connection pooling (or caching), so that wouldn't be a problem. > IMHO, worth exactly what you paid for it I paid quite a lot of it in terms of my time to develop the interface. So I'm rather fond of it. Varying opinions of course welcome. Best, David
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
Please calm down, folks. Apache::DBI is a module that was designed to help with porting legacy CGI applications to mod_perl. It's a valid criticism to say that the action-at-a-distance parts of it are undesirable in new mod_perl applications. Personally, I have used mostly custom caching code instead for years. Over time, Apache::DBI picked up some other features which are useful in mod_perl. If you're using something else, you should make sure you have these or know why you don't need them. - Startup safety. This prevents sharing of connections opened in the parent process during startup. Apache::DBI does this by not caching connections during startup. DBIx::Class does this by making a new connection if you fork or start a new thread. Note the stuff about InactiveDestroy in the DBI docs if you use DBIx::Class or DBIx::Connector. - Automatic rollback. Apache::DBI issues a rollback at the end of every request where the DBI connection was not opened in AutoCommit mode. This is to prevent a die() during a transaction from leaving your database in a bad state. If you use subroutine blocks wrapped in eval (e.g. the transaction stuff in DBIx::Connector), this should not be necessary, but make sure you ALWAYS do it that way if you're counting on that to protect you. I agree that trashing Apache::DBI is not very useful, but you should also know what Apache::DBI was meant for and what it's limitations are. - Perrin
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
On 27/06/11 04:27 PM, David E. Wheeler wrote: On Jun 27, 2011, at 1:40 PM, Dave Morgan wrote: You lost me. But really, I strongly recommend against the use of Apache::DBI. Some discussion here: http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description And having read that, I strongly recommend against the use of DBIx-Connector. But then I'm just a production DBA :) Me too. What weaknesses do you see in it? What's the point of it? As far as I can see the author claims to have issues with Apache::DBI and does not like the hidden aspect. I have never experienced his "issues" and the hidden aspect is the good part. Apache::DBI can be deployed by an admin without consulting the developers, without affecting their code. It does not require any "use" statements in the source code. He claims that it does no caching across threads. Why not? If the thread uses the same connection/session state then why not use a cached connection. If it doesn't then it is the developers responsibility. Transaction management: I cannot see the point of it, however, I can see the utility to others. My personal viewpoint is that a if good commit, else rollback make what's happening explicit which when dealing with a db is extremely useful. Mind you I believe AutoCommit is a bad thing and should never have been made. My shop also use stored procs for almost everything. Wish DBD::Pg would let me read cursors, like DBD::Oracle, that's what I really need. I suppose it is all a matter of personal preference but I have found that the further removed the developer is from the database the worse they are at accessing it. DBIx::Class is the perfect example. Please spare me the hassle of trying to debug/explain/improve any code that uses that. I am sure that high quality code can be written using DBIx::Class but I have yet to see it. Oops, just realized you are the author :). Please don't take anything above personally, I just think that if you wanted transaction management, it would have been better to write a module that just does that and nothing else. Then, if a developer in my shop wanted to use it I could load it without having to worry about apache managing two connection pools. IMHO, worth exactly what you paid for it Dave Best, David -- Dave Morgan Operations Manager, BorealEscapes http://www.borealescapes.ca dave.mor...@borealescapes.ca 403 288 8759
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
On Jun 27, 2011, at 2:17 PM, Fred Moyer wrote: >> You lost me. But really, I strongly recommend against the use of >> Apache::DBI. Some discussion here: >> http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description > > It seems like you are looking for a more feature rich db connection > caching module as opposed to a drop in module for mod_perl. For most > mod_perl users, Apache::DBI provides a performance improvement with Pg > and Oracle for just a few lines in your startup.pl. No. DBIx::Connector doesn't do caching at all. That's the point, really. Best, David
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
On Jun 27, 2011, at 1:40 PM, Dave Morgan wrote: >> You lost me. But really, I strongly recommend against the use of >> Apache::DBI. Some discussion here: >> >> >> http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description >> > > And having read that, I strongly recommend against the use of DBIx-Connector. > But then I'm just a production DBA :) Me too. What weaknesses do you see in it? Best, David
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
On Mon, Jun 27, 2011 at 1:22 PM, David E. Wheeler wrote:
> On Jun 27, 2011, at 1:13 PM, Fred Moyer wrote:
>
>> Wow, that's obnoxious:
>>
>> 1237 if ($INC{'Apache/DBI.pm'} && $ENV{MOD_PERL}) {
>> 1238 $old_connect_via = $DBI::connect_via;
>> 1239 $DBI::connect_via = 'connect';
>> 1240 }
>
> DBIx::Connector does the same thing.
I just filed an RT ticket with DBIx::Class for this asking for some
details on why it is necessary. Hoping that they'll be willing to
share some of their technical concerns. I'm not sure why this code
isn't working in my environment, but it could be because I have
Apache::DBI setup differently than they do.
> You lost me. But really, I strongly recommend against the use of Apache::DBI.
> Some discussion here:
> http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
It seems like you are looking for a more feature rich db connection
caching module as opposed to a drop in module for mod_perl. For most
mod_perl users, Apache::DBI provides a performance improvement with Pg
and Oracle for just a few lines in your startup.pl.
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
On 27/06/11 02:22 PM, David E. Wheeler wrote: On Jun 27, 2011, at 1:13 PM, Fred Moyer wrote: Snip . You lost me. But really, I strongly recommend against the use of Apache::DBI. Some discussion here: http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description And having read that, I strongly recommend against the use of DBIx-Connector. But then I'm just a production DBA :) Dave -- Dave Morgan Operations Manager, BorealEscapes http://www.borealescapes.ca dave.mor...@borealescapes.ca 403 288 8759
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
On Jun 27, 2011, at 1:13 PM, Fred Moyer wrote:
> Wow, that's obnoxious:
>
> 1237 if ($INC{'Apache/DBI.pm'} && $ENV{MOD_PERL}) {
> 1238 $old_connect_via = $DBI::connect_via;
> 1239 $DBI::connect_via = 'connect';
> 1240 }
DBIx::Connector does the same thing.
> And it is also apparently not working as they expected:
>
> [Mon Jun 27 13:05:17 2011] [notice] Apache/2.2.17 (Unix)
> mod_apreq2-20090110/2.8.0 mod_perl/2.0.5 Perl/v5.12.3 configured --
> resuming normal operations
> 8879 Apache::DBI new connect to 'dbname='...
>
> In my startup.pl (My::Model is DBIx::Class based):
>
> $Apache::DBI::DEBUG = 2;
> my $db_connect_params = My::Model->connect_params;
> Apache::DBI->connect_on_init( @{$db_connect_params} );
> Apache::DBI->setPingTimeOut( $db_connect_params->[0], 5 );
>
> # delete this line and I will beat you with a stick (note to self)
> My::Model->connect->disconnect;
> $DBI::connect_via = 'Apache::DBI::connect';
You lost me. But really, I strongly recommend against the use of Apache::DBI.
Some discussion here:
http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description
Best,
David
Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
On Mon, Jun 27, 2011 at 12:53 PM, Octavian Rasnita wrote:
> Here is a comment that might be helpful, because it also explains why
> DBIx::Class can work with Apache::DBI (and why it is not needed):
>
> http://lists.scsys.co.uk/pipermail/dbix-class/2006-April/001153.html
>
> ""
> DBIx::Class already manages its connections for you, and therefore it
> cannot benefit from Apache::DBI under any scenario. It makes one
> connection per-process, and keeps that connection persistent,
> reconnecting only if the connection appears to have died, or if you
> fork/thread over to another process/thread-id. The only Apache::DBI
> issue in DBIx::Class is that Apache::DBI will actually thwart
> DBIx::Class's connection management code, and cause it to use the same
> (and invalid) connection in a new process, in cases such as (as
> mentioned above) if you make a DBI connection before forking in a
> prefork mod_perl server.
>
> To work around this, DBIx::Class has specific code in it to work
> around Apache::DBI, nullifying the effects of Apache::DBI on
> DBIx::Class. Essentially, loading Apache::DBI should change nothing
> and be rather pointless under DBIx::Class.
Wow, that's obnoxious:
1237 if ($INC{'Apache/DBI.pm'} && $ENV{MOD_PERL}) {
1238 $old_connect_via = $DBI::connect_via;
1239 $DBI::connect_via = 'connect';
1240 }
And it is also apparently not working as they expected:
[Mon Jun 27 13:05:17 2011] [notice] Apache/2.2.17 (Unix)
mod_apreq2-20090110/2.8.0 mod_perl/2.0.5 Perl/v5.12.3 configured --
resuming normal operations
8879 Apache::DBI new connect to 'dbname='...
In my startup.pl (My::Model is DBIx::Class based):
$Apache::DBI::DEBUG = 2;
my $db_connect_params = My::Model->connect_params;
Apache::DBI->connect_on_init( @{$db_connect_params} );
Apache::DBI->setPingTimeOut( $db_connect_params->[0], 5 );
# delete this line and I will beat you with a stick (note to self)
My::Model->connect->disconnect;
$DBI::connect_via = 'Apache::DBI::connect';
Re: How do you use mod_perl for your web application?
On Jun 27, 2011, at 12:53 PM, Octavian Rasnita wrote: > DBIx::Class already manages its connections for you, and therefore it > cannot benefit from Apache::DBI under any scenario. It makes one > connection per-process, and keeps that connection persistent, > reconnecting only if the connection appears to have died, or if you > fork/thread over to another process/thread-id. The only Apache::DBI > issue in DBIx::Class is that Apache::DBI will actually thwart > DBIx::Class's connection management code, and cause it to use the same > (and invalid) connection in a new process, in cases such as (as > mentioned above) if you make a DBI connection before forking in a > prefork mod_perl server. > > To work around this, DBIx::Class has specific code in it to work > around Apache::DBI, nullifying the effects of Apache::DBI on > DBIx::Class. Essentially, loading Apache::DBI should change nothing > and be rather pointless under DBIx::Class. > > The only reason we support it (support working around it) is because > someone might want Apache::DBI loaded up under the same mod_perl as a > DBIx::Class application to support a different legacy application > which does not use DBIx::Class, in which case they share a perl > interpreter and will both have the same set of modules loaded. The same statements apply to DBIx::Connector, FWIW. Best, David
Re: How do you use mod_perl for your web application?
Here is a comment that might be helpful, because it also explains why DBIx::Class can work with Apache::DBI (and why it is not needed): http://lists.scsys.co.uk/pipermail/dbix-class/2006-April/001153.html "" DBIx::Class already manages its connections for you, and therefore it cannot benefit from Apache::DBI under any scenario. It makes one connection per-process, and keeps that connection persistent, reconnecting only if the connection appears to have died, or if you fork/thread over to another process/thread-id. The only Apache::DBI issue in DBIx::Class is that Apache::DBI will actually thwart DBIx::Class's connection management code, and cause it to use the same (and invalid) connection in a new process, in cases such as (as mentioned above) if you make a DBI connection before forking in a prefork mod_perl server. To work around this, DBIx::Class has specific code in it to work around Apache::DBI, nullifying the effects of Apache::DBI on DBIx::Class. Essentially, loading Apache::DBI should change nothing and be rather pointless under DBIx::Class. The only reason we support it (support working around it) is because someone might want Apache::DBI loaded up under the same mod_perl as a DBIx::Class application to support a different legacy application which does not use DBIx::Class, in which case they share a perl interpreter and will both have the same set of modules loaded. "" Octavian - Original Message - From: "Fred Moyer" To: "Octavian Rasnita" Cc: ; "mod_perl list" Sent: Monday, June 27, 2011 6:37 PM Subject: Re: How do you use mod_perl for your web application? > On Sun, Jun 26, 2011 at 10:55 PM, Octavian Rasnita wrote: >> From: "Randolf Richardson" >>> I believe Catalyst depends on DBIx::Class, which also tries to turn >>> off the connection caching features provided by Apache::DBI (if I'm >>> recalling correctly) -- if this is true, then it could certainly help >>> to explain the lesser performance in a ModPerl environment. >> >> >> Catalyst doesn't depend on DBIx::Class. >> DBIx::Class just does its own persistent connection and this is why it >> doesn't need Apache::DBI. > > Do you have any evidence for this claim? I've been using DBIx::Class > with Apache::DBI for several years and have never seen anything to > this effect.
Re: How do you use mod_perl for your web application?
On 6/27/11 11:44 AM, "McCarrell, Jeff" wrote: >While this may not be the last word on this subject of DBIx::Class Db conn >caching, >a cursory glance at the documentation shows: >(http://search.cpan.org/~frew/DBIx-Class-0.08192/lib/DBIx/Class/Manual/Int >r >o.pod#Connecting) > > Note that DBIx::Class::Schema does not cache connections for >you. If you use multiple connections, you need to do this >manually. Poking a little bit further, (http://search.cpan.org/~frew/DBIx-Class-0.08192/lib/DBIx/Class/Storage/DBI .pm#connect_info) it looks like DBIx::Class caches statement handles via DBI (see disable_sth_caching which explicitly disables this caching) and that the design is oriented toward re-connecting to the DB transparently, as long as AutoCommit is turned on; which Apache::DBI also does. I believe that DBIx::Class is not as well suited for interleaving different SQL statements on the same connection as Apache::DBI because of its deeper assumptions about error handling and the state it assumes across SQL statements. So it appears that DBIx::Class does do its own connection handling, but aimed at a different design center than Apache::DBI. HTH, -- jeff
Re: How do you use mod_perl for your web application?
On 6/27/11 8:37 AM, "Fred Moyer" wrote: >>DBIx::Class just does its own persistent connection and this is why it >>doesn't need Apache::DBI. > >Do you have any evidence for this claim? I've been using DBIx::Class >with Apache::DBI for several years and have never seen anything to >this effect. > While this may not be the last word on this subject of DBIx::Class Db conn caching, a cursory glance at the documentation shows: (http://search.cpan.org/~frew/DBIx-Class-0.08192/lib/DBIx/Class/Manual/Intr o.pod#Connecting) Note that DBIx::Class::Schema does not cache connections for you. If you use multiple connections, you need to do this manually.
Re: How do you use mod_perl for your web application?
On Sun, Jun 26, 2011 at 10:55 PM, Octavian Rasnita wrote: > From: "Randolf Richardson" >> I believe Catalyst depends on DBIx::Class, which also tries to turn >> off the connection caching features provided by Apache::DBI (if I'm >> recalling correctly) -- if this is true, then it could certainly help >> to explain the lesser performance in a ModPerl environment. > > > Catalyst doesn't depend on DBIx::Class. > DBIx::Class just does its own persistent connection and this is why it > doesn't need Apache::DBI. Do you have any evidence for this claim? I've been using DBIx::Class with Apache::DBI for several years and have never seen anything to this effect.
Re: How do you use mod_perl for your web application?
On Sun, Jun 26, 2011 at 5:11 PM, Randolf Richardson wrote: > I believe Catalyst depends on DBIx::Class As Octavian said, there isn't really a connection between the two. Catalyst people often use DBIx::Class, but there's no tie at a code level. > To be fair, I think it would be important to run benchmarks against > a number of different products (some with database dependencies, some > without, etc.), and make sure the same peformance enhancing features > (such as database connection handle caching) are functioning (or not > functioning) across the different environments (e.g., mod_fcgid, > mod_perl2, etc.). For this benchmark, I was simply trying to determine whether or not the process management and buffering of the different web runtimes made a significant performance difference. I'm pleased to report that the differences are small, so you can use the one that you like best for other reasons. - Perrin
Re: How do you use mod_perl for your web application?
From: "Randolf Richardson" On Fri, Jun 24, 2011 at 3:00 PM, Phil Van wrote: > Interesting those are mod_fcgid + CGI, compared to plain > Apache + mod_perl + libapeq ? There are a number of modules like CGI and libapreq that run in multiple environments. My benchmark was a Catalyst app that just returned about 30K of HTML. [sNip] I believe Catalyst depends on DBIx::Class, which also tries to turn off the connection caching features provided by Apache::DBI (if I'm recalling correctly) -- if this is true, then it could certainly help to explain the lesser performance in a ModPerl environment. Catalyst doesn't depend on DBIx::Class. DBIx::Class just does its own persistent connection and this is why it doesn't need Apache::DBI. The performance is always lower for high-level programs than for low-level ones. Catalyst, DBIx::Class, Template-Toolkit, HTML::FormFu are high level modules which decrease the performance, but increase very much the productivity, so it depends on what is most important for you. If somebody needs to squeeze every millisecond from an application without scaling it by adding more and more servers, mod_perl handlers is the way to go. On the other hand, if somebody needs to create many applications that should be easy to maintain, or if the performance is not so important - you don't need to handle millions requests every day, then a higher level program is the way to go - a pre-made CMS, or blog, or wiki, or if they are too restrictive, a web framework + ORM + templating system + form processor. To be fair, I think it would be important to run benchmarks against a number of different products (some with database dependencies, some without, etc.), and make sure the same peformance enhancing features (such as database connection handle caching) are functioning (or not functioning) across the different environments (e.g., mod_fcgid, mod_perl2, etc.). Such a benchmark is usually the way of convincing the beginners, because the speed difference is usually the most simple and easy to understand difference between 2 similar programs. But as I said, a lowe level program is always faster than a higher level one (or at least in general, if both of them are done right). DBIx::Class uses DBI and many other modules which make programming much easier, so the programmer doesn't need to reinvent the wheel and concatenate strings for creating SQL queries. A templating system also is more readable and easier to understand than a big string with the entire page content which has Perl variables inside, a form processor is easier to maintain and create than a custom-created system of filtering, validating, applying constraints and other things for the input data, and a web framework is also much easier to use and maintain than doing a custom URL dispatching, character encoding, authentication, authorization, and many other things. Yes, as usually, the lower-level programs are more flexible and offer much more possibilities, but with a higher effort, and usually this effort is not necessary because most applications are not very complex. Catalyst can be used very fine with mod_perl, but yes, I heard very many recommendations (and not only from Catalyst users) to use fastcgi and not mod_perl. I use mod_perl with Catalyst because I found it more easy to use for my needs, but I do understand their opinions. Ideally, a Perl application should not need C-based modules, should not require a certain web server nor a certain database, and it should be portable under all operating systems. It would be very fine to not depend on Perl either, but this may be harder to do. :-) FastCGI can be used under more web servers, and this may be very important for those who need to deploy their applications on some VPS or on the cloud, where they might not have very many resources available, and so they may want to use a web server that consumes less resources than Apache. Octavian
Re: How do you use mod_perl for your web application?
> On Fri, Jun 24, 2011 at 3:00 PM, Phil Van wrote: > > > Interesting those are mod_fcgid + CGI, compared to plain > > Apache + mod_perl + libapeq ? > > There are a number of modules like CGI and libapreq that run in > multiple environments. My benchmark was a Catalyst app that just > returned about 30K of HTML. [sNip] I believe Catalyst depends on DBIx::Class, which also tries to turn off the connection caching features provided by Apache::DBI (if I'm recalling correctly) -- if this is true, then it could certainly help to explain the lesser performance in a ModPerl environment. To be fair, I think it would be important to run benchmarks against a number of different products (some with database dependencies, some without, etc.), and make sure the same peformance enhancing features (such as database connection handle caching) are functioning (or not functioning) across the different environments (e.g., mod_fcgid, mod_perl2, etc.). Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada http://www.inter-corporate.com
Re: How do you use mod_perl for your web application?
On Fri, Jun 24, 2011 at 12:17 PM, Perrin Harkins wrote: > > > Are you comparing that to mod_perl with a proxy server in front of it? > That is the equivalent architecture. If you remove the proxy, > mod_perl becomes faster but the scalability suffers. I wouldn't > recommend anyone run mod_perl without a frontend proxy of some kind. > > This is exactly what I saw. Better FastCGI support for Apache would be great. > I have some FastCGI programs, let me see if I could pack them and upload to CPAN. > > You actually can access efficient file serving through the mod_perl > API, but I agree, auth in the app framework is often a bad solution. > My favorite solution so far has been to use things like mod_auth_tkt > which let you write a complex auth system in your favorite language > and then check credentials from an efficient C module that can guard a > static file directory. > > - Perrin > Totally agree. Moving system-wide operations to C modules as far as possible.
Re: How do you use mod_perl for your web application?
On Fri, Jun 24, 2011 at 3:00 PM, Phil Van wrote: > Interesting those are mod_fcgid + CGI, compared to plain Apache + > mod_perl + libapeq ? There are a number of modules like CGI and libapreq that run in multiple environments. My benchmark was a Catalyst app that just returned about 30K of HTML. > I think all those application servers end up at roughly the same speed. Yes, that's what I've seen. > In > my cases, mod_fcgid has fewer memory footprint, which is typically around > 15-20M per application loaded with common modules like DBI, SHA1 and JSON. > Eventually, one may serve more fcgid applications on the same machine. Are you comparing that to mod_perl with a proxy server in front of it? That is the equivalent architecture. If you remove the proxy, mod_perl becomes faster but the scalability suffers. I wouldn't recommend anyone run mod_perl without a frontend proxy of some kind. > This is true. The earlier mod_fastcgi is commercial licensed; and the > support to AAA is almost broken. But the new fcgid, originally designed by > xiaolan's friend (as in the previous post) is very active in development. As > far as I know, it would be one of the standard modules in the coming httpd > 2.4. Better FastCGI support for Apache would be great. > I am also trying to promote the new mod_fcgid here :-) I think the main competition among FastCGI users is pure-perl daemons as FastCGI backends. I had good success in my tests with one of those. > This is a bad idea --- how about to serve a static mp3 in member area? We > lose the advantages to serve the file as NOT MODIFIED, or system's efficient > sendfile call. You actually can access efficient file serving through the mod_perl API, but I agree, auth in the app framework is often a bad solution. My favorite solution so far has been to use things like mod_auth_tkt which let you write a complex auth system in your favorite language and then check credentials from an efficient C module that can guard a static file directory. - Perrin
Re: How do you use mod_perl for your web application?
On Fri, Jun 24, 2011 at 8:10 AM, Perrin Harkins wrote:
> On Fri, Jun 24, 2011 at 12:45 AM, Phil Van wrote:
> > One should really try mod_fcgid + perl application. that is lighter,
> faster,
> > and more stable.
>
> FastCGI works fine, but these claims are not true. I benchmarked
> several FastCGI environments and none of them were significantly
> faster than mod_perl. They are also not lighter. The only thing
> "heavy" in mod_perl is Perl, and that will be there in FastCGI, PSGI,
> etc.
>
Interesting those are mod_fcgid + CGI, compared to plain Apache +
mod_perl + libapeq ?
I think all those application servers end up at roughly the same speed. In
my cases, mod_fcgid has fewer memory footprint, which is typically around
15-20M per application loaded with common modules like DBI, SHA1 and JSON.
Eventually, one may serve more fcgid applications on the same machine.
>
> > mod_fcgid provides also authenticate/authorize/access controls, besides
> > dynamical content.
>
> True, but my experience is that the documentation for these is pretty
> weak compared to the mod_perl equivalent. They don't seem to be used
> by many people. The ones for mod_perl are widely used and have many
> modules on CPAN for common needs.
>
>
This is true. The earlier mod_fastcgi is commercial licensed; and the
support to AAA is almost broken. But the new fcgid, originally designed by
xiaolan's friend (as in the previous post) is very active in development. As
far as I know, it would be one of the standard modules in the coming httpd
2.4.
I am also trying to promote the new mod_fcgid here :-)
Here is a typical scenario to run AAA in Fast::CGI
1) enable FCGI aaa program on the directory via httpd.conf or .htaccess
2) run aaa_program($r) if ($ENV->{FCGI_ROLE} && ($ENV->{FCGI_ROLE} eq
'AUTHORIZER'));
3) return 200 OK if it passes, or 401 if fails
However, the trend is to move these functions away from server APIs
> and put them in the application framework, so it may be a moot point.
>
>
This is a bad idea --- how about to serve a static mp3 in member area? We
lose the advantages to serve the file as NOT MODIFIED, or system's efficient
sendfile call.
> - Perrin
>
Re: How do you use mod_perl for your web application?
On Fri, Jun 24, 2011 at 12:45 AM, Phil Van wrote: > One should really try mod_fcgid + perl application. that is lighter, faster, > and more stable. FastCGI works fine, but these claims are not true. I benchmarked several FastCGI environments and none of them were significantly faster than mod_perl. They are also not lighter. The only thing "heavy" in mod_perl is Perl, and that will be there in FastCGI, PSGI, etc. > mod_fcgid provides also authenticate/authorize/access controls, besides > dynamical content. True, but my experience is that the documentation for these is pretty weak compared to the mod_perl equivalent. They don't seem to be used by many people. The ones for mod_perl are widely used and have many modules on CPAN for common needs. However, the trend is to move these functions away from server APIs and put them in the application framework, so it may be a moot point. - Perrin
Re: How do you use mod_perl for your web application?
On Fri, Jun 24, 2011 at 12:45 PM, Phil Van wrote: > One should really try mod_fcgid + perl application. that is lighter, faster, > and more stable. > mod_fcgid provides also authenticate/authorize/access controls, besides > dynamical content. > These are probably all you want to get from mod_perl. > Do you mean this module: http://httpd.apache.org/mod_fcgid/ Yes the author of mod_fcgid is one of my friends. He wrote the module orignally for NetEase webmail systems, and it behave well there. The PV each day for netease freemail systems is more than 100 million I believe. And for mod_perl, I have been running a mp2 handler in our production application for more than 3 years, never had problems. xiaolan
Re: How do you use mod_perl for your web application?
One should really try mod_fcgid + perl application. that is lighter, faster, and more stable. mod_fcgid provides also authenticate/authorize/access controls, besides dynamical content. These are probably all you want to get from mod_perl. On Tue, Jun 21, 2011 at 2:13 PM, Perrin Harkins wrote: > On Tue, Jun 21, 2011 at 5:03 PM, Rolf Schaufelberger wrote: > >> 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. > > > > yes, I've tried this too, but this leads to a big memory footprint too. > If you have 10 sites and make separate (preforking) instance for each vhost, > with StartServers = 2 and set the other parameters (Min/MaxSpareServers etc) > to low values, you quickly get 20 oder 30 fat apache processes. Ok, you can > get this running with enough memory, but the idea of instance pools seems > to be a better and more elegant solution for this. > > I don't understand what would be different. My suggestion was to run > one httpd server for each version of the code that you need, possibly > with virtual hosts on each if there are multiple hosts that use the > same version of the code. If you had an "instance pool", wouldn't it > also be multiple processes (or threads if you prefer) per version of > code? I don't see how you could avoid that. Were you thinking you'd > reset the perl interpreters completely between requests so that one > could be shared between multiple versions of code? > > > I've discussed this once with Torsten Förtsch who is a mod_perl expert > nearby, his opinion was, that it wouldn't be very much code that has to be > added for this. > > Torsten is a major contributor and I'm sure that whatever he had in > mind would be cool. > > - Perrin >
Re: How do you use mod_perl for your web application?
On Tue, Jun 21, 2011 at 5:03 PM, Rolf Schaufelberger wrote: >> 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. > > yes, I've tried this too, but this leads to a big memory footprint too. If > you have 10 sites and make separate (preforking) instance for each vhost, > with StartServers = 2 and set the other parameters (Min/MaxSpareServers etc) > to low values, you quickly get 20 oder 30 fat apache processes. Ok, you can > get this running with enough memory, but the idea of instance pools seems > to be a better and more elegant solution for this. I don't understand what would be different. My suggestion was to run one httpd server for each version of the code that you need, possibly with virtual hosts on each if there are multiple hosts that use the same version of the code. If you had an "instance pool", wouldn't it also be multiple processes (or threads if you prefer) per version of code? I don't see how you could avoid that. Were you thinking you'd reset the perl interpreters completely between requests so that one could be shared between multiple versions of code? > I've discussed this once with Torsten Förtsch who is a mod_perl expert > nearby, his opinion was, that it wouldn't be very much code that has to be > added for this. Torsten is a major contributor and I'm sure that whatever he had in mind would be cool. - Perrin
Re: How do you use mod_perl for your web application?
Am 21.06.2011 um 18:12 schrieb Perrin Harkins: > On Tue, Jun 21, 2011 at 2:25 AM, Rolf Schaufelberger wrote: >> We are using Mason 1.x, a (little) modified version of MasonX::WebApp > > Us too! Glad to know someone else is using it. Same to me, didn't hear from somebody else using it. When I started with it there weren't much alternatives, David Wheelers Interp::WithCallbacks or Maypole and that was 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 yes, I've tried this too, but this leads to a big memory footprint too. If you have 10 sites and make separate (preforking) instance for each vhost, with StartServers = 2 and set the other parameters (Min/MaxSpareServers etc) to low values, you quickly get 20 oder 30 fat apache processes. Ok, you can get this running with enough memory, but the idea of instance pools seems to be a better and more elegant solution for this. I've discussed this once with Torsten Förtsch who is a mod_perl expert nearby, his opinion was, that it wouldn't be very much code that has to be added for this. Rolf Schaufelberger
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
Re: How do you use mod_perl for your web application?
On Thu, 16 Jun 2011 06:01:03 +0200, Fred Moyer 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: How do you use mod_perl for your web application?
On Tue, Jun 21, 2011 at 2:25 AM, Rolf Schaufelberger 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: How do you use mod_perl for your web application?
On Mon, Jun 20, 2011 at 11:00 PM, Randolf Richardson 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?
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?
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?
> On Fri, Jun 17, 2011 at 7:28 PM, Randolf Richardson
> wrote:
> > I suspect that I wouldn't be running
> > into these issues with a framework system designed to work with
> > DBIx::Class.
>
> I don't think mod_perl should have more trouble cooperating with
Oh, please don't get me wrong -- I wasn't, for even a minute,
thinking that mod_perl was the culprit. When modules that add
functionality like Java's "try {} catch {}" paradigms work just fine
under mod_perl2, I have very little reason to doubt its capabilities.
> DBIx::Class than other web environments. However, some of the people
> who use DBIx::Class are vocal mod_perl haters, so they may not give
> very good advice about how to set it up with mod_perl.
I was hoping that this wasn't the case. It's really a shame when
someone hates a given technology. 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., but I've already committed to using
mod_perl2 for so many things, and for so many years, that I just
write it off as "enthusiasm that's gone a bit too far." I hope that
the fact that I'm out there mentioning mod_perl2 from time-to-time,
and without trying to push it on others, does help a little bit.
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. I think
that a product that works well and is based on quality code certainly
has the potential to see fewer updates, but this does start some
interesting debates about what a lot of unknown people are thinking.
> > A DBIx developer in IRC explained to me once that
> > DBIx::Class also goes to great lengths to shut off connection caching
> > from the Apache::DBI module -- after switching back to DBI, the
> > resulting performance gain has me wondering if this is correct.
>
> 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).
> Sounds like you're having a good time with your mod_perl stuff! Good to hear.
It's wonderful. I just love how fast it is, and how well it
integrates so closely with Apache HTTPd. I've got a few friends
getting interested in it lately (and one of them has been doing a lot
of PHP development, but wants to find a way to go back to Perl, so I
helped him get it working).
Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com
Re: How do you use mod_perl for your web application?
We use Mason 1.x inside a custom web framework (which I've recently gotten permission to release open-source), under mod_perl/Apache 2. Working on a transition to Plack and Mason 2, but we've already integrated the superior stack traces and debug console from Plack middleware. On Jun 15, 2011, at 9:01 PM, Fred Moyer wrote: > I'm interested in hearing about what application frameworks (Catalyst, > CGI::App, Mojolicious) are used here with mod_perl. Given the number > of emerging Perl based webservers on CPAN (in addition to Nginx, > lighty, etc), it seems like there are many more Perl web application > and webservers out there now than there were five years ago. > > I'll start. I have a couple of Apache::Dispatch based applications I > wrote. I also work on an Apache::ASP large codebase, and a couple of > different Catalyst based systems. All are running on mod_perl 2.0.4 > in production (the ops haven't upgraded to 2.0.5 yet). > > If I were to migrate, I would probably try out something like > Mojolicious on Plack on mod_perl2. Performance of mod_perl2 has never > been an issue to date, but I have Perlbal doing connection handling as > a reverse proxy.
Re: How do you use mod_perl for your web application?
On Fri, Jun 17, 2011 at 7:28 PM, Randolf Richardson wrote: > I suspect that I wouldn't be running > into these issues with a framework system designed to work with > DBIx::Class. I don't think mod_perl should have more trouble cooperating with DBIx::Class than other web environments. However, some of the people who use DBIx::Class are vocal mod_perl haters, so they may not give very good advice about how to set it up with mod_perl. > A DBIx developer in IRC explained to me once that > DBIx::Class also goes to great lengths to shut off connection caching > from the Apache::DBI module -- after switching back to DBI, the > resulting performance gain has me wondering if this is correct. 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. Sounds like you're having a good time with your mod_perl stuff! Good to hear. - Perrin
Re: How do you use mod_perl for your web application?
> I'm interested in hearing about what application frameworks (Catalyst, > CGI::App, Mojolicious) are used here with mod_perl. Given the number > of emerging Perl based webservers on CPAN (in addition to Nginx, > lighty, etc), it seems like there are many more Perl web application > and webservers out there now than there were five years ago. [sNip] I'm using mod_perl2 for custom internet site development. Where many people might use static HTML pages, or other programming languages such as JSP (and others), I have a .pl (Perl source code) file in its place (e.g., "index.pl" instead of "index.html"). On one of my web sites, I documented the steps that I use to configure mod_perl2 for this (working sample source code included): How to install and configure ModPerl 2 http://www.modperl.pl/how-to/ I am hosting hundreds of web sites that I developed with mod_perl2, and although most of them are small (and static pages could have worked just fine too), there are a few that have PostgreSQL database backends (membership management, PayPal integration, full transaction history browsing, private forums, etc.). I did use DBIx::Class for a while, but eventually moved back to straight DBI (and I just finished converting the last site a few days ago). I think DBIx::Class is a wonderful system, but the problem I had with it is that new versions were behaving unexpectedly in ways that would cause my web sites to stop functioning (unless I enabled various "backward compabitility" options), and then re-generating classes eventually resulted in the custom classes having to be updated as well. So, I moved back to DBI which is doing the job very well for me, and which I find is also more flexible despite being a little bit less convenient. I suspect that I wouldn't be running into these issues with a framework system designed to work with DBIx::Class. A DBIx developer in IRC explained to me once that DBIx::Class also goes to great lengths to shut off connection caching from the Apache::DBI module -- after switching back to DBI, the resulting performance gain has me wondering if this is correct. At one point I started to create a telnet server for a BBS-type system (just for fun), but had to put it on the back-burner due to time-constraints (customizing one of Apache 2 HTTPd's connection handlers made this possible). Originally I started out using mod_perl on Novell's NetWare OS, but Novell stopped pre-compiling mod_perl2 so I switched to NetBSD (which I've been using ever since). I also started writing a Wiki system from scratch, and plan to continue with that eventually. I don't use proxying or virtualization for my web servers (it's all running bare-metal), just raw mod_perl2. I'm extremely pleased with the high performance and solid reliability that I get from mod_perl2 on NetBSD servers, and intend to keep using it (and promoting it) for years to come. Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada http://www.inter-corporate.com
Re: How do you use mod_perl for your web application?
On 15/06/11 10:01 PM, Fred Moyer wrote: I'm interested in hearing about what application frameworks (Catalyst, CGI::App, Mojolicious) are used here with mod_perl. We currently support an open source corporate CMS called Metapoint http://www.metapointcms.com (derived from Metadot, derived from the original Redhat CMS) which runs on mod_perl 1.3 and mod_perl 2.0.x without change It is fully dynamic. supporting MySQL, Postgres, SQLLite and Oracle. It easily integrates with external systems including VOIP and and source control applications. It is easily extendible so that any code can be called through wrappers in perl modules. We do nothing fancy with mod-perl, everything is done with Apache::Registry. We use a fair number of Apache modules, including mod_deflate as Fred mentioned earlier. In order to leverage other programmers work we have spent a lot of time looking at web frameworks and have a prototype running under Catalyst. We will gradually port our code ( and clean up a lot of crap) to Catalyst and I hope to be running on it within a year. Years ago we compiled apache, mod_perl and our other modules from source but now we rely on the CentOS packages. I really have no interest in perl webservers per se but I would like to hear about other frameworks that may meet our needs. Mojolicious appears to be a little underdeveloped for what we want but I am willing to be corrected on this. HTH Dave -- Dave Morgan Operations Manager, BorealEscapes http://www.borealescapes.ca dave.mor...@borealescapes.ca 403 288 8759
Re: How do you use mod_perl for your web application?
Le jeudi 16 juin 2011 à 14:11 -0700, Joe Schaefer a écrit : > > To me writing to a generic webserver API is not all that exciting. > Python people love it, but they've never had a proper exposure > to httpd in the first place. Yes it means you gain some portability, > but the downside is that you lose an awful lot of power that comes > from the existing open source module ecosystem for httpd. That's not > easily replaced, no matter what others may say. > Power indeed. I wrote an application for case management that uses mod_perl's and postgresql's specific features, via simple mod_perl handlers (LAMP to me means Linux/Apache/Mod_Perl/Postgres). The result is 15 milliseconds response times to generate an html page with authentication and a hit to the database, on commodity hardware. My application serves five to six users all day with a 1.6 Ghz processor (200 dollar machine, 0 license) which peaks at 0.3% usage on busy weekdays. That leaves me room for growth. I don't suppose you can get the same numbers using frameworks? -- Vincent Veyron http://marica.fr/ Logiciel de gestion des sinistres et des contentieux pour le service juridique
Re: How do you use mod_perl for your web application?
I had 8-9 apps running as custom mp2 modules (not really in any framework.) I did a few things in Catalyst, but it never really lit my candle. Perlbal for reverse proxy. I used Postgres a lot, but eventually realized that sqlite3 was good enough for what I was doing most of the time. Of late, I've been wanting to go to PSGI or node.js, but I haven't taken the plunge yet. Many of my mod_perl apps relied on client-side PKI and SSL renegotiation, which I don't think can be done in PSGI, (or at least not well) and mod_perl really shines by having hooks for all phases of request handling. On Thu, Jun 16, 2011 at 12:01 AM, Fred Moyer wrote: > I'm interested in hearing about what application frameworks (Catalyst, > CGI::App, Mojolicious) are used here with mod_perl. Given the number > of emerging Perl based webservers on CPAN (in addition to Nginx, > lighty, etc), it seems like there are many more Perl web application > and webservers out there now than there were five years ago. > > I'll start. I have a couple of Apache::Dispatch based applications I > wrote. I also work on an Apache::ASP large codebase, and a couple of > different Catalyst based systems. All are running on mod_perl 2.0.4 > in production (the ops haven't upgraded to 2.0.5 yet). > > If I were to migrate, I would probably try out something like > Mojolicious on Plack on mod_perl2. Performance of mod_perl2 has never > been an issue to date, but I have Perlbal doing connection handling as > a reverse proxy. >
Re: How do you use mod_perl for your web application?
On Thu, Jun 16, 2011 at 2:01 PM, Fred Moyer wrote: > I'm interested in hearing about what application frameworks (Catalyst, > CGI::App, Mojolicious) are used here with mod_perl. We have a lot of code using CGI::App as well as a mix of in-house custom frameworks (old legacy stuff that goes back 8 to 10 years). All our apache/mod_perl servers sit behind three nginx boxes that do caching, SSL offloading and content compression. 90% of what is behind the proxies is running apache2/mod_perl2 (stock debian packages for ease of maintenance), but there is still some apache1.3/mod_perl1 stuff hanging around too. Some apps run through FastCGI, but the majority are mod_perl content handlers or Registry scripts. Cheers, Cees
Re: How do you use mod_perl for your web application?
Hi Fred, I use mod_perl on a custom built framework written back in 2005 Performance of mod_perl has never been an issue, internal authenication and network speed are more issues. This runs on an intranet and services around 5000 users Regards Greg George From: Fred Moyer To: mod_perl list Date: 16/06/2011 02:01 PM Subject:How do you use mod_perl for your web application? I'm interested in hearing about what application frameworks (Catalyst, CGI::App, Mojolicious) are used here with mod_perl. Given the number of emerging Perl based webservers on CPAN (in addition to Nginx, lighty, etc), it seems like there are many more Perl web application and webservers out there now than there were five years ago. I'll start. I have a couple of Apache::Dispatch based applications I wrote. I also work on an Apache::ASP large codebase, and a couple of different Catalyst based systems. All are running on mod_perl 2.0.4 in production (the ops haven't upgraded to 2.0.5 yet). If I were to migrate, I would probably try out something like Mojolicious on Plack on mod_perl2. Performance of mod_perl2 has never been an issue to date, but I have Perlbal doing connection handling as a reverse proxy. *** Please consider the environment before printing this e-mail. This message is intended solely for the individual(s) and entity(s) addressed. It is confidential and may contain legally privileged information. The use, copying or distribution of this message or any information it contains, by anyone other than the addressee, is prohibited. If you have received this message in error, please notify postmas...@orica.com. The mailbox address from which this message has been sent is for business mail only. Mail sent to it may be subject to security scanning and delivery on non-business messages sent to this address may not occur. Thank you. ***
Re: How do you use mod_perl for your web application?
On Thu, Jun 16, 2011 at 1:26 PM, Michael Peters wrote: > I'd like to see the performance of Starman vs > mod_perl for normal applications (that don't need to do anything fancy with > Apache). If it's anywhere close to mod_perl than I suspect lots of people > would use it instead since it's much easier to setup and also much easier to > package with your app since it's just a CPAN module. Would be nice to > through FastCGI into that benchmark too. I tweeted @miyagawa to see if he had this benchmark, and if memory serves mod_perl2 was about 75% the speed of Starman in a hello world benchmark with an unknown mod_perl2 configuration. I believe the Starman cpan page has benchmarks vs FastCGI. My takeaway from those benchmarks was that all of the webservers tested were essentially equally fast since they were within 25-50% of the performance of each other with a simple benchmark. I'm not sold on packaging the webserver with the application though. I've been moving towards using the webserver (in my case httpd/mod_perl2) that is installed with the platform. One less thing for me to worry about, in my case the Centos packagers take care of that problem for me.
Re: How do you use mod_perl for your web application?
- Original Message > From: Fred Moyer > To: Joe Schaefer > Cc: mod_perl list > Sent: Thu, June 16, 2011 5:01:49 PM > Subject: Re: How do you use mod_perl for your web application? > > On Thu, Jun 16, 2011 at 1:30 PM, Joe Schaefer wrote: > > Sigh. The big win with mod_perl2 is you get to interface with the rest > > of the C modules for httpd, often via subrequests. At the ASF we've > > been running mod_perl2 as our frontline mailserver for over 5y > > This is Apache2::Qpsmtpd right? Nice module. > > > , and recently > > I wrote an ASF-wide CMS with it that's gaining more and more users as > > time goes on, in under 5K LOC. Haven't seen the need for app frameworks > > because most of my code is mod_perl2 specific- it just won't work in any > > other webserver. > > I guess I should rephrase what I said earlier; I don't see use of > mod_perl2 for web applications going away. I see the usage pattern > for Perl based web applications that use frameworks like Catalyst et > al becoming one where there is less usage of tightly coupled modules > such as Apache::Session and Apache::DBI. To me writing to a generic webserver API is not all that exciting. Python people love it, but they've never had a proper exposure to httpd in the first place. Yes it means you gain some portability, but the downside is that you lose an awful lot of power that comes from the existing open source module ecosystem for httpd. That's not easily replaced, no matter what others may say. > The ability to interface with the httpd C modules is a big win that I > don't think a lot of users appreciate until their application gets big > enough to cause pain. Output compression is one area I've seen people > struggle with in Perl land, and write elaborate hacks into their > Catalyst application, when they could do the same thing in httpd.conf > with 'Include conf/deflate.conf' and just stuff all the mod_deflate > directives in that file. > Yup. Content negotiation is another area where people come up with lotsa sloppy hacks. Just run a subrequest with content-negotiation enabled and be happy- it just works.
Re: How do you use mod_perl for your web application?
On Thu, Jun 16, 2011 at 1:30 PM, Joe Schaefer wrote: > Sigh. The big win with mod_perl2 is you get to interface with the rest > of the C modules for httpd, often via subrequests. At the ASF we've > been running mod_perl2 as our frontline mailserver for over 5y This is Apache2::Qpsmtpd right? Nice module. > , and recently > I wrote an ASF-wide CMS with it that's gaining more and more users as > time goes on, in under 5K LOC. Haven't seen the need for app frameworks > because most of my code is mod_perl2 specific- it just won't work in any > other webserver. I guess I should rephrase what I said earlier; I don't see use of mod_perl2 for web applications going away. I see the usage pattern for Perl based web applications that use frameworks like Catalyst et al becoming one where there is less usage of tightly coupled modules such as Apache::Session and Apache::DBI. The ability to interface with the httpd C modules is a big win that I don't think a lot of users appreciate until their application gets big enough to cause pain. Output compression is one area I've seen people struggle with in Perl land, and write elaborate hacks into their Catalyst application, when they could do the same thing in httpd.conf with 'Include conf/deflate.conf' and just stuff all the mod_deflate directives in that file.
Re: How do you use mod_perl for your web application?
On Thu, Jun 16, 2011 at 4:18 PM, Fred Moyer wrote: > Maybe I'm not completely grokking how people are starting new projects > using Plack, but it seems like the way to go is to not use Plack > itself to write the code, but to use one of the many web frameworks > (Mason2, Catalyst, Mojolicious) and then use Plack to specify what > webserver is used. Plack is just middleware. I'm just saying Plack looks fun. Maybe I miss the days of writing OO mod_perl handlers. That was fun. > There is a Mason handler for Plack, so it almost seems like you could > migrate your existing application to the Plack middleware stack while > changing little in your Mason codebase. It's clear that you haven't seen this Mason codebase ;) - Perrin
Re: How do you use mod_perl for your web application?
> - Original Message > >> From: Fred Moyer >> To: Perrin Harkins >> Cc: David E. Wheeler ; mod_perl list >> >> Sent: Thu, June 16, 2011 4:18:17 PM >> Subject: Re: How do you use mod_perl for your web application? >> >> On Thu, Jun 16, 2011 at 1:13 PM, Perrin Harkins wrote: >> > On Thu, Jun 16, 2011 at 4:07 PM, David E. Wheeler >>wrote: >> >> Whatever old man! >> > >> > I know, it's just a reality of working on applications that have been >> > around for years. These tools are so reliable that they tend to stick >> > around. If I started something new I would probably use Plack, since >> > I've enjoyed using similar stuff in Python. >> >> Maybe I'm not completely grokking how people are starting new projects >> using Plack, but it seems like the way to go is to not use Plack >> itself to write the code, but to use one of the many web frameworks >> (Mason2, Catalyst, Mojolicious) and then use Plack to specify what >> webserver is used. Plack is just middleware. >> >> There is a Mason handler for Plack, so it almost seems like you could >> migrate your existing application to the Plack middleware stack while >> changing little in your Mason codebase. >> >> I see the role of mod_perl2 going forward as not something that >> applications are written on, but something that webserver middleware >> interfaces with. > > Sigh. The big win with mod_perl2 is you get to interface with the rest > of the C modules for httpd, often via subrequests. At the ASF we've > been running mod_perl2 as our frontline mailserver for over 5y, and recently > I wrote an ASF-wide CMS with it that's gaining more and more users as > time goes on, in under 5K LOC. Haven't seen the need for app frameworks > because most of my code is mod_perl2 specific- it just won't work in any > other webserver. Agreed with this I've been looking around at all these discussions the situation I'm in is probably more complex than writing a single application I manage a large infastructure for a large scientific institute with a small core webteam - and upwards of 200 developers. So my approach to development is probably considerably different to some of the projects here. Currently we are migrating our website to a new "mod_perl" backed system. It has many requirements so our framework (Developed in house) has to be compact, easy, flexible, and easily extensible, but at the same time give good diagnostics and stop bad code being submitted. The system is a mixture of: * mod_perl handlers to perform routing, mapping URL spaces to perl modules; to handle temporary files; improve error reporting; handle user identity etc; built in caching, optimisation of images/ js/css; * mod_perl output filters to handle page decorating; * javascript/css libraries tied into the system; * integrated support for AJAX; * a series of modules which handle Components (parts of pages which can be included into static HTML/dynamically generated HTML); and Actions (web pages, JSON/XML documents etc) * an SVN based sandbox/dev/staging/production system to pubish code, and check quality tool to force good HTML, Javascript; * tools to monitor changes, etc * ability to write applications as either CGI scripts, mod_perl (using registry) [but both are frowned on], Ruby, PHP, Java, HTML/JavaScript and still have the benefits of the decoration and component system (Ruby, PHP, Java etc just produce raw HTML containing component instructions) e.g. http://www.sanger.ac.uk/resources/databases/tiffin/table.jsp?col=3 Is a JSP wrapped using Perl to look like the rest of the site... In other projects I combine it with PHP to handle a lot of the initial set up - parsing cookies for users etc and populating variables that other applications can use; It has a few more lines of code than yours - but the core of the system is quite compact - it's just the fluff and added features which make it longer... (plus getting the code through perl::critic!) -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Re: How do you use mod_perl for your web application?
- Original Message > From: Fred Moyer > To: Perrin Harkins > Cc: David E. Wheeler ; mod_perl list > > Sent: Thu, June 16, 2011 4:18:17 PM > Subject: Re: How do you use mod_perl for your web application? > > On Thu, Jun 16, 2011 at 1:13 PM, Perrin Harkins wrote: > > On Thu, Jun 16, 2011 at 4:07 PM, David E. Wheeler >wrote: > >> Whatever old man! > > > > I know, it's just a reality of working on applications that have been > > around for years. These tools are so reliable that they tend to stick > > around. If I started something new I would probably use Plack, since > > I've enjoyed using similar stuff in Python. > > Maybe I'm not completely grokking how people are starting new projects > using Plack, but it seems like the way to go is to not use Plack > itself to write the code, but to use one of the many web frameworks > (Mason2, Catalyst, Mojolicious) and then use Plack to specify what > webserver is used. Plack is just middleware. > > There is a Mason handler for Plack, so it almost seems like you could > migrate your existing application to the Plack middleware stack while > changing little in your Mason codebase. > > I see the role of mod_perl2 going forward as not something that > applications are written on, but something that webserver middleware > interfaces with. Sigh. The big win with mod_perl2 is you get to interface with the rest of the C modules for httpd, often via subrequests. At the ASF we've been running mod_perl2 as our frontline mailserver for over 5y, and recently I wrote an ASF-wide CMS with it that's gaining more and more users as time goes on, in under 5K LOC. Haven't seen the need for app frameworks because most of my code is mod_perl2 specific- it just won't work in any other webserver.
Re: How do you use mod_perl for your web application?
On 06/16/2011 04:18 PM, Fred Moyer wrote: Maybe I'm not completely grokking how people are starting new projects using Plack, but it seems like the way to go is to not use Plack itself to write the code, but to use one of the many web frameworks (Mason2, Catalyst, Mojolicious) and then use Plack to specify what webserver is used. Plack is just middleware. Yes, but lots of people are using Plack to refer to the Plack family of stuff. Mainly the PSGI spec, the middleware and possibly one of the new Plack/PSGI oriented servers (like Starman). I see the role of mod_perl2 going forward as not something that applications are written on, but something that webserver middleware interfaces with. Yeah, that's what I see too. I'd like to see the performance of Starman vs mod_perl for normal applications (that don't need to do anything fancy with Apache). If it's anywhere close to mod_perl than I suspect lots of people would use it instead since it's much easier to setup and also much easier to package with your app since it's just a CPAN module. Would be nice to through FastCGI into that benchmark too. -- Michael Peters Plus Three, LP
Re: How do you use mod_perl for your web application?
On Thu, Jun 16, 2011 at 1:19 PM, Daniel Risacher wrote: > Of late, I've been wanting to go to PSGI or node.js, but I haven't > taken the plunge yet. Many of my mod_perl apps relied on client-side > PKI and SSL renegotiation, which I don't think can be done in PSGI, > (or at least not well) and mod_perl really shines by having hooks for > all phases of request handling. Having support for these request phases is definitely something that middleware authors should keep in mind when looking to support mod_perl2 well. I don't think Plack does this right now.
Re: How do you use mod_perl for your web application?
On Thu, Jun 16, 2011 at 1:13 PM, Perrin Harkins wrote: > On Thu, Jun 16, 2011 at 4:07 PM, David E. Wheeler > wrote: >> Whatever old man! > > I know, it's just a reality of working on applications that have been > around for years. These tools are so reliable that they tend to stick > around. If I started something new I would probably use Plack, since > I've enjoyed using similar stuff in Python. Maybe I'm not completely grokking how people are starting new projects using Plack, but it seems like the way to go is to not use Plack itself to write the code, but to use one of the many web frameworks (Mason2, Catalyst, Mojolicious) and then use Plack to specify what webserver is used. Plack is just middleware. There is a Mason handler for Plack, so it almost seems like you could migrate your existing application to the Plack middleware stack while changing little in your Mason codebase. I see the role of mod_perl2 going forward as not something that applications are written on, but something that webserver middleware interfaces with.
Re: How do you use mod_perl for your web application?
On Thu, Jun 16, 2011 at 4:07 PM, David E. Wheeler wrote: > Whatever old man! I know, it's just a reality of working on applications that have been around for years. These tools are so reliable that they tend to stick around. If I started something new I would probably use Plack, since I've enjoyed using similar stuff in Python. - Perrin
Re: How do you use mod_perl for your web application?
On Jun 16, 2011, at 12:14 PM, Perrin Harkins wrote: > On Thu, Jun 16, 2011 at 12:01 AM, Fred Moyer wrote: >> I'm interested in hearing about what application frameworks (Catalyst, >> CGI::App, Mojolicious) are used here with mod_perl. > > Mason 1.x on mod_perl 1.x and apache 1.x, baby! Whatever old man! David
Re: How do you use mod_perl for your web application?
On Thu, Jun 16, 2011 at 12:01 AM, Fred Moyer wrote: > I'm interested in hearing about what application frameworks (Catalyst, > CGI::App, Mojolicious) are used here with mod_perl. Mason 1.x on mod_perl 1.x and apache 1.x, baby! - Perrin
Re: How do you use mod_perl for your web application?
> I'm interested in hearing about what application frameworks (Catalyst, > CGI::App, Mojolicious) are used here with mod_perl. Currently, I use plain mod_perl2 2.0.4 with apache2 for a project about 10k LOC on the web side and about 32k application's LOC. I would like to know a better framework to use in a very specific case: web side and application are separated in different virtual servers. I see no gain in using Mojolicious in my case. -- Anton Petrusevich
Re: How do you use mod_perl for your web application?
On 06/16/2011 12:01 AM, Fred Moyer wrote: I'll start. I have a couple of Apache::Dispatch based applications I wrote. I also work on an Apache::ASP large codebase, and a couple of different Catalyst based systems. All are running on mod_perl 2.0.4 in production (the ops haven't upgraded to 2.0.5 yet). We use CGI::Application on mod_perl 1.31 (I know, I know) with Apache 2 as a reverse proxy. If I were to migrate, I would probably try out something like Mojolicious on Plack on mod_perl2. Performance of mod_perl2 has never been an issue to date, but I have Perlbal doing connection handling as a reverse proxy. We're looking at migrating to PSGI. We actually plan to do a full evaluation of backends (mod_perl2 vs Starman) and proxies (varnish, lighttpd, nginx, apache2, perlbal) with SSL thrown in the mix too (some proxies don't do SSL so we'll look at doing proxy + pound) -- Michael Peters Plus Three, LP
Re: How do you use mod_perl for your web application?
On Jun 15, 2011, at 9:01 PM, Fred Moyer wrote: > I'll start. I have a couple of Apache::Dispatch based applications I > wrote. I also work on an Apache::ASP large codebase, and a couple of > different Catalyst based systems. All are running on mod_perl 2.0.4 > in production (the ops haven't upgraded to 2.0.5 yet). I use Apache 2 as a reverse proxy for a bunch of Starman-powered Plack apps. And I have a Bricolage install on mod_perl2. > If I were to migrate, I would probably try out something like > Mojolicious on Plack on mod_perl2. Performance of mod_perl2 has never > been an issue to date, but I have Perlbal doing connection handling as > a reverse proxy. PGXN, which runs on Starman, will be moving to a PostgreSQL community server. I think they use Varnish for reverse proxying. Best, David
How do you use mod_perl for your web application?
I'm interested in hearing about what application frameworks (Catalyst, CGI::App, Mojolicious) are used here with mod_perl. Given the number of emerging Perl based webservers on CPAN (in addition to Nginx, lighty, etc), it seems like there are many more Perl web application and webservers out there now than there were five years ago. I'll start. I have a couple of Apache::Dispatch based applications I wrote. I also work on an Apache::ASP large codebase, and a couple of different Catalyst based systems. All are running on mod_perl 2.0.4 in production (the ops haven't upgraded to 2.0.5 yet). If I were to migrate, I would probably try out something like Mojolicious on Plack on mod_perl2. Performance of mod_perl2 has never been an issue to date, but I have Perlbal doing connection handling as a reverse proxy.
