Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re: Re: Speeding up commercial Web applications

by PotPieMan (Hermit)
on May 08, 2003 at 02:31 UTC ( [id://256454] : note . print w/replies, xml ) Need Help??

in reply to Re: Speeding up commercial Web applications
in thread Speeding up commercial Web applications

I apologize for not describing the profile. Out of the ~10 seconds, the breakdown is something like the following:
  • 1 second on startup - database connection, etc.
  • 1-2 seconds on database work
  • 6-7 seconds on "processing"

It's the "processing" step that causes so much trouble, since we can't make major modifications to the code.

And we have definitely thought about buying a better product, or writing one in house. Ugh.

Replies are listed 'Best First'.
Re: Re: Re: Speeding up commercial Web applications
by perrin (Chancellor) on May 08, 2003 at 02:46 UTC
    You can probably get it to work under PerlRun. That would completely eliminate the startup time. It won't help with the processing time though. For that, you really have to profile things and change code. The only generic piece of advice I can offer is to run perl 5.6.1 compiled with no threads, since it seems to have better performance than later perl versions.

    Incidentally, FastCGI and SpeedyCGI have the same limitations as mod_perl when running poorly written code. PerlRun does a better job than either of them do at trying to make things work.

Re: Speeding up commercial Web applications
by Abigail-II (Bishop) on May 08, 2003 at 07:33 UTC
    Well, then you can save at most 1 second by changing the program to be both mod_perl (or something similar) aware, and by using some database connection pooling mechanism. You might be able to save a little on the database work by using different indices or a different layout. But that also saves you at most 2 seconds.

    The majority of the possible savings will be from changing the code. But you say you can't make major modifications. There isn't a magical wand you can wave that instantly makes all programs faster. So, I'd say, your task is impossible.


      We are reluctant to make modifications because we want the product to still be the product, if that makes any sense. Along the same lines, investing a lot of programmer time in changing the code now probably means investing a lot of time in changing the code when we upgrade.

      If you can't tell, I don't have much faith in this product.