RE: [PHP] continue working after finishing up with the http client

2009-05-27 Thread bruce
hi tom...

exacly what are you trying to accomplish? is this in a web app? has the user
hit the site, logged in, etc?

can you provide an example of what the sequence of events are that you're
trying to deal with..

thanks


-Original Message-
From: Tom Worster [mailto:f...@thefsb.org]
Sent: Wednesday, May 27, 2009 6:27 AM
To: php-general@lists.php.net
Subject: [PHP] continue working after finishing up with the http client


what options are there to do the following:

1. receive request from client (including post data)

2. do some work, update the db, prepare output for client

3. send output and finish up with the client

4. do some more work that might take considerable time, updating the db some
more

it would be convenient and efficient if step 4 took place within the same
process as steps 1-3. but output control seems not to be sufficient:
ob_flush(); flush(); sends the output but leave the client waiting for more.
is there a way to close the connection as though exit; were called but
without quitting the script?

alternatively the script could start another process, copy over whatever
data is needed and disconnect from it. but that has its overheads on the
server.

are the other possibilities?

tia
tom



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] continue working after finishing up with the http client

2009-05-27 Thread Tom Worster
On 5/27/09 9:50 AM, bruce bedoug...@earthlink.net wrote:

 exacly what are you trying to accomplish? is this in a web app? has the user
 hit the site, logged in, etc?
 
 can you provide an example of what the sequence of events are that you're
 trying to deal with..

it is a web app.

let's say for example that we're processing an ajax query. say we can
normally generate and deliver the response to the client quickly but the
speed depends on a cache with a relatively low miss rate.

now, when we get a cache miss, imagine that generating the client response
from scratch takes significantly less time than generating and inserting the
new cache entry corresponding to the query. so we want to send the response
to the client and then process the cache entry.

without getting into whether or not this cache design makes sense, my
question in this example is: what options are there for ending the http
transition and then continuing on to do the cache update work?
 

 -Original Message-
 From: Tom Worster [mailto:f...@thefsb.org]
 Sent: Wednesday, May 27, 2009 6:27 AM
 To: php-general@lists.php.net
 Subject: [PHP] continue working after finishing up with the http client
 
 
 what options are there to do the following:
 
 1. receive request from client (including post data)
 
 2. do some work, update the db, prepare output for client
 
 3. send output and finish up with the client
 
 4. do some more work that might take considerable time, updating the db some
 more
 
 it would be convenient and efficient if step 4 took place within the same
 process as steps 1-3. but output control seems not to be sufficient:
 ob_flush(); flush(); sends the output but leave the client waiting for more.
 is there a way to close the connection as though exit; were called but
 without quitting the script?
 
 alternatively the script could start another process, copy over whatever
 data is needed and disconnect from it. but that has its overheads on the
 server.
 
 are the other possibilities?



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] continue working after finishing up with the http client

2009-05-27 Thread David Otton
2009/5/27 Tom Worster f...@thefsb.org:

 without getting into whether or not this cache design makes sense, my
 question in this example is: what options are there for ending the http
 transition and then continuing on to do the cache update work?

You either continue processing then-and-there (exec(), or whatever) or
you put the job in queue to be dealt with at your leisure.

The queue is the better solution if you're concerned about processor
load, as you can prioritise it. The exec() is simpler to implement.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP] continue working after finishing up with the http client

2009-05-27 Thread bruce
hi tom...

if i understand your state diagram/workflow process. your server repsonds to
the client request, with two actions...

 action 1) return data to client relatively fast
 action 2) insert the data into your cache (or whereever) which takes
time...

is this correct?

do you have to somehow use the 'new'/updated cache data in the future
actions with the client...

it might be possible for you to have a setup, where you have an external
cron process, or other continually running process that does the cache
insertions



-Original Message-
From: Tom Worster [mailto:f...@thefsb.org]
Sent: Wednesday, May 27, 2009 7:14 AM
To: bruce; php-general@lists.php.net
Subject: Re: [PHP] continue working after finishing up with the http
client


On 5/27/09 9:50 AM, bruce bedoug...@earthlink.net wrote:

 exacly what are you trying to accomplish? is this in a web app? has the
user
 hit the site, logged in, etc?

 can you provide an example of what the sequence of events are that you're
 trying to deal with..

it is a web app.

let's say for example that we're processing an ajax query. say we can
normally generate and deliver the response to the client quickly but the
speed depends on a cache with a relatively low miss rate.

now, when we get a cache miss, imagine that generating the client response
from scratch takes significantly less time than generating and inserting the
new cache entry corresponding to the query. so we want to send the response
to the client and then process the cache entry.

without getting into whether or not this cache design makes sense, my
question in this example is: what options are there for ending the http
transition and then continuing on to do the cache update work?


 -Original Message-
 From: Tom Worster [mailto:f...@thefsb.org]
 Sent: Wednesday, May 27, 2009 6:27 AM
 To: php-general@lists.php.net
 Subject: [PHP] continue working after finishing up with the http client


 what options are there to do the following:

 1. receive request from client (including post data)

 2. do some work, update the db, prepare output for client

 3. send output and finish up with the client

 4. do some more work that might take considerable time, updating the db
