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]

Re: FastCGI and DB connections / global variables?


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]

Re: FastCGI and DB connections / global variables?

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]

Re: FastCGI and DB connections / global variables?

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]

Re: FastCGI and DB connections / global variables?

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

[Joshua Ruppert]

Re: FastCGI and DB connections / global variables?


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]

Re: FastCGI and DB connections / global variables?


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.
jstucklex@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]

Re: FastCGI and DB connections / global variables?

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]

Re: FastCGI and DB connections / global variables?

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

[Joshua Ruppert]

Re: FastCGI and DB connections / global variables?


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@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.
jstucklex@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.

[Joshua Ruppert]

Re: FastCGI and DB connections / global variables?


Chung Leong wrote:

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.

We're using ODBC instead of the direct MSSQL drivers for one, and we
are using the standard odbc_connect() function. Are there any known
problems using ODBC with MS SQL Server?

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.

Wouldn't the service login be the Web Server service login? So to
control the PHP login I would need to change the Web service login?

[Chung Leong]

Re: FastCGI and DB connections / global variables?

Joshua Ruppert wrote:

We're using ODBC instead of the direct MSSQL drivers for one, and we
are using the standard odbc_connect() function. Are there any known
problems using ODBC with MS SQL Server?

I'm not too familiar with ODBC. The SQL Server ODBC driver does
connection pooling. With standard CGI you'd get a new connection
everytime, whereas the connection would be reused in FastCGI. As your
application works in CGI but no in FastCGI, that's a good place to
look.

It could also be that you were experiencing deadlocks before, only that
IIS was terminating the process.

I'm sort of out of ideas. You might want to reproduce the condition (on
a test environment of course), then run sp_who/sp_who2 in Query
Analyser to see what is actually happening. It'd also be interesting to
see if the PHP processes would unfreeze if you stop SQLServer.

Wouldn't the service login be the Web Server service login? So to
control the PHP login I would need to change the Web service login?

Nevermind. I mistakenly thought the installer adds PHP as a service.

[Joshua Ruppert]

Re: FastCGI and DB connections / global variables?

Chung Leong wrote:

Joshua Ruppert wrote:

We're using ODBC instead of the direct MSSQL drivers for one, and we
are using the standard odbc_connect() function. Are there any known
problems using ODBC with MS SQL Server?

>
I'm not too familiar with ODBC. The SQL Server ODBC driver does
connection pooling. With standard CGI you'd get a new connection
everytime, whereas the connection would be reused in FastCGI. As your
application works in CGI but no in FastCGI, that's a good place to
look.
>
It could also be that you were experiencing deadlocks before, only that
IIS was terminating the process.
>
I'm sort of out of ideas. You might want to reproduce the condition (on
a test environment of course), then run sp_who/sp_who2 in Query
Analyser to see what is actually happening. It'd also be interesting to
see if the PHP processes would unfreeze if you stop SQLServer.

No problem. I'm about at the end of my rope too. I've not been able to
reproduce the problem, but it (stranded PHP processes) actually happens
with or without FastCGI, but without FastCGI I'm able to kill the
stranded processes. So I'm able to keep the site running, my big
problem with FastCGI is that when the !@#$ hit the fan I had to reboot.

We are no strangers to SQL Server and resolving dead locks and
optimizing queries but these stranded processes have been a complete
mystery. The problem is that even if we can prove it's caused by a dead
lock, you can't avoid the occasional dead lock. The best you can do is
write the program so it recovers gracefully. We're thinking about
trying PHP 5 to see if that resolves the problem. We may even write a
low level app to clear out stranded processes. It seem like more of a
bug in PHP forever waiting instead of timing out.

[Jerry Stuckle]

Re: FastCGI and DB connections / global variables?

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@a ttglobal.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.
>>jstucklex@att global.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.
>

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

[Joshua Ruppert]

Re: FastCGI and DB connections / global variables?


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@at tglobal.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.
>jstucklex@attg lobal.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.

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

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.