If you had any more details that you could post here, you might get a lot of help that way, right now.

For instance, I have no idea what your “specialists” mean when they say that “the hand-over to mod_perl fails.”   If it actually did that, you’d be getting a 500 Internal Server Error ... not “serious performance issues.”   mod_perl is a tool that embeds a Perl interpreter right into the Apache worker-processes, and, basically, either the request is received and processed and the program’s output is returned as the new web-page contents that you see ... or you get an internal server error or 404 Not Found.   I’m afraid that I just don’t think too highly of your “specialists,” based on this description.   (Of course, that’s all I have to go on, so take it with appropriate salt.)

Performance issues in mod_perl sites often come down to one of four things, when they used to be running okay on the same hardware and they suddenly stop doing it:

1. An unresolved bug in the programming of the site.   If you use a change-control system to manage the source code (as you should), you can use it to examine changes that had recently been made, shortly before the point in time when the site began misbehaving.
2. Resource over-commitment (or, undiagnosed hardware issues); unrecognized networking problems.   (A router can be blinking merrily away and still be misbehaving.)
3. SQL or back-end operations taking much too long, e.g. because a table index has been disabled or dropped.
4. In general, something changed.   Maybe you didn’t know it, maybe it was done improperly, maybe you didn’t understand or have not yet found its impact.   (This is why I keep a “running log” on all machines ... with a paper notebook and a pencil.   Never trust your ... your ... oh, nevermind, I forgot what I was going to say ...)

And the first question that I always ask is:   “when did this start happening?”   The follow-on question is:   “All right, so what happened the week before that?”

• Read chapters 7 and 8