Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 47215 invoked from network); 16 Mar 2010 15:06:26 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 16 Mar 2010 15:06:26 -0000 Received: (qmail 65976 invoked by uid 500); 16 Mar 2010 15:06:23 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 65895 invoked by uid 500); 16 Mar 2010 15:06: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 65887 invoked by uid 99); 16 Mar 2010 15:06:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Mar 2010 15:06:22 +0000 X-ASF-Spam-Status: No, hits=-1.0 required=10.0 tests=AWL,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of john.iliffe@iliffe.ca designates 206.248.138.118 as permitted sender) Received: from [206.248.138.118] (HELO iliffe.ca) (206.248.138.118) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Mar 2010 15:06:18 +0000 Received: from 192.168.1.10 (unverified [192.168.1.1]) by iliffe.ca (SurgeMail 3.9e) with ESMTP id 2501-1735046 for ; Tue, 16 Mar 2010 11:05:56 -0400 From: John Iliffe To: users@httpd.apache.org In-Reply-To: References: <4B9A7B92.5000701@inkworkswell.com> <5ddb50771003121049i5c2c798fse4b4b80d2a149529@mail.gmail.com> <4B9A8F22.3080100@inkworkswell.com> Content-Type: text/plain Date: Tue, 16 Mar 2010 11:05:56 -0400 Message-Id: <1268751956.8669.10.camel@linuxprod2> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-35.0.4.el4) Content-Transfer-Encoding: 7bit X-Originating-IP: 192.168.1.1 X-Authenticated-User: john.iliffe@iliffe.ca Subject: Re: [users@httpd] mod_php script 'queue' 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