mod_php script "queue"

mod_php script "queue"

am 12.03.2010 14:19:28 von Bruno - e-comBR

--0016e6dab03490bb0004819a610e
Content-Type: text/plain; charset=ISO-8859-1

Hello,

While performing some tests, I saw that:

-When I run a PHP script with a infinite loop, the apache process(using
mod_prefork) still busy (php.ini timeouts disabled) 'forever' (the obvious
fact).
-When I run again the same script with the same URL, apache seems to
'enqueue' the second request, because no other process seems to be running.
-But if I send a SIGTERM to the apache process, it seems to begin processing
the second script, and stop the first.
-If I run the script using a different URL(just by changing the query
string), it seems to run both process parallely.

It's just the first step. I've done the same tests, but using mod_rewrite.
It's different: even with different URL, the process get 'queued'.

I just ask: is this the expected behaviour??

It's causing a little throuble for me. When a PHP script generates a bigger
report(taking about ten minutes or more), the user seems to be impatient.
They're doing refreshs on the page. So, for each refresh apache is queuing a
new script, and just begin running this when the queue is empty again.

What do you suggest me?

Thank you,
Bruno Moreira Guedes

--0016e6dab03490bb0004819a610e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,

While performing some tests, I saw that:

-When I run a=
PHP script with a infinite loop, the apache process(using mod_prefork) sti=
ll busy (php.ini timeouts disabled) 'forever' (the obvious fact). r>
-When I run again the same script with the same URL, apache seems to 'e=
nqueue' the second request, because no other process seems to be runnin=
g.
-But if I send a SIGTERM to the apache process, it seems to begin pro=
cessing the second script, and stop the first.

-If I run the script using a different URL(just by changing the query strin=
g), it seems to run both process parallely.

It's just the first =
step. I've done the same tests, but using mod_rewrite. It's differe=
nt: even with different URL, the process get 'queued'.


I just ask: is this the expected behaviour??

It's causing a =
little throuble for me. When a PHP script generates a bigger report(taking =
about ten minutes or more), the user seems to be impatient. They're doi=
ng refreshs on the page. So, for each refresh apache is queuing a new scrip=
t, and just begin running this when the queue is empty again.


color: rgb(255, 255, 255);" title=3D"o que voc=EAs me sugerem?">What do you=
suggest me?


Thank you,
Bruno Moreira Guedes


--0016e6dab03490bb0004819a610e--

Re: mod_php script "queue"

am 12.03.2010 17:31:54 von Nilesh Govindrajan

On Fri, Mar 12, 2010 at 6:49 PM, Bruno - e-comBR wrote:
> Hello,
>
> While performing some tests, I saw that:
>
> -When I run a PHP script with a infinite loop, the apache process(using
> mod_prefork) still busy (php.ini timeouts disabled) 'forever' (the obvious
> fact).
> -When I run again the same script with the same URL, apache seems to
> 'enqueue' the second request, because no other process seems to be running.
> -But if I send a SIGTERM to the apache process, it seems to begin processing
> the second script, and stop the first.
> -If I run the script using a different URL(just by changing the query
> string), it seems to run both process parallely.
>
> It's just the first step. I've done the same tests, but using mod_rewrite.
> It's different: even with different URL, the process get 'queued'.
>
> I just ask: is this the expected behaviour??
>
> It's causing a little throuble for me. When a PHP script generates a bigger
> report(taking about ten minutes or more), the user seems to be impatient.
> They're doing refreshs on the page. So, for each refresh apache is queuing a
> new script, and just begin running this when the queue is empty again.
>
> What do you suggest me?
>
> Thank you,
> Bruno Moreira Guedes
>

I don't use mod_php, so don't know about its behavior. But I recommend
you inform the users that the report can take upto ten minutes to
generate and to be patient. That's the only solution I see.

--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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: mod_php script "queue"

am 12.03.2010 18:36:18 von Reese

On 12-Mar-10 11:31, Nilesh Govindarajan wrote:
> On Fri, Mar 12, 2010 at 6:49 PM, Bruno - e-comBR wrote:

>> It's causing a little throuble for me. When a PHP script generates a bigger
>> report(taking about ten minutes or more), the user seems to be impatient.
>> They're doing refreshs on the page. So, for each refresh apache is queuing a
>> new script, and just begin running this when the queue is empty again.
>>
>> What do you suggest me?
>>
>> Thank you,
>> Bruno Moreira Guedes
>>
>
> I don't use mod_php, so don't know about its behavior. But I recommend
> you inform the users that the report can take upto ten minutes to
> generate and to be patient. That's the only solution I see.

