FastCGI and DB connections / global variables?

[Joshua Ruppert]

When I'm using FastCGI do I need to code differently than I do when
using regular CGI? Because the PHP.exe processes don't go away do
global variables stick around from page request to page request,
creating the need for better managment / pooling of DB connections?

Josh

[Chung Leong]

Joshua Ruppert wrote:

When I'm using FastCGI do I need to code differently than I do when
using regular CGI? Because the PHP.exe processes don't go away do
global variables stick around from page request to page request,
creating the need for better managment / pooling of DB connections?

Josh

There is no difference from a programming standpoint. Global variables
are destroyed at the end of each request.

[Joshua Ruppert]

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.

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.
Chung Leong wrote:

Joshua Ruppert wrote:

When I'm using FastCGI do I need to code differently than I do when
using regular CGI? Because the PHP.exe processes don't go away do
global variables stick around from page request to page request,
creating the need for better managment / pooling of DB connections?

Josh

There is no difference from a programming standpoint. Global variables
are destroyed at the end of each request.

[Chung Leong]

Joshua Ruppert wrote:

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.

Hmmm. What's the database server? Maybe a script has left a transaction
open by accident?

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.

Sort off topic, but I think you'll find the kill util in the Windows
Resource Kit quite handy for situations like that.

[Jerry Stuckle]

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.

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.
js*******@attgl obal.net
=============== ===

[Joshua Ruppert]

Chung Leong wrote:

Joshua Ruppert wrote:

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.

Hmmm. What's the database server? Maybe a script has left a transaction
open by accident?

There are four Microsoft SQL Server 2000 servers running behind a
single IIS page server.

As for an open transaction, that was my first thought too. I've
systematically check for and clean up open transactions before each use
and then at the end of each script. I did that because it was easy to
do a global search and replace on the open transaction statements.

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.

Sort off topic, but I think you'll find the kill util in the Windows
Resource Kit quite handy for situations like that.

Thanks for the tip, though do you think FastCGI would respond properly
to a process being killed through the back door like that, and replace
it properly?

[Joshua Ruppert]

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.

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.
js*******@attgl obal.net
=============== ===

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

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?

[Chung Leong]

Joshua Ruppert wrote:

There are four Microsoft SQL Server 2000 servers running behind a
single IIS page server.

As for an open transaction, that was my first thought too. I've
systematically check for and clean up open transactions before each use
and then at the end of each script. I did that because it was easy to
do a global search and replace on the open transaction statements.

Are you using mssql_pconnect( )? Try switching to mssql_connect() . That
would remove the one difference between FastCGI and CGI.

If you're using ADODB through COM, that could be the source of the
problem. PHP (version 4 at least) has a nasty habit of not releasing
COM objects correctly. After a while the leak builds up and the server
sort of dies.

Thanks for the tip, though do you think FastCGI would respond properly
to a process being killed through the back door like that, and replace
it properly?

I think it will. Windows does a decent job cleaning up dead processes.
And to the controlling process, there isn't a huge difference between a
child exiting normally or abnormally.

What you should do though is to not run PHP as a system process. Go
into services and run change the login to IWebUser or something.

[Jerry Stuckle]

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.

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.
js*******@att global.net
============= =====

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.
js*******@attgl obal.net
=============== ===

[Joshua Ruppert]

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.
js*******@attg lobal.net
============== ====

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.
js*******@attgl obal.net
=============== ===

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

and I also do a
odbc_free_resul t($result);

before each
$result = odbc_exec($conn ect, $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_resul t call before each.
The only thing I'm seeing as I write this is that I could do a
odbc_free_resul t call before each odbc_close, but I would assume that a
close would also free the result set.