Re: mod_perl vs php performance when accessing Oracle under load

You should be able to gain a small speed boost by using a non-threaded version of Perl, plus, there's always the Advanced Perl DBI talk. DBI's prepare_cached might help for some cases of repeated statements, too.

Anyway, I do not see anything wrong with your test code as you have laid it out (and was certain that the likely culprit was CGI.pm). I trust that your production code is of similar quality, and hope that the apples-to-oranges comparison by your client was, well, apples and oranges. And not HTTP to HTTPS...

Comment on Re: mod_perl vs php performance when accessing Oracle under load Download Code

Replies are listed 'Best First'.
Re^2: mod_perl vs php performance when accessing Oracle under load by liz (Monsignor) on Aug 28, 2012 at 08:02 UTC
FWIW, when moving from a threaded perl to an identical unthreaded version of Perl at $work, in practice the difference in performance hardly made it above noise levels (as in less than 1%). This was quite disappointing. So, the Perl test-suite may run 15% faster without threads, but your real life application gains may be a lot less. I guess the test-suite just exercises the expensive unthreaded code paths on a threaded perl more than in the real world.	[reply]

Replies are listed 'Best First'.

Re^2: mod_perl vs php performance when accessing Oracle under load
by liz (Monsignor) on Aug 28, 2012 at 08:02 UTC

So, the Perl test-suite may run 15% faster without threads, but your real life application gains may be a lot less. I guess the test-suite just exercises the expensive unthreaded code paths on a threaded perl more than in the real world.

[reply]