Else, if you can make the PHP script 'smart' in some way so that a
popup or other visual indicator will give constant, visual feedback
on the progress of the request. With a "Cancel" button that functions
to kill the original request while blocking page refreshes. They can
start over from scratch if they like.

Reese



------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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: mod_php script "queue"

am 12.03.2010 18:50:51 von Nilesh Govindrajan

On Fri, Mar 12, 2010 at 11:06 PM, Reese wrote:
> On 12-Mar-10 11:31, Nilesh Govindarajan wrote:
>>
>> On Fri, Mar 12, 2010 at 6:49 PM, Bruno - e-comBR
>> wrote:
>
>>> It's causing a little throuble for me. When a PHP script generates a
>>> bigger
>>> report(taking about ten minutes or more), the user seems to be impatien=
t.
>>> They're doing refreshs on the page. So, for each refresh apache is
>>> queuing a
>>> new script, and just begin running this when the queue is empty again.
>>>
>>> What do you suggest me?
>>>
>>> Thank you,
>>> Bruno Moreira Guedes
>>>
>>
>> I don't use mod_php, so don't know about its behavior. But I recommend
>> you inform the users that the report can take upto ten minutes to
>> generate and to be patient. That's the only solution I see.
>
> Else, if you can make the PHP script 'smart' in some way so that a
> popup or other visual indicator will give constant, visual feedback
> on the progress of the request. With a "Cancel" button that functions
> to kill the original request while blocking page refreshes. They can
> start over from scratch if they like.
>
> Reese
>
>
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project=
..
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> =A0" =A0 from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>

I think that's possible with AJAX-JSON combination.
But the cronjob solution will be best if he doesn't know PHP (an
administrator's job is not to tweak the web-interface!)

--=20
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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: mod_php script "queue"

am 12.03.2010 19:49:34 von Jonathan Zuckerman

--00504502983643964204819eff4d
Content-Type: text/plain; charset=UTF-8

On Fri, Mar 12, 2010 at 9:36 AM, Reese wrote:

> On 12-Mar-10 11:31, Nilesh Govindarajan wrote:
>
>> On Fri, Mar 12, 2010 at 6:49 PM, Bruno - e-comBR
>> wrote:
>>
>
> It's causing a little throuble for me. When a PHP script generates a
>>> bigger
>>> report(taking about ten minutes or more), the user seems to be impatient.
>>> They're doing refreshs on the page. So, for each refresh apache is
>>> queuing a
>>> new script, and just begin running this when the queue is empty again.
>>>
>>> What do you suggest me?
>>>
>>> Thank you,
>>> Bruno Moreira Guedes
>>>
>>>
>> I don't use mod_php, so don't know about its behavior. But I recommend
>> you inform the users that the report can take upto ten minutes to
>> generate and to be patient. That's the only solution I see.
>>
>
> Else, if you can make the PHP script 'smart' in some way so that a
> popup or other visual indicator will give constant, visual feedback
> on the progress of the request. With a "Cancel" button that functions
> to kill the original request while blocking page refreshes. They can
> start over from scratch if they like.
>
> Reese
>
>
>
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See 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
>
>
Is there any way to cache the report?

Maybe for that specific page (or the reports pages in general) you should
institute a process whereby the webpage doesn't run the report itself but
acts an an interface to a CLI task that generates the report. When you hit
the webpage, it attempts to obtain a "report lock", at which point the
report begins to run, once the report is generated the lock can be released,
and the web page can retrieve and report the results. The lock can be
implemented any number of ways, I've done it in the past by simply touching
and then deleting a file in the /tmp folder.

To eventually ensure the user sees the report when it's done being
generated, you could do some fancy Keep-alive with the http request, or just
have some javascript on the page that automatically reloads it, and upon
reload the script will check to see if there's a report built for that user,
otherwise it checks to see if there's a lock. If there's a lock, it stops
and waits to try again soon. If there is no lock, it starts a new report.

Just some thoughts! Good luck with your problem, I don't think it's really
an apache problem.

--00504502983643964204819eff4d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 12, 2010 at 9:36 AM, Reese =3D"ltr"><howell.r@inkworks=
well.com
>
wrote:
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

