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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
