Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: ModPerl

How do you use mod_perl for your web application?

 

 

First page Previous page 1 2 Next page Last page  View All ModPerl modperl RSS feed   Index | Next | Previous | View Threaded


rs at plusw

Jun 20, 2011, 11:25 PM

Post #26 of 50 (1639 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

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


rolf.b.mr at gmail

Jun 21, 2011, 4:43 AM

Post #27 of 50 (1633 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

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.


perrin at elem

Jun 21, 2011, 9:09 AM

Post #28 of 50 (1633 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

On Mon, Jun 20, 2011 at 11:00 PM, Randolf Richardson <randolf [at] modperl> 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


perrin at elem

Jun 21, 2011, 9:12 AM

Post #29 of 50 (1632 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

On Tue, Jun 21, 2011 at 2:25 AM, Rolf Schaufelberger <rs [at] plusw> 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


cosimo at streppone

Jun 21, 2011, 9:33 AM

Post #30 of 50 (1633 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

On Thu, 16 Jun 2011 06:01:03 +0200, Fred Moyer <fred [at] redhotpenguin>
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


david at kineticode

Jun 21, 2011, 9:58 AM

Post #31 of 50 (1634 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

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


rs at plusw

Jun 21, 2011, 2:03 PM

Post #32 of 50 (1631 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

Am 21.06.2011 um 18:12 schrieb Perrin Harkins:

> On Tue, Jun 21, 2011 at 2:25 AM, Rolf Schaufelberger <rs [at] plusw> 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


perrin at elem

Jun 21, 2011, 2:13 PM

Post #33 of 50 (1636 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

On Tue, Jun 21, 2011 at 5:03 PM, Rolf Schaufelberger <rs [at] plusw> 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


pv2100 at gmail

Jun 23, 2011, 9:45 PM

Post #34 of 50 (1612 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

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 <perrin [at] elem> wrote:

> On Tue, Jun 21, 2011 at 5:03 PM, Rolf Schaufelberger <rs [at] plusw> 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
>


practicalperl at gmail

Jun 24, 2011, 12:53 AM

Post #35 of 50 (1606 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

On Fri, Jun 24, 2011 at 12:45 PM, Phil Van <pv2100 [at] gmail> 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


perrin at elem

Jun 24, 2011, 8:10 AM

Post #36 of 50 (1599 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

On Fri, Jun 24, 2011 at 12:45 AM, Phil Van <pv2100 [at] gmail> 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


pv2100 at gmail

Jun 24, 2011, 12:00 PM

Post #37 of 50 (1599 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

On Fri, Jun 24, 2011 at 8:10 AM, Perrin Harkins <perrin [at] elem> wrote:

> On Fri, Jun 24, 2011 at 12:45 AM, Phil Van <pv2100 [at] gmail> 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
>


perrin at elem

Jun 24, 2011, 12:17 PM

Post #38 of 50 (1597 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

On Fri, Jun 24, 2011 at 3:00 PM, Phil Van <pv2100 [at] gmail> 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


pv2100 at gmail

Jun 24, 2011, 1:27 PM

Post #39 of 50 (1598 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

On Fri, Jun 24, 2011 at 12:17 PM, Perrin Harkins <perrin [at] elem> 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.


randolf at modperl

Jun 26, 2011, 5:11 PM

Post #40 of 50 (1585 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

> On Fri, Jun 24, 2011 at 3:00 PM, Phil Van <pv2100 [at] gmail> 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 - randolf [at] inter-corporate
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com


orasnita at gmail

Jun 26, 2011, 10:55 PM

Post #41 of 50 (1585 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

From: "Randolf Richardson" <randolf [at] modperl>
>> On Fri, Jun 24, 2011 at 3:00 PM, Phil Van <pv2100 [at] gmail> 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


perrin at elem

Jun 27, 2011, 7:23 AM

Post #42 of 50 (1581 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

On Sun, Jun 26, 2011 at 5:11 PM, Randolf Richardson <randolf [at] modperl> 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


fred at redhotpenguin

Jun 27, 2011, 8:37 AM

Post #43 of 50 (1587 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

On Sun, Jun 26, 2011 at 10:55 PM, Octavian Rasnita <orasnita [at] gmail> wrote:
> From: "Randolf Richardson" <randolf [at] modperl>
>> 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.


jmccarre at akamai

Jun 27, 2011, 11:44 AM

Post #44 of 50 (1581 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

On 6/27/11 8:37 AM, "Fred Moyer" <fred [at] redhotpenguin> 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.


jmccarre at akamai

Jun 27, 2011, 12:00 PM

Post #45 of 50 (1576 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

On 6/27/11 11:44 AM, "McCarrell, Jeff" <jmccarre [at] akamai> 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


orasnita at gmail

Jun 27, 2011, 12:53 PM

Post #46 of 50 (1579 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

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" <fred [at] redhotpenguin>
To: "Octavian Rasnita" <orasnita [at] gmail>
Cc: <randolf [at] modperl>; "mod_perl list" <modperl [at] perl>
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 <orasnita [at] gmail> wrote:
>> From: "Randolf Richardson" <randolf [at] modperl>
>>> 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.


david at kineticode

Jun 27, 2011, 1:10 PM

Post #47 of 50 (1577 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

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


mkanat at bugzilla

Jul 2, 2011, 12:38 AM

Post #48 of 50 (1569 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

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/


davehodg at gmail

Jul 2, 2011, 2:05 AM

Post #49 of 50 (1554 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

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.


bac2bac at bac2bac

Jul 4, 2011, 9:43 AM

Post #50 of 50 (1537 views)
Permalink
Re: How do you use mod_perl for your web application? [In reply to]

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.

First page Previous page 1 2 Next page Last page  View All ModPerl modperl RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.