On 12-Mar-10 11:31, Nilesh Govindarajan wrote:

x #ccc solid;padding-left:1ex">
On Fri, Mar 12, 2010 at 6:49 PM, Bruno - e-comBR < o@e-combr.com.br" target=3D"_blank">bruno@e-combr.com.br> wrote:




0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">


It's causing a little throuble for me. When a PHP script generates a bi=
gger

report(taking about ten minutes or more), the user seems to be impatient. r>
They're doing refreshs on the page. So, for each refresh apache is queu=
ing a

new script, and just begin running this when the queue is empty again.



What do you suggest me?



Thank you,

Bruno Moreira Guedes






I don't use mod_php, so don't know about its behavior. But I recomm=
end

you inform the users that the report can take upto ten minutes to

generate and to be patient. That's the only solution I see.




Else, if you can make the PHP script 'smart' in some way so that a<=
br>
popup or other visual indicator will give constant, visual feedback

on the progress of the request. With a "Cancel" button that funct=
ions

to kill the original request while blocking page refreshes. They can

start over from scratch if they like.



Reese








------------------------------------------------------------ ---------

The official User-To-User support forum of the Apache HTTP Server Project.<=
br>
See <URL: lank">http://httpd.apache.org/userslist.html> for more info.

To unsubscribe, e-mail: g" target=3D"_blank">users-unsubscribe@httpd.apache.org

 "   from the digest: cribe@httpd.apache.org" target=3D"_blank">users-digest-unsubscribe@httpd.ap=
ache.org


For additional commands, e-mail: org" target=3D"_blank">users-help@httpd.apache.org




Is there any way to cache the repor=
t?

Maybe for that specific page (or the reports pa=
ges in general) you should institute a process whereby the webpage doesn=
9;t run the report itself but acts an an interface to a CLI task that gener=
ates the report.  When you hit the webpage, it attempts to obtain a &q=
uot;report lock", at which point the report begins to run, once the re=
port is generated the lock can be released, and the web page can retrieve a=
nd report the results.  The lock can be implemented any number of ways=
, I've done it in the past by simply touching and then deleting a file =
in the /tmp folder.



To eventually ensure the user sees the report when it&#=
39;s done being generated, you could do some fancy Keep-alive with the http=
request, or just have some javascript on the page that automatically reloa=
ds it, and upon reload the script will check to see if there's a report=
built for that user, otherwise it checks to see if there's a lock. =C2=
=A0If there's a lock, it stops and waits to try again soon.  If th=
ere is no lock, it starts a new report.



Just some thoughts! Good luck with your problem, I don&=
#39;t think it's really an apache problem.


--00504502983643964204819eff4d--

Re: mod_php script "queue"

am 12.03.2010 19:59:46 von Reese

On 12-Mar-10 13:49, Jonathan Zuckerman wrote:
> On Fri, Mar 12, 2010 at 9:36 AM, Reese wrote:
>
>> On 12-Mar-10 11:31, Nilesh Govindarajan wrote:
>>
>>> On Fri, Mar 12, 2010 at 6:49 PM, Bruno - e-comBR
>>> wrote:
>>>
>> It's causing a little throuble for me. When a PHP script generates a
>>>> bigger
>>>> report(taking about ten minutes or more), the user seems to be impatient.
>>>> They're doing refreshs on the page. So, for each refresh apache is
>>>> queuing a
>>>> new script, and just begin running this when the queue is empty again.
>>>>
>>>> What do you suggest me?
>>>>
>>>> Thank you,
>>>> Bruno Moreira Guedes
>>>>
>>>>
>>> I don't use mod_php, so don't know about its behavior. But I recommend
>>> you inform the users that the report can take upto ten minutes to
>>> generate and to be patient. That's the only solution I see.
>>>
>> Else, if you can make the PHP script 'smart' in some way so that a
>> popup or other visual indicator will give constant, visual feedback
>> on the progress of the request. With a "Cancel" button that functions
>> to kill the original request while blocking page refreshes. They can
>> start over from scratch if they like.
>>
>> Reese
>>
>>
>>
>>
>> ------------------------------------------------------------ ---------
>> The official User-To-User support forum of the Apache HTTP Server Project.
>> See 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
>>
>>
> Is there any way to cache the report?

