Edit report at http://bugs.php.net/bug.php?id=52103&edit=1

 ID:               52103
 User updated by:  chris at leaflock dot net
 Reported by:      chris at leaflock dot net
 Summary:          Using oci_connect causes PHP to take a long time to
                   finish
 Status:           Duplicate
 Type:             Bug
 Package:          OCI8 related
 Operating System: RHEL Server 5.1
 PHP Version:      5.3.2
 Assigned To:      sixd

 New Comment:

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?


Previous Comments:
------------------------------------------------------------------------
[2010-06-16 20:44:51] s...@php.net

----------------------

Duplicate of http://bugs.php.net/bug.php?id=51610

------------------------------------------------------------------------
[2010-06-16 20:13:49] 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.


------------------------------------------------------------------------



-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52103&edit=1

Reply via email to