in reply to mod_perl vs php performance when accessing Oracle under load
Even though you say, “Solved!” based on a difference of having or not-having https turned on, obviously there must be something more in play here. PHP is a fine, well-built system, but it cannot be 10 times faster just on its own coding merits. SSL should not knock-off that much speed, although it does pay a one-time cost at connect time for key-negotiation. (Are your benchmarks connecting every single time? Quite possibly, and that’s not realistic.)
You should frankly but politely question why your customer is presenting a PHP vs. Perl comparison because it is an apples-to-oranges comparison ... but there must be some motivation for it. Are they talking right now to a competitor who is promising them the moon?
You need to continue to pursue the strategy of systematically testing how the application actually spends its time, and what gives rise to the perception of “response time.” as seen by the user. It is often helpful to attach instrumentation to the back-end portions of the system, i.e. to the objects that it uses to do actual work, using test-rigs that are not associated with the web server processes.
Many web-sites burn up a lot of time with “set-up / tear-down costs” which they pay every time for every request: they connect to the database server, then tear that connection down a few milliseconds later. They prepare dozens or even hundreds of individual queries which the database server has no choice but to parse “as though it had never seen it before,” set up, execute, then tear down. Since these actions involve a lot of resources and multiple processes and/or computers (hence, fiber optics or patch cables), they not only add-up quickly, but they also degrade non-linearly under load.
Bear in mind that it really makes no difference whether the application is done in mod_perl or not: while this does implement “a persistent handler-process,” in this case by stuffing Perl right into the Apache worker-bees, the effective use of persistence is a fundamental design point that has to be engineered into the thing from the start. Apps are frequently designed, then shoehorned into mod_perl or FastCGI “to make them run faster,” but the design doesn’t really change. And they do run somewhat faster, especially on the too-lightly loaded developer’s systems, which superficially seems to exonerate the strategy.