in reply to Re^2: Timing concerns on PerlEX/Mod_Perl
in thread Timing concerns on PerlEX/Mod_Perl

Anyone have any ideas on what to do now?

I know naff all about PerlEz or Mod_perl, but I would think the next thing to do is determine if it is all scripts on that server, or just this particular script.

Ie. Write a simple script that does nothing except produce the timing information as above.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."
  • Comment on Re^3: Timing concerns on PerlEX/Mod_Perl

Replies are listed 'Best First'.
Re^4: Timing concerns on PerlEX/Mod_Perl
by Anonymous Monk on Jul 26, 2008 at 03:54 UTC
    I isolating is kind of hard since I use one central code that loads functions. So it would pretty much means rewriting the entire code.

    What PerlEX and Mod_Perl do is they pre-load a lot of the variables and start up into memory and then execute threads that access the persistent data.

    personally I do not think im storing that much data into ram that would give it issues in spawning threads but it could be my use of namespaces :/..if there was only a way..maybe ISAPI component to monitor script start up or etc :/...or maybe some apache functions?

      You don't have rewrite or even change the script.

      Make a copy of it, with the timing code, under a different url.

      Comment out everything except the timing code and run it.

      Still the same effect?

      1. Yes: Your server set-up isn't what you think it is or it is screwed.
      2. No.
        1. Uncomment half the script.
        2. Run it again. Still okay?
          1. Yes: Uncomment half of the remaining code. Goto 2b
          2. No: Re-comment half the code you just uncommented. Goto 2b

      You'll rapidly find the line of the code that screwing you.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        Well if I run the script with 2-3 people using it. It runs hassle free. The issue happens when I make it live.(but CPU usage doesn't go up)

        I can try though..but since the code is written in a centralized environment. It is more dynamic, example:

        I write in html: <*Get List|type:all*>

        so only thing I can really comment out are the objects. Rest is kidna dependent. For a better understanding here is my code structure:

        I have 4 name spaces:

        main - the main namespace which calls the other namespaces and handles outputting of data from common(headers) and frame(html).

        common - stores all the basic stuff like opening files, accessing database and etc. it also loads query strings and headers.

        frame - loads the html, the advanced functions like login account and etc which is made up of calling the common. After loading HTML it loads the Skin namespace on the loaded html.

        Skin - loads the layout, all the images, textboxes, forms, assigns ids and other more advanced objects.



        Sigh..my urge to have a centralized structure is probably my biggest downfall..its good and convenient, but if the core has issues, makes it much harder to debug :(