Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 84388 invoked from network); 12 Mar 2010 18:51:02 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 12 Mar 2010 18:51:02 -0000 Received: (qmail 71789 invoked by uid 500); 12 Mar 2010 18:50:22 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 71727 invoked by uid 500); 12 Mar 2010 18:50:22 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 71719 invoked by uid 99); 12 Mar 2010 18:50:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Mar 2010 18:50:21 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of j.zuckerman@gmail.com designates 209.85.222.201 as permitted sender) Received: from [209.85.222.201] (HELO mail-pz0-f201.google.com) (209.85.222.201) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Mar 2010 18:50:15 +0000 Received: by pzk39 with SMTP id 39so908678pzk.15 for ; Fri, 12 Mar 2010 10:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=gXTDUpvgyfbHrkc6AjTu0lCdOGgD7NNyk3GZtdk5v9w=; b=QbD6HejLO8JmhhLcsG1hM07aFrYil/KCqKvs2vxLMtnohXL31mlCyRhJjL2tlNtnCE FIOoSKQp9sX8EHIPdtqTt69To/FckJGcrL2p0E5txv/EF78kWT4rpqbl550YkkoMVbqX izD7XXrBINBQlef0pYa2Sia/oMxVqjk72qtec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=JKv9mXfowDXSHs+j15N1o++206bk54g6QhboN/6y0vEFvL106E0ioFCck3KBk9v1P0 AEQkGXa/6hWJJtSHd76f35y2QBheN7MtWtBj3Cs4I3V7s8nskFuKrAcEWvMq/gMSSN1N MDliQSRu7NrIvEzA+bKDkPlR4TSJmdSgk78fs= MIME-Version: 1.0 Received: by 10.114.8.2 with SMTP id 2mr2978655wah.91.1268419794274; Fri, 12 Mar 2010 10:49:54 -0800 (PST) In-Reply-To: <4B9A7B92.5000701@inkworkswell.com> References: <4B9A7B92.5000701@inkworkswell.com> From: Jonathan Zuckerman Date: Fri, 12 Mar 2010 10:49:34 -0800 Message-ID: <5ddb50771003121049i5c2c798fse4b4b80d2a149529@mail.gmail.com> To: users@httpd.apache.org Content-Type: multipart/alternative; boundary=00504502983643964204819eff4d X-Virus-Checked: Checked by ClamAV on apache.org Subject: Re: [users@httpd] mod_php script 'queue' --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 <howell.r@inkworks= well.com> wrote:
On 12-Mar-10 11:31, Nilesh Govindarajan wrote:
On Fri, Mar 12, 2010 at 6:49 PM, Bruno - e-comBR <bruno@e-combr.com.br> wrote:

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. 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:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
=C2=A0" =C2=A0 from the digest: users-digest-unsubscribe@httpd.ap= ache.org
For additional commands, e-mail: 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. =C2=A0When 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. =C2=A0The 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. =C2=A0If 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--