PHP Server question
Moderator: General Moderators
PHP Server question
I'm not quite sure how to test this accurately, and I can't find the answer, so here's my question... When a visitor to your site goes to a PHP page that does multiple database queries, what happens if they refresh, close the browser, or go to another page while the server is still running the script? I assume the server completes the entire script no matter what (except if the server crashes, etc.). But, I want to be sure of this. I'm having a hard time testing it, because I don't know if the script is simply finished before I refresh.
I'm sorry for the dumb question. I've been using PHP for quite some time now. But, I'm just now getting into developing pages where this actually matters. I plan on using transactions soon. But, without using transactions, I'm not sure what happens to queries that haven't started before the user sends a request for a new page.
Thanks in advance!
Swede
I'm sorry for the dumb question. I've been using PHP for quite some time now. But, I'm just now getting into developing pages where this actually matters. I plan on using transactions soon. But, without using transactions, I'm not sure what happens to queries that haven't started before the user sends a request for a new page.
Thanks in advance!
Swede
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
I'm pretty sure the proccess dies. Lets say you write an infinite loop with no timeout.... the server does stop handling it if you close the browser.
Run it.... it would never end.... check your CPU, it's probably rocketed. Now close the window and give it a few secs to decide you've gone... the CPU returns to normal.
Code: Select all
<?php
set_timeout(0);
$i = 0;
while ( ++$i )
{
echo "$i<br />";
}
?>Are you sure that the process is dying because you close the browser?
With the code sample you gave, it would simply time out, assuming that you have your max_execution_time set to something other than 0 in your php.ini. I know that you have set_timeout(0) listed in your sample code. But, that's not a php function, and therefore wouldn't keep it from timing out (if you used that exact code). I think you meant set_time_limit(0). Anyway, I see what you meant, and I'll see what happens if I try it. I have to try it locally, to view my system resources. So, hopefully, that will answer my question.
Any other tests or if someone knows the answer, I'd appreciate it. Thank you, d11wtq!
With the code sample you gave, it would simply time out, assuming that you have your max_execution_time set to something other than 0 in your php.ini. I know that you have set_timeout(0) listed in your sample code. But, that's not a php function, and therefore wouldn't keep it from timing out (if you used that exact code). I think you meant set_time_limit(0). Anyway, I see what you meant, and I'll see what happens if I try it. I have to try it locally, to view my system resources. So, hopefully, that will answer my question.
Any other tests or if someone knows the answer, I'd appreciate it. Thank you, d11wtq!
- shiznatix
- DevNet Master
- Posts: 2745
- Joined: Tue Dec 28, 2004 5:57 pm
- Location: Tallinn, Estonia
- Contact:
when you close the browser it stops the script. otherwise, with the above example, it would keep executing even after you closed the browser. it would take about 30 seconds or more for that script to start showing excessive memory usage so if you just ran that script then quickly close your browser, check the memory usage and notice that nothing is happening. the script ends when you go away.
It could depend on what the script is doing when they refresh, close or move on. If the script is sending output to the browser but the browser suddenly goes away, then it makes sense for the server to kill it. Like the example d11wtq gave. However if the script is doing lots of work (database queries, etc.) and not sending output then I'm pretty sure the script won't die until it tries to send something to the browser and finds that it's not there anymore. It really depends on how the server manages it's processes. Can it only detect the absence of a browser when it tries to send it output? You may have to read up on the internals of whatever web server software you're using to know for sure. You could run some tests by having the script write to a log file with each step and see when that output stops.When a visitor to your site goes to a PHP page that does multiple database queries, what happens if they refresh, close the browser, or go to another page while the server is still running the script?
Thanks for the replies. I guess I'll have to try setting up a test script that I can tell what point the script gets killed, as sheila suggested. I'll take a look at the ignore_user_abort() function. The reason I'm trying to figure this out, is to stop double-clickers from running a script more than once. But, I wasn't sure what happens when they do a double click that runs a particular script. Does their 2nd click makes the first click's script die. Hope that makes sense. But, I'll try to set up a test that I can see what's happening. By the way, my host uses Windows 2003 Server w/ IIS6.
Thanks again, Swede
Thanks again, Swede
I found this at PHP.net:
As long as your order handling script does not output anything, there's no way that it will be aborted before it completes processing (unless it timeouts). PHP only senses user aborts when a script sends output. If there's no output sent to the client before processing completes, which is presumably the case for an order handling script, the script will run to completion.
So, the only time a script can be terminated due to the user hitting stop is when it sends output. If you don't send any output until processing completes, you don't have to worry about user aborts.
As long as your order handling script does not output anything, there's no way that it will be aborted before it completes processing (unless it timeouts). PHP only senses user aborts when a script sends output. If there's no output sent to the client before processing completes, which is presumably the case for an order handling script, the script will run to completion.
So, the only time a script can be terminated due to the user hitting stop is when it sends output. If you don't send any output until processing completes, you don't have to worry about user aborts.
- trukfixer
- Forum Contributor
- Posts: 174
- Joined: Fri May 21, 2004 3:14 pm
- Location: Miami, Florida, USA
check out the PRG patternSwede78 wrote:Thanks for the replies. I guess I'll have to try setting up a test script that I can tell what point the script gets killed, as sheila suggested. I'll take a look at the ignore_user_abort() function. The reason I'm trying to figure this out, is to stop double-clickers from running a script more than once. But, I wasn't sure what happens when they do a double click that runs a particular script. Does their 2nd click makes the first click's script die. Hope that makes sense. But, I'll try to set up a test that I can see what's happening. By the way, my host uses Windows 2003 Server w/ IIS6.
Thanks again, Swede
http://www.theserverside.com/articles/a ... tAfterPost
actually I plan to modify it slightly for some stuff I am working on , which is essentially, POST/REDIRECT/PROCESS/REDIRECT
basically no matter how many times the user hits the submit button (trigger finger/double click/race condition)
only one instance of the form goes to the posted page, and only one instance of the post data is sent to the processing page... since it will use SESSION data, and any subsequent POST requests sent after the initial click , at the POST page, are never processed because there's no session or browser to redirect session data to the processing page.. in essence, virtually guarantees only one post submission per browser session, and "refresh" exploits are broken to boot
I think I'll probably do something similar to that affect. However, I'm not sure yet if I'll need to use ignore_user_abort as it seems (according to someone else) that you don't need it. I'll have to test that. Haven't had a chance yet. But, I already planned on setting a session that flags whether or not the processes have already been done. That should do the trick.jshpro2 wrote:Why not set ignore user abort, and then set a flag when the page starts, if its called twice the second instance sees the flag and takes the appropriate actions
Thanks trukfixer. I took a quick glance at the link you provided. But, I'm going to need a more than a quick glance to understand the whole concept.
Swede