Performance issue

This is a multi-part message in MIME format.

------_=_NextPart_001_01C92AE7.EC2FF0CA
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have an AIX 5.2 (16 GB RAM), Apache 2.2.8, MySQL 5.0.51a and mod_per
2.04 environment. I had a Perl cgi-bin program using CGI.pm that I
converted to work in mod_perl. The converted script still uses CGI.pm
and is now enabled in Apache via:

PerlModule ModPerl::Registry
Alias /perl/ /usr/local/apache2/perl/

SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
Order allow,deny
Allow from all


I have my startup.pl containing:

use Apache::DBI;
use DBI();

Called in httpd.conf with:

PerlPostConfigRequire /usr/local/apache2/scripts/startup.pl

Apache was compiled with --with-mpm=3Dprefork

All webpages are accessed using SSL. I am investigating offloading SSL,
but that will take a few months to accomplish.

If only a few users are using the application then performance is fine.
By this I mean the display of a MySQL query to a webpage takes a few
seconds. Once we get over 20 users performance degrades to about 45
seconds.

Any tips would be appreciated.

------_=_NextPart_001_01C92AE7.EC2FF0CA
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




charset=3Dus-ascii">
6.5.7652.24">

I have an AIX 5.2 (16 GB RAM), Apache =
2.2.8, MySQL 5.0.51a and mod_per 2.04 environment.  I had a Perl =
cgi-bin program using CGI.pm that I converted to work in mod_perl.  =
The converted script still uses CGI.pm and is now enabled in Apache =
via:

PerlModule ModPerl::Registry


Alias /perl/ =
/usr/local/apache2/perl/


<Location /perl/>


    SetHandler =
perl-script


    PerlResponseHandler =
ModPerl::Registry


    PerlOptions =
+ParseHeaders


    Options =
+ExecCGI


    Order =
allow,deny


    Allow from =
all


</Location>

I have my startup.pl containing:

use Apache::DBI;


use DBI();

Called in httpd.conf with:

PerlPostConfigRequire  =
/usr/local/apache2/scripts/startup.pl

Apache was compiled with =
--with-mpm=3Dprefork

All webpages are accessed using =
SSL.  I am investigating offloading SSL, but that will take a few =
months to accomplish.

If only a few users are using the =
application then performance is fine.  By this I mean the display =
of a MySQL query to a webpage takes a few seconds.  Once we get =
over 20 users performance degrades to about 45 seconds.

Any tips would be appreciated.

Re: Performance issue

Brian Gaber wrote:
> I have an AIX 5.2 (16 GB RAM), Apache 2.2.8, MySQL 5.0.51a and mod_per
> 2.04 environment. I had a Perl cgi-bin program using CGI.pm that I
> converted to work in mod_perl. The converted script still uses CGI.pm
> and is now enabled in Apache via:
>
> PerlModule ModPerl::Registry
> Alias /perl/ /usr/local/apache2/perl/
>
> SetHandler perl-script
> PerlResponseHandler ModPerl::Registry
> PerlOptions +ParseHeaders
> Options +ExecCGI
> Order allow,deny
> Allow from all
>
>
> I have my startup.pl containing:
>
> use Apache::DBI;
> use DBI();
>
> Called in httpd.conf with:
>
> PerlPostConfigRequire /usr/local/apache2/scripts/startup.pl
>
> Apache was compiled with --with-mpm=prefork
>
> All webpages are accessed using SSL. I am investigating offloading SSL,
> but that will take a few months to accomplish.
>
> If only a few users are using the application then performance is fine.
> By this I mean the display of a MySQL query to a webpage takes a few
> seconds. Once we get over 20 users performance degrades to about 45
> seconds.
>
> Any tips would be appreciated.

While a good route to optimization would be to implement Apache::DProf
(http://search.cpan.org/dist/Apache-DB), a delay of 45 seconds is quite
large and I am guessing that if you enabled query timing in MySQL you
could identify the offending queries in your mysql log and start from there.

Apache::DProf is generally good at taking your request times from 5
seconds to 0.05 seconds, but given a 45 second delay on a page that runs
a database query, I'd look at your database performance first.