Before you try to wrap your head around the mod_perl book (I think I've read through it twice, and still don't get all of the intimate details), you might want to try to determine where the bottleneck is, and tune that part.
<p.
If the problem is your database, enter 'mysql tuning' into your favorite search engine, and you should hopefully find good advice, such as:
And make sure, before you start tuning that you set a goal ... choose a performance metric, and work until you hit that number. Otherwise, you can run the risk of optimization obsession, and you spend days trying shave another 1/10th of a second off of your execution time, when it might be better spent on other tasks.
| [reply] |
Good point, but the mod_perl book also has a lot of help for finding the bottleneck, using the Perl profiler and the DBI profiler.
| [reply] |
The biggest bangs for the buck:
- pre-loading modules in startup.pl and not scribbling on shared data - reduces both memory usage and response time by up to 30% each
- Correct database schema - reduces SQL query response time by up to 90%
- Usage of CPAN modules - reduces response time by up to 30%
Those numbers are cumulative. I've seen a report go from 270 seconds to 3 seconds, just by following those three items.
- In general, if you think something isn't in Perl, try it out, because it usually is. :-)
- "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
| [reply] |
| [reply] |