You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Sheryl <gu...@his.com> on 2011/12/09 18:02:18 UTC
[users@httpd] Clarification on Apache timouts
Greetings,
I have a situation in which a PHP script is getting hung on a socket call and never exiting. Also never getting to the point of sending back any output to the client in the form of HTML.
Before you tell me to ask the PHP list though, the language of the script is really irrelevant (and I have already posted on a PHP list concerning the call that is hanging).
The point is, my reading of the docs on the various timeouts in apache leads me to think that unless there is something on the way to/from the client none of the timeouts apply. I don't see a way to limit the time that something is *preparing* to send back a response.
Certainly Timeout at the default setting has no effect, and I don't see any other directive that looks promising.
Am I missing something?
Thanks,
Sheryl
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Clarification on Apache timeouts
Posted by Sheryl <gu...@his.com>.
Nick Kew wrote:
On Fri, 09 Dec 2011 14:36:02 -0500 (EST)
"Sheryl " <gu...@his.com> wrote:
> The developers say they can't fix the code and are taking the "apache is
> broken or it would solve this for us" tack. That's why I'm trying to find
> out more how the apache timeouts work.
> Apache timeouts don't affect connections made from PHP. That's the
> business of PHP, or the scripts concerned and their configuration.
Thanks. What I wanted was a sanity check.
> If you run PHP as CGI you could set a timeout after which to give
> up waiting and return an error to the client. man ulimit!
We don't run PHP as CGI. I've been working with various *NIX since 1988
and did think to review the ulimit page before I posted because I considered
trying it apache itself (briefly). Ulimit is fine if you have a process
chewing CPU or grabbing memory. Fortunately or not, that isn't the case here.
The timeout I need is on wall clock time, not CPU cycles. AFAICT from the
man page ulimit doesn't have that option.
Sheryl
--
Nick Kew
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Clarification on Apache timeouts
Posted by Nick Kew <ni...@webthing.com>.
On Fri, 09 Dec 2011 14:36:02 -0500 (EST)
"Sheryl " <gu...@his.com> wrote:
> The developers say they can't fix the code and are taking the "apache is broken or it would solve this for us" tack. That's why I'm trying to find out more how the apache timeouts work.
Apache timeouts don't affect connections made from PHP. That's the
business of PHP, or the scripts concerned and their configuration.
If you run PHP as CGI you could set a timeout after which to give
up waiting and return an error to the client. man ulimit!
--
Nick Kew
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Clarification on Apache timeouts
Posted by "J.Lance Wilkinson" <jl...@psu.edu>.
Sheryl wrote:
> J. Lance Wilkinson wrote:
>
>> I have had some locally build PHP scripts that run a very long time (doing
>> database lookups and so forth) before outputting the desired content. These
>> would time out like that.
>
>> Of course, a user would sit around waiting for a result and give up as well.
>> So I resolved both of these by putting a progress bar out in the output to
>> start with:
>
> [snip]
>
> Thanks. Interesting. Unfortunately it's a socket call that is hanging and
> never coming back. Since the call goes out into space and never completes
> there's no way for us to implement a progress bar.
A socket call IN THE PHP code? Then you can protect your session
w/ Apache w/ flush() calls like I was suggesting, and the timeouts
between the PHP code and your authentication server should be
adjustable and the timeout events trapable in the PHP code, based on
consulting the PHP "manuals" at http://www.php.net/manual/en/index.php
If the PHP code is accessible/maintainable by you and yours, that is.
> The whole thing has to do with socket connections to an authentication
> server. pass/fail works ok but users' accounts can get into states the code
> doesn't handle. The users do get impatient, as you say, and hit reload over
> and over and hit the max number of http connections periodically.
>
> The developers say they can't fix the code and are taking the "apache is
> broken or it would solve this for us" tack. That's why I'm trying to find
> out more how the apache timeouts work.
1. If "the developers" are saying they can't fix THEIR PHP code, I'd find new
developers. I've never had any formal training in PHP, but I've yet
to find something I wanted/needed to do using PHP that I wasn't able
to accomplish.
2. If "the developers" are saying they can't fix somebody else's PHP code due
to lack of understanding of PHP, see (1).
3. If "the developers" are saying they can't fix somebody else's PHP code due
to some contractual issue or something with a 3rd-party provider of
the PHP code, none of this is going to help. I'd be looking for
another 3rd party in that case.
IT's not clear where APACHE falls in all this. If the socket call is not in
the PHP code, but rather in a MODULE loaded dynamically or otherwise into
Apache, please cite the MODULE that the developers are using to do this.
Apache in and of itself, as I understand things (and no, I'm not a committer or
anything more than a user who's used Apache HTTPD in some for or another on 4
different OS's [OpenVMS, Windows, Solaris and Linux]for the past 7 or 8 years),
would not be doing any socket calls on behalf of any authentication system.
That kind of thing is only done from within the PHP user's PHP code, or
external to the PHP code in an Apache MODULE, which is NOT the same as Apache
HTTPD.
--
J.Lance Wilkinson ("Lance") InterNet: Lance.Wilkinson@psu.edu
Systems Design Specialist - Lead Phone: (814) 865-4870
Digital Library Technologies FAX: (814) 863-3560
E3 Paterno Library
Penn State University
University Park, PA 16802
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Clarification on Apache timeouts
Posted by Sheryl <gu...@his.com>.
J. Lance Wilkinson wrote:
> I have had some locally build PHP scripts that run a very long time (doing
> database lookups and so forth) before outputting the desired content. These
> would time out like that.
> Of course, a user would sit around waiting for a result and give up as well.
> So I resolved both of these by putting a progress bar out in the output to
> start with:
[snip]
Thanks. Interesting. Unfortunately it's a socket call that is hanging and never coming back. Since the call goes out into space and never completes there's no way for us to implement a progress bar.
The whole thing has to do with socket connections to an authentication server. pass/fail works ok but users' accounts can get into states the code doesn't handle. The users do get impatient, as you say, and hit reload over and over and hit the max number of http connections periodically.
The developers say they can't fix the code and are taking the "apache is broken or it would solve this for us" tack. That's why I'm trying to find out more how the apache timeouts work.
Sheryl
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Clarification on Apache timouts
Posted by "J.Lance Wilkinson" <jl...@psu.edu>.
Sheryl wrote:
> Greetings,
>
> I have a situation in which a PHP script is getting hung on a socket call
> and never exiting. Also never getting to the point of sending back any
> output to the client in the form of HTML.
>
> Before you tell me to ask the PHP list though, the language of the script is
> really irrelevant (and I have already posted on a PHP list concerning the
> call that is hanging).
>
> The point is, my reading of the docs on the various timeouts in apache leads
> me to think that unless there is something on the way to/from the client
> none of the timeouts apply. I don't see a way to limit the time that
> something is *preparing* to send back a response.
I have had some locally build PHP scripts that run a very long time (doing
database lookups and so forth) before outputting the desired content. These
would time out like that.
Of course, a user would sit around waiting for a result and give up as well.
So I resolved both of these by putting a progress bar out in the output to
start with:
echo "<script language=JavaScript "
. " src=/images/ProgressBar.js></script>\n";
echo "<div id=loading_bar></div>\n";
echo "<script language=JavaScript>\n";
echo " progressBar = "
. "new ProgressBar('/images/Wrt_progressbar_empty.png',"
. " '/images/Wrt_progressbar_full.png', 404, "
. " 12);\n";
echo "progressBar.appendTo(document.getElementById('loading_bar'));\n";
echo "</script>\n";
flush();
Then I'd put in the database processing loop output that would advance the
progress bar:
$pct = (int)( ( ($idx) * 100 ) / $limit);
echo "<script language=JavaScript>setPercentage($pct);</script>\n";
echo "<script language=JavaScript> "
. " progressBar.setLoadingProgress($pct);</script>\n";
flush();
The PHP flush() function is described here:
http://php.net/manual/en/function.flush.php
The ProgressBar.js script I got someplace, don't recall where, and it only has
as its internal documentation as "author pit" which doesn't help much. Bottom
line is the resolution to your PROBLEM might be the PHP flush() function, to
make your SCRIPT compatible w/ your Apache timeouts, while the way you hide the
jumpiness this might push into your users' browsers is to actually USE the
delay to tell the user something they might be interested in, like this
progress bar or some other one. The JavaScript itself is only 93 lines
including commentary, so I'm happy to share that out if anybody wants it.
--
J.Lance Wilkinson ("Lance") InterNet: Lance.Wilkinson@psu.edu
Systems Design Specialist - Lead Phone: (814) 865-4870
Digital Library Technologies FAX: (814) 863-3560
E3 Paterno Library
Penn State University
University Park, PA 16802
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org