Re: Re: 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.

Comment on Re: Re: Speeding up commercial Web applications

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.	[reply]
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. Abigail	[reply]
Re: Speeding up commercial Web applications by PotPieMan (Hermit) on May 08, 2003 at 13:09 UTC
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.	[reply]


Pathologically Eclectic Rubbish Lister
	PerlMonks