some
 more

 it would be convenient and efficient if step 4 took place within the same
 process as steps 1-3. but output control seems not to be sufficient:
 ob_flush(); flush(); sends the output but leave the client waiting for
more.
 is there a way to close the connection as though exit; were called but
 without quitting the script?

 alternatively the script could start another process, copy over whatever
 data is needed and disconnect from it. but that has its overheads on the
 server.

 are the other possibilities?



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] continue working after finishing up with the http client

2009-05-27 Thread Tom Worster
On 5/27/09 12:35 PM, bruce bedoug...@earthlink.net wrote:

 hi tom...
 
 if i understand your state diagram/workflow process. your server repsonds to
 the client request, with two actions...
 
  action 1) return data to client relatively fast
  action 2) insert the data into your cache (or whereever) which takes
 time...
 
 is this correct?

sure. but it was just an example of use of such an output and connection
control technique.


 do you have to somehow use the 'new'/updated cache data in the future
 actions with the client...

this was part of the example, yes. but another example could be that you
process a web client's html form request, then send the client its response,
close the client connection and then proceed with a whole bunch of complex
logging of what was done.


 it might be possible for you to have a setup, where you have an external
 cron process, or other continually running process that does the cache
 insertions

yes. this is one of the proposals david otton made, both of which are
reasonable but do not enjoy the convenience or efficiency of doing the end
work (e.g. the cache insertion) in the same process and memory space as the
script that did the front work (e.g. processed the cache miss and sent the
ajax response). doing the end work in a separate process comes with the
overhead of serializing and communicating data to the other process.

i found a web page suggesting that you can get a client to close the
connection if you set ignore_user_abort(), then send Connection: close and
Content-Length: #octets headers, then send the response followed by
ob_flush and flush. can't say i'm in love with this.

http://waynepan.com/2007/10/11/how-to-use-ignore_user_abort-to-do-process-ou
t-of-band/




 -Original Message-
 From: Tom Worster [mailto:f...@thefsb.org]
 Sent: Wednesday, May 27, 2009 7:14 AM
 To: bruce; php-general@lists.php.net
 Subject: Re: [PHP] continue working after finishing up with the http
 client
 
 
 On 5/27/09 9:50 AM, bruce bedoug...@earthlink.net wrote:
 
 exacly what are you trying to accomplish? is this in a web app? has the
 user
 hit the site, logged in, etc?
 
 can you provide an example of what the sequence of events are that you're
 trying to deal with..
 
 it is a web app.
 
 let's say for example that we're processing an ajax query. say we can
 normally generate and deliver the response to the client quickly but the
 speed depends on a cache with a relatively low miss rate.
 
 now, when we get a cache miss, imagine that generating the client response
 from scratch takes significantly less time than generating and inserting the
 new cache entry corresponding to the query. so we want to send the response
 to the client and then process the cache entry.
 
 without getting into whether or not this cache design makes sense, my
 question in this example is: what options are there for ending the http
 transition and then continuing on to do the cache update work?
 
 
 -Original Message-
 From: Tom Worster [mailto:f...@thefsb.org]
 Sent: Wednesday, May 27, 2009 6:27 AM
 To: php-general@lists.php.net
 Subject: [PHP] continue working after finishing up with the http client
 
 
 what options are there to do the following:
 
 1. receive request from client (including post data)
 
 2. do some work, update the db, prepare output for client
 
 3. send output and finish up with the client
 
 4. do some more work that might take considerable time, updating the db
 some
 more
 
 it would be convenient and efficient if step 4 took place within the same
 process as steps 1-3. but output control seems not to be sufficient:
 ob_flush(); flush(); sends the output but leave the client waiting for
 more.
 is there a way to close the connection as though exit; were called but
 without quitting the script?
 
 alternatively the script could start another process, copy over whatever
 data is needed and disconnect from it. but that has its overheads on the
 server.
 
 are the other possibilities?
 
 
 
 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php
 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] continue working after finishing up with the http client

2009-05-27 Thread Tom Worster
On 5/27/09 10:33 AM, David Otton phpm...@jawbone.freeserve.co.uk wrote:

 2009/5/27 Tom Worster f...@thefsb.org:
 
 without getting into whether or not this cache design makes sense, my
 question in this example is: what options are there for ending the http
 transition and then continuing on to do the cache update work?
 
 You either continue processing then-and-there (exec(), or whatever) or
 you put the job in queue to be dealt with at your leisure.
 
 The queue is the better solution if you're concerned about processor
 load, as you can prioritise it. The exec() is simpler to implement.

in the absence of a tidy way to close the http connection to the client in
mid-php script, i think the queue will be my better bet. if i use mysql to
implement the queue then i'll have some convenient options for handling it. 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php