Edit report at http://bugs.php.net/bug.php?id=52263&edit=1
ID: 52263 User updated by: andrew at digicol dot de Reported by: andrew at digicol dot de Summary: Script cleanup takes long with Oracle 11 instant client Status: Bogus Type: Bug Package: OCI8 related Operating System: Linux PHP Version: 5.3.2 New Comment: Ok, thanks for the pointer to the other bug report. This is in fact exactly the same issue. However, I cannot subscribe to the statement that has been made there: "Most deployments either do not start and stop PHP processes frequently, or are not sensitive to the time between completing the work of the script and the termination of the process." We use a "find <dir> -name '*.xml' | php do_some_work.php -" style approach. The actual execution time of the script is < 100 milliseconds. Adding 1 second to each invocation makes the whole thing slower by factor 10. We could change the whole procedure to minimize PHP script invocations, of course. But a one second overhead is quite hefty, isn't it? Is there any chance this will be configurable if you don't need DRCP or FAN? Previous Comments: ------------------------------------------------------------------------ [2010-07-06 16:26:00] johan...@php.net Expected behavior. See bug #51610. ------------------------------------------------------------------------ [2010-07-06 16:03:00] andrew at digicol dot de There is a logical fault in the script that I pasted - the calculation of the elapsed time should be after the disconnect ( sorry, this happened while stripping down the original test script to a simpler one). This does not affect the described behavior, though - the pause is still there: ... if ($conn === false) die("ocilogon failed\n"); list($usec, $sec) = explode(' ', microtime()); $now = ((float)$usec + (float)$sec); $elapsed = $now - $stime; fwrite(STDOUT, $elapsed . "\n"); ------------------------------------------------------------------------ [2010-07-06 15:49:26] andrew at digicol dot de Description: ------------ PHP scripts that connect to an Oracle 11gR2 database server using version 11 clients (instant client, fat client) hang for approx. one second after the last command in the script has been executed. === version 11 client === PHP was build with the following configure option: --with-oci8=--with-oci8=instantclient,/usr/local/lib64/instantclient/instantclient_11_2 Executing the test script results in: $ time php oci_connect.php 0.0691978931427 real 0m1.119s user 0m0.055s sys 0m0.058s The first value is printed as the last statement in the script. It will not return immediately to the command-line, but hang noticeably for approx. 1 second. When commenting out the two OCI-related statements the script returns immediately. This may also be a bug in the Oracle client libraries, I am not sure. But the one second pause does not happen when connect and disconnecting with sqlplus: time echo -e "exit\n" | sqlplus *****/*****@//*****/***** SQL*Plus: Release 11.2.0.1.0 Production on Thu Jul 1 16:56:11 2010 Copyright (c) 1982, 2009, Oracle. All rights reserved. Connected to: Oracle Database 11g Release 11.2.0.1.0 - 64bit Production >Disconnected from Oracle Database 11g Release 11.2.0.1.0 - 64bit Production real 0m0.063s user 0m0.018s sys 0m0.011s Test script: --------------- oci_connect.php: <?php list($usec, $sec) = explode(' ', microtime()); $stime = ((float)$usec + (float)$sec); $conn = ocilogon('user', 'pass', 'host/service'); if ($conn === false) die("ocilogon failed\n"); list($usec, $sec) = explode(' ', microtime()); $now = ((float)$usec + (float)$sec); ocilogoff($conn); if ($conn === false) die("ocilogon failed\n"); $elapsed = $now - $stime; fwrite(STDOUT, $elapsed . "\n"); ?> Expected result: ---------------- I would expect the same behavior as with the Oracle 10 client libraries: === version 10 client === When PHP is built against the older, release 10 libraries, this does not happen: --with-oci8=--with-oci8=instantclient,/usr/local/lib64/instantclient/instantclient_10_2 Executing the test script results in: $ time php oci_connect.php 0.0691978931427 real 0m0.161s user 0m0.052s sys 0m0.068s ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/bug.php?id=52263&edit=1