You could get the parameters sorted out, then create a cron job
from it and feed it to a .log file. This log file could be made
available to administrators only, the world or something in
between, depending on where in the file system it is located and
the associated permissions.

> To eventually ensure the user sees the report when it's done being
> generated, you could do some fancy Keep-alive with the http request, or just
> have some javascript on the page that automatically reloads it, and upon
> reload the script will check to see if there's a report built for that user,
> otherwise it checks to see if there's a lock. If there's a lock, it stops
> and waits to try again soon. If there is no lock, it starts a new report.

Or compress and store or mail it to them (and others?), starting a new
log file after each clock cycle.

This is starting to feel like reinventing HTTP access logs. We got off
track somewhere.

Reese



------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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: mod_php script "queue"

am 16.03.2010 14:45:36 von Bruno - e-comBR

--0016e6d778ed6749700481eb367e
Content-Type: text/plain; charset=ISO-8859-1

2010/3/12 Reese

> On 12-Mar-10 13:49, Jonathan Zuckerman wrote:
>
>> On Fri, Mar 12, 2010 at 9:36 AM, Reese wrote:
>>
>> On 12-Mar-10 11:31, Nilesh Govindarajan wrote:
>>>
>>> On Fri, Mar 12, 2010 at 6:49 PM, Bruno - e-comBR
>>>> wrote:
>>>>
>>>> It's causing a little throuble for me. When a PHP script generates a
>>>
>>>> bigger
>>>>> report(taking about ten minutes or more), the user seems to be
>>>>> impatient.
>>>>> They're doing refreshs on the page. So, for each refresh apache is
>>>>> queuing a
>>>>> new script, and just begin running this when the queue is empty again.
>>>>>
>>>>> What do you suggest me?
>>>>>
>>>>> Thank you,
>>>>> Bruno Moreira Guedes
>>>>>
>>>>>
>>>>> I don't use mod_php, so don't know about its behavior. But I recommend
>>>> you inform the users that the report can take upto ten minutes to
>>>> generate and to be patient. That's the only solution I see.
>>>>
>>>> Else, if you can make the PHP script 'smart' in some way so that a
>>> popup or other visual indicator will give constant, visual feedback
>>> on the progress of the request. With a "Cancel" button that functions
>>> to kill the original request while blocking page refreshes. They can
>>> start over from scratch if they like.
>>>
>>> Reese
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------ ---------
>>> The official User-To-User support forum of the Apache HTTP Server
>>> Project.
>>> See 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
>>>
>>>
>>> Is there any way to cache the report?
>>
>
> You could get the parameters sorted out, then create a cron job
> from it and feed it to a .log file. This log file could be made
> available to administrators only, the world or something in
> between, depending on where in the file system it is located and
> the associated permissions.
>
>
> To eventually ensure the user sees the report when it's done being
>> generated, you could do some fancy Keep-alive with the http request, or
>> just
>> have some javascript on the page that automatically reloads it, and upon
>> reload the script will check to see if there's a report built for that
>> user,
>> otherwise it checks to see if there's a lock. If there's a lock, it stops
>> and waits to try again soon. If there is no lock, it starts a new report.
>>
>
> Or compress and store or mail it to them (and others?), starting a new
> log file after each clock cycle.
>
> This is starting to feel like reinventing HTTP access logs. We got off
> track somewhere.
>
>
> Reese
>
>
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See 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
>
>

