Re: [PHP] continue working after finishing up with the http client
On 5/27/09 10:33 AM, "David Otton" wrote: > 2009/5/27 Tom Worster : > >> 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
Re: [PHP] continue working after finishing up with the http client
On 5/27/09 12:35 PM, "bruce" 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" 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
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" 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/5/27 Tom Worster : > 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
On 5/27/09 9:50 AM, "bruce" 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
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
