|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2010-04-20 05:24 UTC] marioroy at verizon dot net
Description:
------------
Is this normal to see the native OCI8 1.3.5 or later requiring additional time to
run code snippet shown below when accessing Oracle 10.2.0.4. I'm seeing this at
work as well (SUSE Linux). Therefore, I have stayed with OCI8 1.2.5 for the
moment.
Notice how the time is the same when using the PDO/OCI interface.
Test script:
---------------
# Native OCI8 Performance:
#
# PHP 5.2.14 201004191430, OCI8 1.2.5: ~ 0.15 seconds ;this is nice
#
# PHP 5.3.3 201004191430, OCI8 1.2.5: ~ 0.25 seconds ;takes 0.1 extra here
# PHP 5.3.3 201004191430, OCI8 1.3.5: ~ 1.20 seconds ;slowness begins when
# PHP 5.3.3 201004191430, OCI8 1.4.1: ~ 1.20 seconds ;script exits for 1.3.5+
# PHP 5.3.3 201004191430, OCI8 1.4.2: ~ 1.20 seconds
<?php
$conn = oci_connect('hr', 'hr', '//localhost:1521/mac10g');
if (!$conn) {
$e = oci_error();
trigger_error(htmlentities($e['message'], ENT_QUOTES), E_USER_ERROR);
}
oci_close($conn);
exit;
?>
# PDO/OCI Performance:
#
# PHP 5.2.14 201004191430, OCI8 1.2.5: ~ 0.15 seconds ;very fast
#
# PHP 5.3.3 201004191430, OCI8 1.2.5: ~ 0.15 seconds ;same as PHP 5.2.14 :)
# PHP 5.3.3 201004191430, OCI8 1.3.5: ~ 0.15 seconds ;very happy to see this
# PHP 5.3.3 201004191430, OCI8 1.4.1: ~ 0.15 seconds ;with 1.3.5+
# PHP 5.3.3 201004191430, OCI8 1.4.2: ~ 0.15 seconds
<?php
try {
$conn = new PDO('oci:dbname=127.0.0.1/mac10g', 'hr', 'hr');
}
catch (PDOException $e) {
trigger_error("Could not connect to database: ". $e->getMessage(), E_USER_ERROR);
}
$conn = NULL;
exit;
?>
Expected result:
----------------
I'm hoping that PHP 5.3.2+ with OCI8 1.4.1+ can perform as fast as PHP 5.2.13 with
OCI8 1.2.5 when using the native driver. This is why I have stayed with 1.2.5 at
work.
It wasn't until tonight that I saw the times the same via the PDO interface. That
made my day.
Actual result:
--------------
The native OCI8 1.3.5+ requires extra time to open/close and exit. The time delta
is 1 second for such a small code snippet.
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Tue Dec 03 16:01:33 2024 UTC |
I have applied this patch to oci8.c. It resolves the issue for me. I set use_spool to 0. Can we have use_spool enabled/disabled via an oci8.ini directive. Thanks. @@ -1711,7 +1693,7 @@ smart_str hashed_details = {0}; time_t timestamp; php_oci_spool *session_pool = NULL; - zend_bool use_spool = 1; /* Default is to use client-side session pool */ + zend_bool use_spool = 0; /* Default is to use client-side session pool */ zend_bool ping_done = 0;I wonder what issues the following patch would bring? Index: oci8.c =================================================================== --- oci8.c (revision 300858) +++ oci8.c (working copy) @@ -35,6 +35,7 @@ #include "php.h" #include "ext/standard/info.h" #include "php_ini.h" +#include "SAPI.h" #include "ext/standard/php_smart_str.h" #if HAVE_OCI8 @@ -3187,7 +3188,11 @@ PHP_OCI_CALL(OCIHandleFree, ((dvoid *) session_pool->err, OCI_HTYPE_ERROR)); } - if (session_pool->env) { + /* When PHP is invoked as a CLI then destruction of the + * Environment handle is left to the OS at PHP process shutdown. + */ + if (session_pool->env && !sapi_module.phpinfo_as_text) { PHP_OCI_CALL(OCIHandleFree, ((dvoid *) session_pool->env, OCI_HTYPE_ENV)); }