http://www.perlmonks.org?node_id=989942


in reply to mod_perl vs php performance when accessing Oracle under load

The first job when optimizing is to find out what takes the most time. I highly recommend Devel::NYTProf, it looks like Devel::NYTProf::Apache is taylored for your use case.

One difference is that you use different SELECT queries in PHP and in Perl, and never retrieve any values. It could be that PHP simply doesn't execute the query before you try to fetch a result, so to make the comparison useful, run the same query in both scripts and also retrieve the result.

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

Replies are listed 'Best First'.
Re^2: mod_perl vs php performance when accessing Oracle under load
by amasidlover (Sexton) on Aug 27, 2012 at 09:14 UTC

    We've been using Devel::NYTProf::Apache for analysing the main application, so I can have a go at that.

    In the meantime I stripped out everything except the lines:

    my $r = shift; $r->content_type('text/plain'); $r->print("Errors: $err\n"); return Apache2::Const::OK;

    And it was still giving 1700ms per request - suggesting that its not the DB access at all...

    The SELECT difference was a cut and paste error, the scripts on the server do both have the WHERE clause.

      I'm now struggling to get NYTProf to do what I need it seems to be only writing one request's worth of data when actually I'm expecting it to write 300 files all with 10 or so requests in.

      PerlModule Devel::NYTProf::Apache PerlSetEnv NYTPROF file=/tmp/nytprof.out:addpid=1:endatexit=1

      I can't really set MaxClients to 1 as the large response times don't occur without the concurrency.

      The timings that are written out show a total of only just over 100ms even including the DB connect - which I assume I'm getting because its only logging my first request. Excluding the connect its about 30ms of time.

      What I'm struggling with is how to translate one request into concurrent requests (for the purposes of estimating timing) - particularly when I'm seeing requests that with no DB activity show 1700ms average response time and with DB calls in there show 1800ms average response time. It suggests to me that something outside of my handler is taking the majority of the response time up when concurrency gets 'high'

      The detailed results from 'ab' show the following:

      Connection Times (ms) min mean[+/-sd] median max Connect: 48 1223 1633.2 918 14262 Processing: 2 611 368.2 573 1542 Waiting: 2 228 167.0 192 679 Total: 75 1833 1626.0 1705 14860

      So the connect is definitely a big part...

      OOOPS!!! Just been back and double checked the PHP results - turns out the PHP version I'd missed the 's' in the URL i.e. http and not https.

      They now give similar results! Lets see if I can now do something productive with the other half of my day...