• 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.

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.

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

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.