Mailing List Archive: ModPerl: ASP

Help!

Index | Next | Previous | View Threaded

mcantone at skarven

Oct 7, 2004, 1:27 PM

Post #1 of 5 (2055 views)
Permalink

Help!

I have one remaining, but somewhat glaring problem. After I use my ASP
application for a little while (not really that long actually - maybe a
dozen transactions), the exact same user behavior seems to cause the
transaction to hang. The response times seem to get a bit worse and a
bit worse until finally it changes doesn't come back. I usually end up
restarting the web server at this point (hard to do in production!)
and it doesn't seem to die easily. I issue a couple of stops - sometimes
as many as 3-4 until it reports actually being stopped. Then I clear out
the session cache, restart and it seems fine. If I don't clear out the
session cache, I think it predictably is still in a funky state -
certainly much of the time it is.

I thought maybe the Reload directive I was using for development (to
force the Perl Modules to get reloaded when they have been changed)
might be using up a lot of memory, but commenting this out doesn't
really seem to help things.

The application I'm testing doesn't store a lot in session though I've
specified MLDBM for StateDB. If the session data *were* growing too
large, is there any warning? Do I just lose session data or do I
crash/hang? As I said though, I am using the recommended MLDBM.

P.S. This is considerably lower priority (unless it is related to the
above somehow), but is there any difference between using IncludesDir
directive and PerlSwitches -I directives? Advantages/disadvantages?

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe [at] perl
For additional commands, e-mail: asp-help [at] perl

warren at etr-usa

Oct 7, 2004, 2:45 PM

Post #2 of 5 (1961 views)
Permalink

Re: Help! [In reply to]

Mike Cantone wrote:
> might be using up a lot of memory,

Stop guessing and measure! Does your platform have a top command? You
can use that to see CPU time and memory usage. If not, you may have sar
or some other system load testing utility.

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe [at] perl
For additional commands, e-mail: asp-help [at] perl

josh at chamas

Oct 8, 2004, 7:56 AM

Post #3 of 5 (1938 views)
Permalink

Re: Help! [In reply to]

Mike Cantone wrote:
>
> The application I'm testing doesn't store a lot in session though I've
> specified MLDBM for StateDB. If the session data *were* growing too
> large, is there any warning? Do I just lose session data or do I
> crash/hang? As I said though, I am using the recommended MLDBM.
>

MLDBM is not a valid setting for StateDB. Try DB_File or GDBM_File
if you are storing a lot of data there, but if you are, know that it
will slow things down considerably.

Also, heed Warren's advice on measuring, not guessing.

If you need a trace level view of Apache::ASP execution, set "PerlSetVar Debug -3"
in your httpd.conf, and restart your web server. There should be low level
execution traces occuring then in your apache error_log.

Regards,

Josh

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe [at] perl
For additional commands, e-mail: asp-help [at] perl

mcantone at skarven

Oct 11, 2004, 1:16 PM

Post #4 of 5 (1938 views)
Permalink

Re: Help! [In reply to]

I'm optimistic I am on the crux of solving this problem with the help of
some collective knowledge.

My ASP application can handle between 20-40 transactions - then it seems
to turn into a runaway process. The memory consumption according to top
is well under 1%, however the CPU for httpd goes into the high 90th
percentile. My application calls swish-e indexing and I found a very
interesting reference on the net which describes what seems to be the
identical problem here: http://mathforum.org/epigone/modperl/fraplahswo
. One of their recommendations is to put an AUTOLOAD in mod perls
startup.pl to see what is happening and, as was the case in the thread,
I can now see that lots of DESTROYs are not getting found.

The majority of these DESTROYs however probably don't really exist, but
a method that can't be found that looks like a real problem is
Apache::Connection::fileno. Josh mentioned fixing this in some of his
change notes for versions of modperl that didn't support this. I don't
know who is looking for this method - I don't know whether it is ASP or
not. I am using Apache 2.0.x which doesn't allow me to use modperl 1.0
(seems to want Apache 1.3), so I am using modperl "2.0" - the dev
version. Where I can find the Apache::Connection.pm module, fileno truly
is not defined, but what is not clear to me is what I can do about it.
Moving to a 1.3 version of Apache is not an option for me - too many
others rely on 2.0. Any ideas?

-Mike

Josh Chamas wrote:
> Mike Cantone wrote:
>
>>
>> The application I'm testing doesn't store a lot in session though I've
>> specified MLDBM for StateDB. If the session data *were* growing too
>> large, is there any warning? Do I just lose session data or do I
>> crash/hang? As I said though, I am using the recommended MLDBM.
>>
>
> MLDBM is not a valid setting for StateDB. Try DB_File or GDBM_File
> if you are storing a lot of data there, but if you are, know that it
> will slow things down considerably.
>
> Also, heed Warren's advice on measuring, not guessing.
>
> If you need a trace level view of Apache::ASP execution, set "PerlSetVar
> Debug -3"
> in your httpd.conf, and restart your web server. There should be low level
> execution traces occuring then in your apache error_log.
>
> Regards,
>
> Josh
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: asp-unsubscribe [at] perl
> For additional commands, e-mail: asp-help [at] perl
>

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe [at] perl
For additional commands, e-mail: asp-help [at] perl

josh at chamas

Oct 12, 2004, 10:13 PM

Post #5 of 5 (1976 views)
Permalink

Re: Help! [In reply to]

Mike Cantone wrote:
> I'm optimistic I am on the crux of solving this problem with the help of
> some collective knowledge.
>
> My ASP application can handle between 20-40 transactions - then it seems
> to turn into a runaway process. The memory consumption according to top
> is well under 1%, however the CPU for httpd goes into the high 90th
> percentile. My application calls swish-e indexing and I found a very
> interesting reference on the net which describes what seems to be the
> identical problem here: http://mathforum.org/epigone/modperl/fraplahswo
> . One of their recommendations is to put an AUTOLOAD in mod perls
> startup.pl to see what is happening and, as was the case in the thread,
> I can now see that lots of DESTROYs are not getting found.
>

I would recommend looking into BSD::Resource for per process limits setting.
IF Apache::Resource has been ported to mod_perl 2.0, I would look
at that too, which wraps around BSD::Resource nicely.

> The majority of these DESTROYs however probably don't really exist, but
> a method that can't be found that looks like a real problem is
> Apache::Connection::fileno. Josh mentioned fixing this in some of his
> change notes for versions of modperl that didn't support this. I don't
> know who is looking for this method - I don't know whether it is ASP or
> not. I am using Apache 2.0.x which doesn't allow me to use modperl 1.0
> (seems to want Apache 1.3), so I am using modperl "2.0" - the dev
> version. Where I can find the Apache::Connection.pm module, fileno truly
> is not defined, but what is not clear to me is what I can do about it.
> Moving to a 1.3 version of Apache is not an option for me - too many
> others rely on 2.0. Any ideas?

The code that references fileno should be safe, even if it does not exist:

# Apache::ASP::Response->IsClientConnected
my $fileno = eval { $conn->fileno };

If you really want this code to not do what its doing,
then you could define this after loading Apache::ASP:

sub Apache::ASP::Response::IsClientConnected {
shift->{IsClientConnected} = 1;
}

And your application should work fine still regardless of whether
this is a real fix for your problem. I am guessing that the real
root of this problem is something else, and you will find your fix
best in BSD::Resource. Also, if you are using worker mpm, I probably
wouldn't, and would be wary of using BSD::Resource in this case.
I would stick with the prefork mpm in Apache 2.

Regards,

Josh

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe [at] perl
For additional commands, e-mail: asp-help [at] perl

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads