Re: FastCGI and DB connections / global variables?

Joshua Ruppert wrote:
Jerry Stuckle wrote:

Joshua Ruppert wrote:

Jerry Stuckle wrote:


Joshua Ruppert wrote:


Jerry Stuckle wrote:



Joshua Ruppert wrote:



With that said I'm not sure what my problem is. I have a website that
has already been developed running Win2K and PHP 4, that I tried to
switch over to FastCGI. When I did this every thing ran fine for a
while, until we had a spike in traffic. (Since FastCGI was tried we
have moved to Win2K3.)

The root cause of the problems seems to be the response time of the DB
servers but I'm not certain. When the database servers became loaded,
the PHP processes seemed to hang while waiting for the database to
respond. Eventually this effected each of the PHP processes started by
FastCGI, completely taking down the site.


t> >>>The only way I found to restart the PHP processes is to reboot
the


machine, because task manager did let me kill the processes that were
started by FastCGI.

Is there anything that you could see (slow DB connections or otherwise)
that would cause this kind of behavior?

I used the PHPLens.com EasyWindows PHP Installer, but I'm having
trouble finding resources to help me fine tune FastCGI opperation.

Any suggestions are greatly appreciated.



Is it possible you're getting into a deadlock situation? These are more
likely to show up when the database is busy, and you probably wouldn't
be able to cancel the task.

P.S. - please don't top post. Thanks.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================


What do you mean by "top post"? Replying above the previous posts?


Yep. This is perfect. Thanks!



No, I have not observed a deadlock. The site is 99% read only, so that
greatly reduces the risk also. Isn't FastCGI suppose to clean up dead
processes?



OK, are you sure you're closing your connections at the end of the
script? Waiting for PHP's gc to do it may take a little time.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================


Yes, I went through the scripts very methodically and systematically to
add the following to the end of each script
odbc_close($connect);

and I also do a
odbc_free_result($result);

before each
$result = odbc_exec($connect, $query);

This was my first website to use PHP and so I had to go back and
retrofit it to do DB resource cleanup. I performed a search and replace
on the odbc_exec calls to add the odbc_free_result call before each.
The only thing I'm seeing as I write this is that I could do a
odbc_free_result call before each odbc_close, but I would assume that a
close would also free the result set.


I always free my results as soon as I'm done with them, and close the
database when I've completed processing with it. I guess I've been
bitten too many times in almost 40 years of programming to depend on the
gc :-).

FastCGI will clean up dead processes when the gc runs. The problem is
it doesn't run immediately - there can be (and generally is) a delay
before it cleans everything up. But like you, I would expect closing
the connection would free the results, at least as far as the database
end goes. And even if they weren't cleaned up on the PHP end
immediately, they shouldn't affect other connections.

Could it be the database servers are just so loaded they can't get back
in a reasonable time? I've found typically response time is an
exponential curve - going from 1% load to 10% load won't affect response
time much - but going from 90% to 99% load has a very big effect. Load
could include CPU, disk, network, etc.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================


Ya, I've come a long way since the initial creation of this site but I
believe that it's pretty tight now, when it comes to db connection
cleanup.

The load on the DB servers was our first thought too, but to complicate
my research even more, I've seen the stranded processes even durring
low traffic times. This makes absolutely no sense to me and seems to
point to a dead lock issue, but then we're back to the PHP libraries
not handling dead locks gracefully. Which I don't think I can do much
about, asside from having a separate app to monitor stranded processes.


But deadlocks handling isn't a function of the PHP libraries - it's one of the database. It would, for instance, be very cruel to pull the calling program (and it's memory) out from under the DB in the middle of a DB call. Which, BTW, is possibly why you can't cancel the tasks from the OS.

I suspect if you recycle the database things would free up (with errors, of course).

Sounds to me like maybe you need to troubleshoot this from the db end.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================
.

Relevant Pages

  • Re: FastCGI and DB connections / global variables?
    ... has already been developed running Win2K and PHP 4, ... switch over to FastCGI. ... When the database servers became loaded, ...
    (comp.lang.php)
  • Re: about structure.
    ... Of course if you want to use a load of checkboxes, it works too, just modify ... I thought about using a database... ... "I thought about using php... ... server needs to call upon php... ...
    (alt.php)
  • Re: FastCGI and DB connections / global variables?
    ... Jerry Stuckle wrote: ... has already been developed running Win2K and PHP 4, ... switch over to FastCGI. ... When the database servers became loaded, ...
    (comp.lang.php)
  • Re: FastCGI and DB connections / global variables?
    ... Jerry Stuckle wrote: ... has already been developed running Win2K and PHP 4, ... switch over to FastCGI. ... When the database servers became loaded, ...
    (comp.lang.php)
  • CGI vs. ISAPI
    ... I first tried to make the jump to PHP 5.0.4. ... to load a database with the ISAPI interface, it hangs until I'm finally told ... the .sql file via phpMyAdmin into MySQL. ...
    (comp.lang.php)