Richard.Hyde at cnet
Oct 18, 2006, 3:15 PM
Post #3 of 4
(1386 views)
Permalink
|
On Fri, 2006-10-06 at 06:20 +0200, Gerald Richter wrote:
> >
> > We just deployed and then un-deployed a version of our
> > application that was converted to embperl2. While it
> > appeared to be faster initially, each web server would drive
> > itself under (all dual 2.6 to 3.2 Ghz Xeon servers) with load
> > after about 40 minutes, sometimes significantly quicker).
> > I can't set the blame entirely on Embperl as that wasn't the
> > only thing that changed. We were forced to convert from a
> > statically linked mod_perl to a DSO mod_perl. Unfortunately
> > I can't revert back to a statically linked mod_perl with
> > Embperl 2.2.0 because Embperl 2 segfauilts (actually a
> > segfault loop when Embperl is loaded). I can't try Embperl
> > 1.3 with a DSO because Embperl segfaults (on apache startup).
> >
> > First, are these segfault situations known?
> > If not what's the best way of going about getting debugging info?
> >
> > We're currently using:
> > Perl 5.8.5
> > Apache 1.3.29 (though when debugging I tried 1.3.37 as well)
> > mod_perl 1.29 Embperl 1.3.6 (and then Embperl 2.2.0)
> >
>
> I don't expect Embperl to be the problem, as I know from sites with serveral
> 100 000 Embperl page hits a day and I don't have this problem either.
>
> Also for performance it doesn't makes a difference if mod_perl is staticly
> or dynamicly loaded.
>
> On Apache 1.3 Embperl 2 should also work with a staticly linked mod_perl
> (Apache 2 requires mod_perl as DSO).
> The segfault might be a result on how you load Embperl.pm in your
> httpd.conf.
How may ways are there? Our loading was via a httpd.conf include, via
PerlModule calls (and not via a perl block or startup.pl or similar).
>
> For the performance it would first take a look at the memory usage. Is it
> increasing over time?
>
Yes and no. Per process memory usage was in line with our Embperl1
versions. We were using far more RAM (on 6GB web servers) due to the
large number of Apache processes that were required to handle incoming
requests (because the older processes were busy using 100% CPU and not
returning data to the clients).
________________________________________________________________________
Richard "Trey" Hyde
Lead Software Engineer, CNET Channel
(949) 399 8722
Richard.Hyde [at] cnet
For technical support, please email channelsupport [at] cnet
|