I would like to thank everyone by this ideas. I'll test each one and see
what happen :-)
But if someone knows a way to adjust this behaviour(some 'undocumented
procedure'), please tell me.

Thanks,
Bruno Moreira Guedes

--0016e6d778ed6749700481eb367e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


2010/3/12 Reese < f=3D"mailto:howell.r@inkworkswell.com">howell.r@inkworkswell .com> pan>
gb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 12-Mar-10 13:49, Jonathan Zuckerman wr=
ote:

204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, Mar 12, 2010 at 9:36 AM, Reese < rkswell.com" target=3D"_blank">howell.r@inkworkswell.com> wrote:



204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 12-Mar-10 11:31, Nilesh Govindarajan wrote:



204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, Mar 12, 2010 at 6:49 PM, Bruno - e-comBR < o@e-combr.com.br" target=3D"_blank">bruno@e-combr.com.br>

wrote:




=A0It's causing a little throuble for me. When a PHP script generates a=


204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin=
: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

bigger

report(taking about ten minutes or more), the user seems to be impatient. r>
They're doing refreshs on the page. So, for each refresh apache is

queuing a

new script, and just begin running this when the queue is empty again.



What do you suggest me?



Thank you,

Bruno Moreira Guedes






I don't use mod_php, so don't know about its behavior. But I recomm=
end

you inform the users that the report can take upto ten minutes to

generate and to be patient. That's the only solution I see.




Else, if you can make the PHP script 'smart' in some way so that a<=
br>
popup or other visual indicator will give constant, visual feedback

on the progress of the request. With a "Cancel" button that funct=
ions

to kill the original request while blocking page refreshes. They can

start over from scratch if they like.



Reese









------------------------------------------------------------ ---------

The official User-To-User support forum of the Apache HTTP Server Project.<=
br>
See <URL: lank">http://httpd.apache.org/userslist.html> for more info.

To unsubscribe, e-mail: g" target=3D"_blank">users-unsubscribe@httpd.apache.org

=A0" =A0 from the digest: ttpd.apache.org" target=3D"_blank">users-digest-unsubscribe@httpd.apache.or=
g


For additional commands, e-mail: org" target=3D"_blank">users-help@httpd.apache.org






Is there any way to cache the report?




You could get the parameters sorted out, then create a cron job

from it and feed it to a .log file. This log file could be made

available to administrators only, the world or something in

between, depending on where in the file system it is located and

the associated permissions.




204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
To eventually ensure the user sees the report when it's done being

generated, you could do some fancy Keep-alive with the http request, or jus=
t

have some javascript on the page that automatically reloads it, and upon >
reload the script will check to see if there's a report built for that =
user,

otherwise it checks to see if there's a lock. =A0If there's a lock,=
it stops

and waits to try again soon. =A0If there is no lock, it starts a new report=
..




Or compress and store or mail it to them (and others?), starting a new

log file after each clock cycle.



This is starting to feel like reinventing HTTP access logs. We got off

track somewhere.




Reese







------------------------------------------------------------ ---------

The official User-To-User support forum of the Apache HTTP Server Project.<=
br>
See <URL: lank">http://httpd.apache.org/userslist.html> for more info.

To unsubscribe, e-mail: g" target=3D"_blank">users-unsubscribe@httpd.apache.org

=A0" =A0 from the digest: httpd.apache.org" target=3D"_blank">users-digest-unsubscribe@httpd.apache.o=
rg


For additional commands, e-mail: org" target=3D"_blank">users-help@httpd.apache.org





=3D"">
gin: 2px 6px 0pt 0pt; float: left;"> -flash" data=3D"http://www.gstatic.com/translate/sound_player.swf" id=3D"tt=
s_object" width=3D"18" height=3D"18"> /translate/sound_player.swf" name=3D"movie"> anslate_tts%3Fq%3DI%2Bwould%2Blike%2Bto%2Bthank%2Beveryone%2 Bfor%2Bideas%26=
tl%3Den" name=3D"flashvars"> ram value=3D"always" name=3D"allowScriptAccess">

r: rgb(255, 255, 255);" title=3D"eu gostaria de agradecer a todos pelas id=
=E9ias" onmouseover=3D"this.style.backgroundColor=3D'#ebeff9'" onmo=
useout=3D"this.style.backgroundColor=3D'#fff'">I would like to than=
k everyone by this ideas. I'll test each one and see what happen :-) >
But if someone knows a way to adjust this behaviour(some 'undocumented =
procedure'), please tell me.

Thanks,
Bruno Moreira Guedes
=


--0016e6d778ed6749700481eb367e--

Re: mod_php script "queue"

am 16.03.2010 15:00:58 von Roger

Do you have persistent connections on?

-r

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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: mod_php script "queue"

am 16.03.2010 15:21:28 von Bruno - e-comBR

--0016e64c0632a47e670481ebb635
Content-Type: text/plain; charset=ISO-8859-1

2010/3/16 Roger

> Do you have persistent connections on?
>
> -r
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See 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
>
>
Are you talking about keep alive?
If so, yes, we're using it.

--0016e64c0632a47e670481ebb635
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


2010/3/16 Roger < f=3D"mailto:rnodal@gmail.com">rnodal@gmail.com>
e class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204);=
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Do you have persistent connections on?



-r



------------------------------------------------------------ ---------

The official User-To-User support forum of the Apache HTTP Server Project.<=
br>
See <URL: lank">http://httpd.apache.org/userslist.html> for more info.

To unsubscribe, e-mail: g">users-unsubscribe@httpd.apache.org

=A0 " =A0 from the digest: @httpd.apache.org">users-digest-unsubscribe@httpd.apache.org

For additional commands, e-mail: org">users-help@httpd.apache.org




Are you talking about keep alive?
If =
so, yes, we're using it.



--0016e64c0632a47e670481ebb635--

Re: mod_php script "queue"

am 16.03.2010 15:33:25 von Roger

I may have miss-understood your question but the fact that your second
script gets put in a queue may have to do with the fact that you are
using persistent connections. Have you tried disabling this off to see
if apache process the second request right of way?

I'm not saying that disabling persistent connections is the solution
that you are having with your report page, I'm mostly referring to the
question of whether this was the expected behavior.

-r

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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: mod_php script "queue"

am 16.03.2010 15:35:08 von Roger

Sorry I meant to say:

"I'm not saying that disabling persistent connections is the solution
to the problem
that you are having with your report page"

-r

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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: mod_php script "queue"

am 16.03.2010 16:05:56 von John Iliffe

On Tue, 2010-16-03 at 10:45 -0300, Bruno - e-comBR wrote:
>
> 2010/3/12 Reese
> On 12-Mar-10 13:49, Jonathan Zuckerman wrote:
> On Fri, Mar 12, 2010 at 9:36 AM, Reese
> wrote:
>
> On 12-Mar-10 11:31, Nilesh Govindarajan wrote:
>
> On Fri, Mar 12, 2010 at 6:49 PM, Bruno
> - e-comBR
> wrote:
>
> It's causing a little throuble for me. When a
> PHP script generates a
> bigger
> report(taking about ten
> minutes or more), the user
> seems to be impatient.
> They're doing refreshs on the
> page. So, for each refresh
> apache is
> queuing a
> new script, and just begin
> running this when the queue is
> empty again.
>
> What do you suggest me?
>
> Thank you,
> Bruno Moreira Guedes
>
>
> I don't use mod_php, so don't know
> about its behavior. But I recommend
> you inform the users that the report
> can take upto ten minutes to
> generate and to be patient. That's the
> only solution I see.
>
> Else, if you can make the PHP script 'smart'
> in some way so that a
> popup or other visual indicator will give
> constant, visual feedback
> on the progress of the request. With a
> "Cancel" button that functions
> to kill the original request while blocking
> page refreshes. They can
> start over from scratch if they like.
>
> Reese
>
>
>
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the
> Apache HTTP Server Project.
> See
>
> 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
>
>
> Is there any way to cache the report?
>
>
> You could get the parameters sorted out, then create a cron
> job
> from it and feed it to a .log file. This log file could be
> made
> available to administrators only, the world or something in
> between, depending on where in the file system it is located
> and
> the associated permissions.
>
>
> To eventually ensure the user sees the report when
> it's done being
> generated, you could do some fancy Keep-alive with the
> http request, or just
> have some javascript on the page that automatically
> reloads it, and upon
> reload the script will check to see if there's a
> report built for that user,
> otherwise it checks to see if there's a lock. If
> there's a lock, it stops
> and waits to try again soon. If there is no lock, it
> starts a new report.
>
>
> Or compress and store or mail it to them (and others?),
> starting a new
> log file after each clock cycle.
>
> This is starting to feel like reinventing HTTP access logs. We
> got off
> track somewhere.
>
>
> Reese
>
>
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP
> Server Project.
> See 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
>
>
>
>
>
> I would like to thank everyone by this ideas. I'll test each one and
> see what happen :-)
> But if someone knows a way to adjust this behaviour(some 'undocumented
> procedure'), please tell me.
>
> Thanks,
> Bruno Moreira Guedes
>
If you have JavaScript in the client programme, do the PHP request as a
background (AJAX) request. Set the client script so that the request is
locked until a response is received. You should also us a timer to
allow the user to restart in case no response is ever received ;-)

You can also use the client script to cancel the PHP processing if the
client goes away - that is the user gets bored waiting and closes the
session.

Ten minutes seems like a long time for a real person to wait and using
background client processing through AJAX will allow the client to use
his terminal for something more productive during that time.

John



------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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