|  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
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: chris at leaflock dot net
New email:
PHP Version: OS:


 [2010-06-16 20:13 UTC] chris at leaflock dot net
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 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

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

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 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

Test script:

#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.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-06-16 20:41 UTC]
-Status: Open +Status: Assigned -Assigned To: +Assigned To: sixd
 [2010-06-16 20:44 UTC]
-Status: Assigned +Status: Duplicate
 [2010-06-16 20:44 UTC]
Duplicate of
 [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  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 and not
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Jul 16 10:01:28 2024 UTC