Re: [PHP] PHP + Oracle + OCIPLogon
Greetings! "Thies C. Arntzen" wrote: > On Thu, Jun 21, 2001 at 09:32:31PM +0300, Rouvas Stathis wrote: > > This has happened with other applications that I have experimented with. > > The "lingering connections" problem is with us at least since PHP.3.0.12 > > (which the first version of PHP I tried). > > That's why I say that PHP/Ora with *persistent* connection do not play > > well with each other. > i'm the author of this module and more than willing to help. > i do tests using the ab tool and have never found any > irregularities in the plogon mode. if you can show me how to > reproduce this i'm (mostly) sure i can fix it! I had the same problem some time ago on TWO different machines running their own Oracle database and the same PHP application. The problem makes me to always restart Apache so the open connections would die. The application was doing both a normal and a persistent connection on two different database tablespaces (differents users). One was always using OciPLogon and the other, OCILogon. The strange thing was that both connections were hold by Oracle as an open connection so I supposed that the OCIPLogon was holding the other connection, even if it was a normal one (non-persistent). One machine had to be restarted to hardware upgrade and after that it didn't show the problem anymore...and the PHP application was still THE SAME! Then I had two machines, with the same configuration (OS, DB Version, PHP App.) but one had this connection problems, and the other was just fine. Some time ago we decided to shut down the Oracle Server on the 'buggy machine' and start it again. The PHP application was still the same. No more problems. I could not say exactly what was going on but this is how it worked for me. I saw some 'bug reports' on Oracle, saying that some kind of changes on database layout, running together with a PHP application could cause Oracle to hold PHP db persistent connections. Hope this helps, -- Lucas PersonaICQ #17635618 [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] PHP + Oracle + OCIPLogon
"Thies C. Arntzen" wrote:
>
> On Fri, Jun 22, 2001 at 02:47:39AM +0300, Rouvas Stathis wrote:
> > "Thies C. Arntzen" wrote:
> > > please send me a "minimal" testcase that shows this
> > > behaviour! i'll look into that then.
> >
> > I said that I'll have it on Monday, but curiosity got the better of
> > me:-)
> >
> > So, I ran my test case and these are my findings, alogn with the test.
> >
> > Machine Configuration
> > Software:
> > - Apache.1.3.12:httpd.conf:MaxClients 150
> > - OS:SuSE.Linux.6.4 (2.2.14)
> > - Ora:Oracle.8.1.6.ee (default install)
> >I believe that by default you have 50 cursors per connection
>
> without even looking at the rest:
>
> if MaxClients is higher than the number of sessions oracle
> allows -> you are toasted!
Yes, I understand this.
But in my test case below, I never requested more than 50 connections to
oracle.
The problem is there even if you request 20 connections, provided that
you run the test script in quick succession and do not wait for the
oracle connections to die.
That is, if you:
while [-f file]; do
ab -n 100 -c 20
done
after a while you will get failed requests.
MaxClients 150, ensures that I do not run out of Apache childs and that
the failed requests are indeed due to ora conditions.
> you have to expect _one_ persistent connection to each
> oracle-instance you connect to per running apache child! in
> your case expect up to 150 single connection. if you cannot
> support 150 single connection to your oracle-server - a)
> decrease MacClients -or- b) up your oracle-session limit!
>
> please get back to me if this is indeed your problem - i'll
> investigate further after that!
>
> (i'll look thru the rest of your mail when i find some time -
> sorry, just getting up)
No problem, I can wait.
-Stathis.
>
> tc
>
> > - PHP:php.4.0.3.pl1 build as module for Apache
> > Hardware:
> > - AMD:Athlon:500
> > - RAM:384MB
> > - HD:IDE
> >
> > Test case (PHP script)
> > This code is typical of the way I handle connections to Oracle (except
> > that I use OciLogon instead of OciPLogon)
> >
> > > $oraconnections[0] = '';
> > $orastatements[0] = '';
> >
> > function newOracleConnection() {
> > global $oraconnections;
> > $c = ociplogon("scott","tiger","oracle");
> > $oraconnections[] = $c;
> > return $c;
> > }
> >
> > function newOracleStmt($connection, $select, $execute) {
> > global $orastatements;
> > $c = ociparse($connection, $select);
> > $orastatements[] = $c;
> > if (strtoupper($execute)=='EXECUTE') { ociexecute($c); }
> > return $c;
> > }
> >
> > function cleanup() {
> > global $orastatements, $oraconnections;
> > reset($orastatements);
> > while (list($key,$val)=each($orastatements)) @OciFreeStatement($val);
> > reset($oraconnections);
> > while (list($key,$val)=each($oraconnections)) @OCILogoff($val);
> > }
> >
> > $cone = NewOracleConnection();
> > $cone2 = NewOracleConnection();
> > $cone3 = NewOracleConnection();
> >
> > $s = "select table_name t from user_tables";
> > $stmt = NewOracleStmt($cone,$s,'');
> > OciDefineByName($stmt,strtoupper('t'),$t);
> > OciExecute($stmt);
> > while (OciFetch($stmt)) echo "\n table_name=$t";
> > OciFreeStatement($stmt);
> >
> > // -- in case we forget
> > cleanup();
> >
> > echo "\n";
> > ?>
> >
> > The above code runs in a separate window ("test-w") using the following
> > command:
> > ab -n 1000 -c 50 http://aspasia.mm.di.uoa.gr/~rouvas/testora.php
> >
> > In another window (lets call it "monitor") the following runs in bash:
> >
> > while [ -f afiedt.buf ]; do
> > echo -n httpd: `ps -elf | grep httpd | wc -l`;
> > echo -en " "oracle: `ps -elf | grep oracle | wc -l`;
> > uptime;
> > done
> >
> > At the beginning, monitor displays something like:
> >
> > httpd: 6 oracle: 15 1:50am up 8 days, 5:38, 8 users, load average:
> > 1.33, 1.95, 3.49
> >
> > >From now on, I will refer to "httpd: 6" and "oracle: 17" parts of the
> > above message as "httpd-counter" and "oracle-counter" respectively.
> >
> > Let the test begin!
> >
> > Everything is happening on the same machine.
> > Since I have not recorded all number I will show only significant ones,
> > that is those that caused troubles. The rest will be displayed as dashes
> > ("-").
> >
> > ab -n n1 -c n2 httpd-counter oracle-counter Failed requests
> > 500 10- - 0
> > 500 20- - 0
> > 900 50- ~52 0
> > The last did not cause any troubles, but... it took a long time for
> > these oracle processes to die.
> > So, I rerun the last invocation (900,50) three times serially, i.e. I
> > waited for the previous one to finish before I fired the next one.
> > 900 50- ~48 0
> > 900 50 ~67 many
> > 900 50
Re: [PHP] PHP + Oracle + OCIPLogon
On Fri, Jun 22, 2001 at 02:47:39AM +0300, Rouvas Stathis wrote:
> "Thies C. Arntzen" wrote:
> > please send me a "minimal" testcase that shows this
> > behaviour! i'll look into that then.
>
> I said that I'll have it on Monday, but curiosity got the better of
> me:-)
>
> So, I ran my test case and these are my findings, alogn with the test.
>
> Machine Configuration
> Software:
> - Apache.1.3.12:httpd.conf:MaxClients 150
> - OS:SuSE.Linux.6.4 (2.2.14)
> - Ora:Oracle.8.1.6.ee (default install)
>I believe that by default you have 50 cursors per connection
without even looking at the rest:
if MaxClients is higher than the number of sessions oracle
allows -> you are toasted!
you have to expect _one_ persistent connection to each
oracle-instance you connect to per running apache child! in
your case expect up to 150 single connection. if you cannot
support 150 single connection to your oracle-server - a)
decrease MacClients -or- b) up your oracle-session limit!
please get back to me if this is indeed your problem - i'll
investigate further after that!
(i'll look thru the rest of your mail when i find some time -
sorry, just getting up)
tc
> - PHP:php.4.0.3.pl1 build as module for Apache
> Hardware:
> - AMD:Athlon:500
> - RAM:384MB
> - HD:IDE
>
> Test case (PHP script)
> This code is typical of the way I handle connections to Oracle (except
> that I use OciLogon instead of OciPLogon)
>
>$oraconnections[0] = '';
> $orastatements[0] = '';
>
> function newOracleConnection() {
> global $oraconnections;
> $c = ociplogon("scott","tiger","oracle");
> $oraconnections[] = $c;
> return $c;
> }
>
> function newOracleStmt($connection, $select, $execute) {
> global $orastatements;
> $c = ociparse($connection, $select);
> $orastatements[] = $c;
> if (strtoupper($execute)=='EXECUTE') { ociexecute($c); }
> return $c;
> }
>
> function cleanup() {
> global $orastatements, $oraconnections;
> reset($orastatements);
> while (list($key,$val)=each($orastatements)) @OciFreeStatement($val);
> reset($oraconnections);
> while (list($key,$val)=each($oraconnections)) @OCILogoff($val);
> }
>
> $cone = NewOracleConnection();
> $cone2 = NewOracleConnection();
> $cone3 = NewOracleConnection();
>
> $s = "select table_name t from user_tables";
> $stmt = NewOracleStmt($cone,$s,'');
> OciDefineByName($stmt,strtoupper('t'),$t);
> OciExecute($stmt);
> while (OciFetch($stmt)) echo "\n table_name=$t";
> OciFreeStatement($stmt);
>
> // -- in case we forget
> cleanup();
>
> echo "\n";
> ?>
>
> The above code runs in a separate window ("test-w") using the following
> command:
> ab -n 1000 -c 50 http://aspasia.mm.di.uoa.gr/~rouvas/testora.php
>
> In another window (lets call it "monitor") the following runs in bash:
>
> while [ -f afiedt.buf ]; do
> echo -n httpd: `ps -elf | grep httpd | wc -l`;
> echo -en " "oracle: `ps -elf | grep oracle | wc -l`;
> uptime;
> done
>
> At the beginning, monitor displays something like:
>
> httpd: 6 oracle: 15 1:50am up 8 days, 5:38, 8 users, load average:
> 1.33, 1.95, 3.49
>
> >From now on, I will refer to "httpd: 6" and "oracle: 17" parts of the
> above message as "httpd-counter" and "oracle-counter" respectively.
>
> Let the test begin!
>
> Everything is happening on the same machine.
> Since I have not recorded all number I will show only significant ones,
> that is those that caused troubles. The rest will be displayed as dashes
> ("-").
>
> ab -n n1 -c n2 httpd-counter oracle-counter Failed requests
> 500 10- - 0
> 500 20- - 0
> 900 50- ~52 0
> The last did not cause any troubles, but... it took a long time for
> these oracle processes to die.
> So, I rerun the last invocation (900,50) three times serially, i.e. I
> waited for the previous one to finish before I fired the next one.
> 900 50- ~48 0
> 900 50 ~67 many
> 900 50 ~65 many
> Next I fired up the following from three different windows
> simultaneously (almost)
>
> ab -n 1000 -c 50
>
> In the first run: http-counter: -
> oracle-counter : (below 50)
> failed requests : (none)
>
> I waited until http-counter:7 and oracle-counter:17 and rerun the three
> simultaneous invocations.
>
> httpd-counter : -
> oracle-counter : 52
> failed-requests : (none)
>
> Without waiting, I fired the three invocations again.
> httpd-counter : 75 (max)
> oracle-counter : 82 (max)
> failed-requests: 550 (test-w-1), 544 (test-w-2) and 493 9 9(test-w-3)
>
> After more runs (and to make a long story short), I observed that no
> matter what the concurrency level or the number of requests to the ab
>
Re: [PHP] PHP + Oracle + OCIPLogon
Thank you for your prompt reply. I read your suggestion about MaxClients in Apache conf. Since this is something I haven't thought before, I'll take it into consideration first and then I will supply you a test case as you requested. I will do so in the forthcoming weekend. Please, read below for my comments on your other points. "Thies C. Arntzen" wrote: > > On Thu, Jun 21, 2001 at 09:32:31PM +0300, Rouvas Stathis wrote: > > "Thies C. Arntzen" wrote: > > > > > > On Thu, Jun 21, 2001 at 03:19:09PM +0300, Rouvas Stathis wrote: > > > > > > > > Unfortunately, you are not doing anything wrong. > > > > Persistent connections and PHP/Ora do not play well with each other. > > > > > > ??? - please elaborate. > > > > PHP/Ora without persistent connections are fine and rock solid even > > under heavy load. > > PHP/Ora with persitent connections does not work. > > Explanation. > > Using OciPlogon you connect to Ora and everything is fine. > > yep. > > > Then you issue an OciLogout and you terminate your connection as fas as > > PHP is concerned. > > wrong > > > Unfortunately, the connection to Oracle is not closed, > > as a "ps -ef | grep oracle" can tell you. > > yes - cause PHP will reuse it! > > > Next time PHP is called, OciPlogon requests (and gets) a new connection > > nope. that would be a bug. I am not aware of the internals, but the displayed behaviour when using OciPLogon is exactly the same with the one displayed when you "forget" to OciLogout. I assume that a new connection is made, since I cannot find another explanation for the number of open connections to increase. I measure open connections doing "ps -elf | grep oracle | grep tnslsnr". > > > to Oracle without using the old one or closing it. Then OciLogout is > > called and you are now left with two open connections to Oracle. > > please send me a "minimal" testcase that shows this > behaviour! i'll look into that then. OK, I will do so. Expect it some time in Monday. > > > The connections PHP opens will timeout eventually and close "by > > themselves". > > nope - that would be bug. I don't think so. All connections to Oracle will close if left by themselves. Oracle will kill them...I think. > > > Now, if you are testing on a personal machine or your machine has enough > > resources, this problem (that I call "lingering connections") may pass > > unnoticed. > > The moment you get more than about 10 hits, those "lingering > > connections" will add up and pretty soon you will (a) run out of Ora > > cursors or (b) run out of resources. > > When that moment comes you will not be able to connect to Ora anymore, > > untill some of those connections die, which of course is dependant on > > the timeout. > > Now in development server with 1GB of RAM > > (Solaris/Ora.8.0.4.EE/PHP.4.0.3.pl1) the "lingering connections" > > phenomenon rarely manifestated itself. In fact it was so rare that I > > almost always suspected my code doing something nasty. > > When it was moved into production (in a Suse > > Linux.2.2.14/PHP.4.0.3.pl1/Ora.8.0.5.EE) with only 128MB of RAM, upon > > the first test run it blew into my face. > > After changing all OciPlogon into plain OciLogon, all problems > > dissapeared. > > > > This has happened with other applications that I have experimented with. > > The "lingering connections" problem is with us at least since PHP.3.0.12 > > (which the first version of PHP I tried). > > > > That's why I say that PHP/Ora with *persistent* connection do not play > > well with each other. > > i'm the author of this module and more than willing to help. > i do tests using the ab tool and have never found any > irregularities in the plogon mode. if you can show me how to > reproduce this i'm (mostly) sure i can fix it! Thanks for the cooperation. > > tc > > > > > I hoped I cleared the issue. > > I really hope that this problem is resolved, since I expect an increase > > in performance when the penalty for making a new connection is avoided. > > > > -Stathis. > > > > > > > > > > tc -Stathis. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] PHP + Oracle + OCIPLogon
"Thies C. Arntzen" wrote:
> please send me a "minimal" testcase that shows this
> behaviour! i'll look into that then.
I said that I'll have it on Monday, but curiosity got the better of
me:-)
So, I ran my test case and these are my findings, alogn with the test.
Machine Configuration
Software:
- Apache.1.3.12:httpd.conf:MaxClients 150
- OS:SuSE.Linux.6.4 (2.2.14)
- Ora:Oracle.8.1.6.ee (default install)
I believe that by default you have 50 cursors per connection
- PHP:php.4.0.3.pl1 build as module for Apache
Hardware:
- AMD:Athlon:500
- RAM:384MB
- HD:IDE
Test case (PHP script)
This code is typical of the way I handle connections to Oracle (except
that I use OciLogon instead of OciPLogon)
The above code runs in a separate window ("test-w") using the following
command:
ab -n 1000 -c 50 http://aspasia.mm.di.uoa.gr/~rouvas/testora.php
In another window (lets call it "monitor") the following runs in bash:
while [ -f afiedt.buf ]; do
echo -n httpd: `ps -elf | grep httpd | wc -l`;
echo -en " "oracle: `ps -elf | grep oracle | wc -l`;
uptime;
done
At the beginning, monitor displays something like:
httpd: 6 oracle: 15 1:50am up 8 days, 5:38, 8 users, load average:
1.33, 1.95, 3.49
>From now on, I will refer to "httpd: 6" and "oracle: 17" parts of the
above message as "httpd-counter" and "oracle-counter" respectively.
Let the test begin!
Everything is happening on the same machine.
Since I have not recorded all number I will show only significant ones,
that is those that caused troubles. The rest will be displayed as dashes
("-").
ab -n n1 -c n2 httpd-counter oracle-counter Failed requests
500 10- - 0
500 20- - 0
900 50- ~52 0
The last did not cause any troubles, but... it took a long time for
these oracle processes to die.
So, I rerun the last invocation (900,50) three times serially, i.e. I
waited for the previous one to finish before I fired the next one.
900 50- ~48 0
900 50 ~67 many
900 50 ~65 many
Next I fired up the following from three different windows
simultaneously (almost)
ab -n 1000 -c 50
In the first run: http-counter: -
oracle-counter : (below 50)
failed requests : (none)
I waited until http-counter:7 and oracle-counter:17 and rerun the three
simultaneous invocations.
httpd-counter : -
oracle-counter : 52
failed-requests : (none)
Without waiting, I fired the three invocations again.
httpd-counter : 75 (max)
oracle-counter : 82 (max)
failed-requests: 550 (test-w-1), 544 (test-w-2) and 493 9 9(test-w-3)
After more runs (and to make a long story short), I observed that no
matter what the concurrency level or the number of requests to the ab
were, if oracle-counter reached about 55, no more requests would be
served.
That, of course, is consistent with the number of Oracle cursors
available.
What is not consistence, hence I think that OciPlogon is unsuitable in
its current implementation, is that while it proved extremely difficult
to run out of connections within a *single* invocation of my test script
with ab, it was trivial to do so when either (a) you invoke ab without
waiting enough time for the oracle-counter (number of Oracle processes)
to decrease or (b) you do parallel invocations.
Of course, (b) is to be expected. But I didn't expect (a).
If a small number of concurrency(10) is used, (a) is rather difficult to
achieve.
Almost any number bigger than that will raise the problem.
I would expect, that in (a) (serial invocations), PHP to reuse existing
connections and the oracle-counter to remain relatively constant.
Instead, it gradually increases, untill it reaches about 55, which in my
case, is the upper limit.
In real world scenarios, you don't have control over what is happening,
so you quickly run out of connections.
In favor of OciPLogon, I have to state that while with OciLogon I got 3
requests/second (max), using OciPlogon got me an impressive 42
requests/second (when no failed requests where observed).
My interpretation:
While PHP is running is doing a very good job of reusing active
connections.
When it is unloaded/stopped it "forgets" some of them and starts opening
some new ones.
That behaviour may be caused by Apache as some clients that were
originally spawned to handle the load, gradually die without killing the
oracle connections that have been associated with them. When a new
request is made, if an existing Apache client is able to handle it, the
connections associated with it are re-used. If a new one is spawned,
then a new set of connections is made.
Hence, the gradual increase of the oracle-counter.
About the same behaviour is observed when you "forget" to OciLogout,
which is to be expected.
Re: [PHP] PHP + Oracle + OCIPLogon
On Thu, Jun 21, 2001 at 09:32:31PM +0300, Rouvas Stathis wrote: > "Thies C. Arntzen" wrote: > > > > On Thu, Jun 21, 2001 at 03:19:09PM +0300, Rouvas Stathis wrote: > > > > > > Unfortunately, you are not doing anything wrong. > > > Persistent connections and PHP/Ora do not play well with each other. > > > > ??? - please elaborate. > > PHP/Ora without persistent connections are fine and rock solid even > under heavy load. > PHP/Ora with persitent connections does not work. > Explanation. > Using OciPlogon you connect to Ora and everything is fine. yep. > Then you issue an OciLogout and you terminate your connection as fas as > PHP is concerned. wrong > Unfortunately, the connection to Oracle is not closed, > as a "ps -ef | grep oracle" can tell you. yes - cause PHP will reuse it! > Next time PHP is called, OciPlogon requests (and gets) a new connection nope. that would be a bug. > to Oracle without using the old one or closing it. Then OciLogout is > called and you are now left with two open connections to Oracle. please send me a "minimal" testcase that shows this behaviour! i'll look into that then. > The connections PHP opens will timeout eventually and close "by > themselves". nope - that would be bug. > Now, if you are testing on a personal machine or your machine has enough > resources, this problem (that I call "lingering connections") may pass > unnoticed. > The moment you get more than about 10 hits, those "lingering > connections" will add up and pretty soon you will (a) run out of Ora > cursors or (b) run out of resources. > When that moment comes you will not be able to connect to Ora anymore, > untill some of those connections die, which of course is dependant on > the timeout. > Now in development server with 1GB of RAM > (Solaris/Ora.8.0.4.EE/PHP.4.0.3.pl1) the "lingering connections" > phenomenon rarely manifestated itself. In fact it was so rare that I > almost always suspected my code doing something nasty. > When it was moved into production (in a Suse > Linux.2.2.14/PHP.4.0.3.pl1/Ora.8.0.5.EE) with only 128MB of RAM, upon > the first test run it blew into my face. > After changing all OciPlogon into plain OciLogon, all problems > dissapeared. > > This has happened with other applications that I have experimented with. > The "lingering connections" problem is with us at least since PHP.3.0.12 > (which the first version of PHP I tried). > > That's why I say that PHP/Ora with *persistent* connection do not play > well with each other. i'm the author of this module and more than willing to help. i do tests using the ab tool and have never found any irregularities in the plogon mode. if you can show me how to reproduce this i'm (mostly) sure i can fix it! tc > > I hoped I cleared the issue. > I really hope that this problem is resolved, since I expect an increase > in performance when the penalty for making a new connection is avoided. > > -Stathis. > > > > > > tc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] PHP + Oracle + OCIPLogon
"Thies C. Arntzen" wrote: > > On Thu, Jun 21, 2001 at 03:19:09PM +0300, Rouvas Stathis wrote: > > > > Unfortunately, you are not doing anything wrong. > > Persistent connections and PHP/Ora do not play well with each other. > > ??? - please elaborate. PHP/Ora without persistent connections are fine and rock solid even under heavy load. PHP/Ora with persitent connections does not work. Explanation. Using OciPlogon you connect to Ora and everything is fine. Then you issue an OciLogout and you terminate your connection as fas as PHP is concerned. Unfortunately, the connection to Oracle is not closed, as a "ps -ef | grep oracle" can tell you. Next time PHP is called, OciPlogon requests (and gets) a new connection to Oracle without using the old one or closing it. Then OciLogout is called and you are now left with two open connections to Oracle. The connections PHP opens will timeout eventually and close "by themselves". Now, if you are testing on a personal machine or your machine has enough resources, this problem (that I call "lingering connections") may pass unnoticed. The moment you get more than about 10 hits, those "lingering connections" will add up and pretty soon you will (a) run out of Ora cursors or (b) run out of resources. When that moment comes you will not be able to connect to Ora anymore, untill some of those connections die, which of course is dependant on the timeout. Now in development server with 1GB of RAM (Solaris/Ora.8.0.4.EE/PHP.4.0.3.pl1) the "lingering connections" phenomenon rarely manifestated itself. In fact it was so rare that I almost always suspected my code doing something nasty. When it was moved into production (in a Suse Linux.2.2.14/PHP.4.0.3.pl1/Ora.8.0.5.EE) with only 128MB of RAM, upon the first test run it blew into my face. After changing all OciPlogon into plain OciLogon, all problems dissapeared. This has happened with other applications that I have experimented with. The "lingering connections" problem is with us at least since PHP.3.0.12 (which the first version of PHP I tried). That's why I say that PHP/Ora with *persistent* connection do not play well with each other. I hoped I cleared the issue. I really hope that this problem is resolved, since I expect an increase in performance when the penalty for making a new connection is avoided. -Stathis. > > tc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] PHP + Oracle + OCIPLogon
On Thu, Jun 21, 2001 at 03:19:09PM +0300, Rouvas Stathis wrote: > > Unfortunately, you are not doing anything wrong. > Persistent connections and PHP/Ora do not play well with each other. ??? - please elaborate. tc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] PHP + Oracle + OCIPLogon
On Wed, Jun 20, 2001 at 05:33:18PM +0200, Confuser wrote: > I understand that OCIPLogon creates a persitant connection to the Oracle DB, > to improve > performance... And I must say it does ! > > However, since OCILogoff is best not used with a persitant logon (and in the > latest versions, > it doesn't do anything anyway)... How will PHP decide when to cut that > connection loose ? one the connection is "broken" php will reestablish it. > > We are working on a relatively small website, with 4 users... Within no > time, the session limit > in Oracle (which is 60) is reached, and the site doesn't work anymore... if you MaxClients if set higher that the maximum number of session you allow in oracel than this would be true. remember: perstistent connection are on the apache-process level. so if you have 50 httpd processes running (and you use plogon) i would expect 60 active oracle connections! > > The website should be able to handle thousands of customers in the future, > so it would only > take a second to crash... not if you configure it "correct". believe me - there are ppls out there that use this stuff;-) tc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] PHP + Oracle + OCIPLogon
"Rouvas Stathis" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Unfortunately, you are not doing anything wrong. > Persistent connections and PHP/Ora do not play well with each other. > I suggest that that you use plain OciLogon. > -Stathis. Oh :o) That's a shame... Ok, guess we'll have to use OCILogon in stead... Thanks for the response! Gunther -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] PHP + Oracle + OCIPLogon
Confuser wrote: > > I understand that OCIPLogon creates a persitant connection to the Oracle DB, > to improve > performance... And I must say it does ! > > However, since OCILogoff is best not used with a persitant logon (and in the > latest versions, > it doesn't do anything anyway)... How will PHP decide when to cut that > connection loose ? > > We are working on a relatively small website, with 4 users... Within no > time, the session limit > in Oracle (which is 60) is reached, and the site doesn't work anymore... > > The website should be able to handle thousands of customers in the future, > so it would only > take a second to crash... > > What are we doing wrong? Why aren't the sessions automatically killed by PHP > ? Unfortunately, you are not doing anything wrong. Persistent connections and PHP/Ora do not play well with each other. I suggest that that you use plain OciLogon. -Stathis. > > Thank you! > Gunther -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] PHP + Oracle + OCIPLogon
I understand that OCIPLogon creates a persitant connection to the Oracle DB, to improve performance... And I must say it does ! However, since OCILogoff is best not used with a persitant logon (and in the latest versions, it doesn't do anything anyway)... How will PHP decide when to cut that connection loose ? We are working on a relatively small website, with 4 users... Within no time, the session limit in Oracle (which is 60) is reached, and the site doesn't work anymore... The website should be able to handle thousands of customers in the future, so it would only take a second to crash... What are we doing wrong? Why aren't the sessions automatically killed by PHP ? Thank you! Gunther -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
