php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #52263 Script cleanup takes long with Oracle 11 instant client
Submitted: 2010-07-06 15:49 UTC Modified: 2010-07-06 16:59 UTC
From: andrew at digicol dot de Assigned:
Status: Not a bug Package: OCI8 related
PHP Version: 5.3.2 OS: Linux
Private report: No CVE-ID: None
 [2010-07-06 15:49 UTC] 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


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-07-06 16:03 UTC] 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 16:25 UTC] johannes@php.net
-Status: Open +Status: Bogus
 [2010-07-06 16:26 UTC] johannes@php.net
Expected behavior. See bug #51610.
 [2010-07-06 16:59 UTC] andrew at digicol dot de
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?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Dec 26 15:01:32 2024 UTC