RE: Re: Understanding persistent connections with oci8

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 Hi Richard,

  You've asked the $64,000 question.  What is a reasonable way for this
timeout to work?  Unfortunately we haven't gotten  far with the
bug.php.net folks to ask the question.  I agree with you that providing
an active thread or process to go out and check for idle persistent
connections is too much overhead. 
I think what is needed is a little investigation to see what can be
reasonable done if a customer wants to use the oci8.persistent_timeout
to limit how long these connections hang around.  

  From our testing of multiple connections we could easily create 50 of
these persistent connections and would have to hit the apache web server
pretty hard with a 1000 requests at 50 at a time to get these to
terminate after the timeout.    But that does work, so that is one data
point and limit when setting this idle timeout.  What I think should
also happen if the timeout is set, and the persistent connection goes
idle long enough it should be marked as a candidate for shutting down.
PHP itself if it goes to use this stale connection, should kill it and
use another connection, hopefully a non-stale persistent connection.

  And actually, Kiran in our lab proposed that as a very easy fix to
implement, and we've tested it and it works fine.  In other words we
make 50 persistent connections, with the timeout at 10 seconds, wait a
minute and then make another round of the same php requests.  With the
fix we proposed all new php connections are made.  So we know this
works.  I think if this was implemented and the documentation was clear
that what the persistent timeout provided was for these connections to
be shutdown when every a new connection tried to use them, PHP or not,
that would go along way to satisfying most customers.  Especially if it
clearly and cleanly documented that was how it worked.

  I can also see environments where the system hosting apache and these
persistent connections for the database is very busy, and can get large
burst of PHP requests from different users accessing the data at a given
time, which creates lots of persistent connections.  I can see them
wanting a more active mechanism for terminating any connections after
the peak has ended and thinks have quieted down for awhile.   I think
your idea of a cron job might work there, or the same mechanism within
PHP.  If there was one, I'd make it optional as it would be overhead and
many customers wouldn't want it.

  There seems to me to be several ways to implement this
persistent_timeout that would make it act like how most idle timeouts
work, and I agree if we can come up with some simple, low overhead ways
that are well documented that would do the trick.


 Thanks and regards, Jay 
   
  

-----Original Message-----
From: Richard Lynch [mailto:ceo@xxxxxxxxx] 
Sent: Wednesday, October 11, 2006 3:44 PM
To: Bauer, Jay W
Cc: php-general@xxxxxxxxxxxxx; Bauer, Jay W; Mendonce, Kiran (STSD);
Nikiel, Carsten; Rai, Moni (GSE WTEC Cupertino); Rieslund, Mikael
Subject: RE:  Re: Understanding persistent connections with oci8

On Wed, October 11, 2006 8:46 am, Bauer, Jay W wrote:
>   Yes there have been some trigger-happy, bug-bogus-marking going on, 
> but that happens.
>
>   And yes, this stays alive without anything going on.  And we have 
> tested your "other wrinkle" and that is how we have been able to end 
> the persistent connections by making connections to a non-oracle-db 
> request which will terminate the persistent connections.  The only 
> other way has been to restart apache.  And I can redo the test with 
> just one server and one connection and explicitly terminate the 
> persistent connection by making a new non-oracle-db request.

Okay, so here's the thing...

At what point in the process of normal web-server operations would you
expect PHP to "notice" that the connection is stale and it should die?

It's clear, to me, and to many others, that the problem here is not that
it doesn't work -- Just that it "works" in a non-intuitive way for
perfectly logical technical reasons.

To clarify this, consider your one-process, one-user, one-hit test.

Time
00:00 User asks for URL that accesses DB
00:01 PHP opens persistent connection
00:02 PHP returns HTML to user
[It's probably not really 2 seconds, but let's just pretend.]

At this juncture, Apache and PHP pretty much just go back to sleep, and
don't do anything at all until something else comes along to wake them
up.

If the next thing to wake them up authenticates against the DB, and
starts using the connections, then they are re-used, because they are
already there, and there is no sense in tearing down a perfectly good
"stale" connection if you're about to build another one.

If the next thing to wake them up does NOT use the DB connection, the
connection is noticed to be stale and killed off.

This is how it works, as far as we can see from your testing.

So there are several possible solutions here.

PHP could set some kind of "timer" to wake itself up, check any
outstanding persistent connections, and kill them off.  This would need
to be managed so that there is only one active "timer" and its wake-up
time is extended as various events occur, since you wouldn't want it
doing too much extra work that PHP is already doing.

That would probably involve a great deal of inter-process communication
and some significant overhead.

The other option, cheap and easy, is to behave the way it does now: 
If somebody wakes PHP up, and it sees a stale connection, and it's not
gonna use that stale connection, it kills it off.

Now for MOST users, on MOST real-life scenarios, the cheap and easy
solution is best.

For those who have an unusual case, such as your dev server, a cron job
to "heartbeat" a non-DB page every X minutes is a no-brainer, once one
understands what's going on and why.

You are certainly welcome to code and submit a patch to PHP to make it
wake up and kill off stale connections, if you really think this is
absolutely crucial...  But if it has the kind of overhead I suspect it
would have, it's not likely to be implemented.

Or you could run a heartbeat cron job to a non-DB connection just a
little bit longer than your connection time-out, and call the problem
solved.

NOTE:
I am NOT an expert on PHP internals, and may be grossly incorrect about
all this.  I'm just giving my perception of your test results, based on
how HTTP / Apache/ PHP generally work.

PS I think this is how all the "persistent" connections operate...

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux