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]
