|
|
Posted by Jerry Stuckle on 07/27/06 21:56
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@attglobal.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@attglobal.net
>>==================
>
>
> 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@attglobal.net
==================
Navigation:
[Reply to this message]
|