> > 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 [EMAIL PROTECTED] For technical support, please email [EMAIL PROTECTED] |
