php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #52103 Using oci_connect causes PHP to take a long time to finish
Submitted: 2010-06-16 20:13 UTC Modified: 2010-06-16 21:15 UTC
From: chris at leaflock dot net Assigned: sixd (profile)
Status: Duplicate Package: OCI8 related
PHP Version: 5.3.2 OS: RHEL Server 5.1
Private report: No CVE-ID: None
 [2010-06-16 20:13 UTC] chris at leaflock dot net
Description:
------------
NOTE: all of this happens when using PHP from the command line, don't know about other cases, that is harder to measure.

Using oci_connect with PHP 5.3.2 (or 5.3.1 or snap php5.3-201006161430) against Oracle 10.2.0.4 causes a PHP script to hang for about a second after all code has been run.  Script doesn't crash, just takes way too long to finish.

i.e. one can do something like this

 print "FIRST LINE OF CODE\n";
 oci_connect('user', 'pass');
 print "LAST LINE OF CODE\n";

and after "LAST LINE OF CODE" is printed, the program will hang for about a second, then finish.  If you remove the oci_connect line, the program runs without any post-code hangup.  PHP 5.2 on the same machine runs with no problems.

Note: the problem happens if the user/pass are correct or not.

What works and what doesn't against Oracle 10.2.0.4:

PHP 5.2              (oci8 1.2.4)     -> works fine
PHP 5.3.1            (oci8 1.3.5)     -> hangs for around one second
PHP 5.3.2            (oci8 1.4.1)     -> hangs for around one second
PHP 5.3-201006161430 (oci8 1.4.2-dev) -> hangs for around one second

What works and what doesn't against Oracle 10.2.0.3:

PHP 5.2              (oci8 1.2.4)     -> works fine
PHP 5.3.1            (oci8 1.3.5)     -> works fine
PHP 5.3.2            (oci8 1.4.1)     -> works fine
PHP 5.3-201006161430 (oci8 1.4.2-dev) -> works fine

Seems to be related to 10.2.0.4 and certain versions of PHP's oci8.

All these PHP's were built with the same configure line:
./configure --prefix=/opt/php --with-oci8 --with-apxs2=/opt/apache2/bin/apxs --enable-ftp --with-xmlrpc --with-iconv --with-curl --with-pear --enable-pcntl --with-zlib --with-readline

I have tested everyone of the above PHP's using 'php -n' (no php.ini).

Again, the bug only manifests on Oracle 10.2.0.4.

Test script:
---------------
<?php

#run this script from the command line with the 'time' command on linux, like so, to see the problem:
#
# time php -n myscript.php
#

print "before connect: ".microtime(true)."\n";

oci_connect('user', 'pass');

print "after connect: ".microtime(true)."\n";

#Note that the slowdown isn't bound to oci_connect,
#The two print statements will happen BEFORE the slowdown occurs,
#i.e. after all PHP code has been processed.

#using strace on the script with the '-c' is also interesting...

?>


Expected result:
----------------
I expect the script to complete in .05 to .15 seconds (or so).

Actual result:
--------------
Script takes at least a full second to finish, after all code has been executed.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-06-16 20:41 UTC] johannes@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: sixd
 [2010-06-16 20:44 UTC] sixd@php.net
-Status: Assigned +Status: Duplicate
 [2010-06-16 20:44 UTC] sixd@php.net
----------------------
Duplicate of http://bugs.php.net/bug.php?id=51610
 [2010-06-16 21:15 UTC] chris at leaflock dot net
I got it, this is expected behavior.

Why, then doesn't it happen on Oracle 10.2.0.3?  Is this documented anywhere?

I'm all for enhancements, but "by the way, use of this function is several times slower" doesn't seem like much of an enhancement...

I think it is fair to say this is a drastic change from expected behavior, this should REALLY be blinking 'red' in the docs.

Again, why in 10.2.0.4 and not 10.2.0.3?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 12:01:27 2024 UTC