in reply to Speeding up commercial Web applications

Without knowing anything about the application, it's very hard to say what to do. If of the 10 seconds it takes, it spends 9.5 in the database, don't bother speeding up the code - speed up your database. If it spends a lot of time doing I/O, get faster disks, a better controller, or more memory. If you are sure it's the code, find the bottleneck(s), and rewrite that, perhaps in C.

Or buy a better product.

Abigail

  • Comment on Re: Speeding up commercial Web applications

Replies are listed 'Best First'.
Re: Re: Speeding up commercial Web applications
by PotPieMan (Hermit) on May 08, 2003 at 02:31 UTC
    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.

[reply]
      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]
      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]
        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]

In Section Seekers of Perl Wisdom