"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:
<bash>
while [-f file]; do
ab -n 100 -c 20 <url>
done
</bash>
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)
> > <code>
> > <?php
> > $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";
> > ?>
> > </code>
> > 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:
> > <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
> > </bash>
> > 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 <url> 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 <url>
> >
> > 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.
> >
> > In all cases, if OciLogon is used no number of failed requests has been
> > observed.
> > Except the significantly slower response time, I find using OciLogon
> > results in more stable programs and so far I think it is more suitable
> > for sites experiencing heavy loads.
> >
> > I'm really looking forward to your reply
> >
> > -Stathis.
> >
> > PS.: Since it is now 3 o'clock in the morning here, please excuse any
> > typos and lax use of
> > English.
--
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]
