Loading ...
Sorry, an error occurred while loading the content.
 

Re: Help!

Expand Messages
  • Warren Young
    ... 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
    Message 1 of 5 , Oct 7, 2004
      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@...
      For additional commands, e-mail: asp-help@...
    • Josh Chamas
      ... 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
      Message 2 of 5 , Oct 8, 2004
        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@...
        For additional commands, e-mail: asp-help@...
      • Mike Cantone
        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 -
        Message 3 of 5 , Oct 11, 2004
          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@...
          > For additional commands, e-mail: asp-help@...
          >


          ---------------------------------------------------------------------
          To unsubscribe, e-mail: asp-unsubscribe@...
          For additional commands, e-mail: asp-help@...
        • Josh Chamas
          ... 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,
          Message 4 of 5 , Oct 12, 2004
            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@...
            For additional commands, e-mail: asp-help@...
          Your message has been successfully submitted and would be delivered to recipients shortly.