Jump to content

Persisting an object over multiple requests


NotionCommotion

Recommended Posts

I have an object which is very expensive to create, and is fairly large but by no means enormous.  The object has two tasks:

  1. Display to the user what can be changed in a database.
  2. Make some or all of those changes based on user input.

Instead of creating it first to perform the first task, I would like to serialize it and store it somewhere and then restore it to perform the second task to reduce user wait time.  Communication of both tasks is as follows where the web client first makes a XMLHttpRequest and then cURL is used for the remaining:

Web Client -> Web Server -> REST API Server -> Time Historian Application (and then back in the same order)

In addition, both of these tasks take significantly longer than 30 seconds resulting in cURL error 28.  I certainly can investigate to determine which of the requests are causing this error, however, feel that the solution to persisting the object might solve this issue as well.

I am thinking of making the REST API server responsible for temporarily storing the object, and am considering the following:

  1. Web client makes XMLHttpRequest to web server and passes session cookie.
  2. Web server makes cURL request to REST API server and passes that same cookie (maybe a bad idea?).
  3. REST API server initiates the time historian application, spawns some new process, and replies to the web server maybe with some expected wait time duration, and web server in turn responds to web client.
  4. Spanned process when object is complete serializes the object's content and saves it as JSON using the session cookie as the filename.
  5. Web client periodically makes requests to web server which in turn make requests to REST API server and when the JSON file is available, recreates the object, executes the applicable method, and replies with the applicable content.
  6. Web client sends user data to the web server and in turn to the REST server to initiate the second task.
  7. Web client similarly periodically makes requests to web server which in turn make requests to REST API server to check if complete and if so the JSON object file is deleted.
  8. If request has not been fulfilled within 24 hours or so, JSON object file is deleted.

I would appreciate any general feedback or recommendations how best to accomplish this, and whether using some 3rd party framework such as Gearman, ReactPHP, redis, etc might simplify matters.

Thank you

Link to comment
Share on other sites

3 hours ago, NotionCommotion said:

4. Spanned process when object is complete serializes the object's content and saves it as JSON using the session cookie as the filename.

You're reinventing caching.

Set yourself up a redis or memcached server and store stuff in there.

Link to comment
Share on other sites

7 hours ago, requinix said:

You're reinventing caching.

Set yourself up a redis or memcached server and store stuff in there.

Okay, I see how a redis or memcached server can be used instead of saving content in a DB or flat file.  Appears that for new projects, redis is likely preferred.

There was much content available describing how to set it up and storing strings, etc in it, but not much regarding persisting an PHP object with methods.  Appears that I will likely want to create a second class which will be injected with the serialized JSON object and implements a common interface to the original creator, true?

Any thoughts on how to best spawn a new process. Is http://gearman.org/ worth considering for the forking of a PHP process, or maybe some other application is more relevant?  Or maybe just run it in the background and have it write to redis/memcached when complete?

Looks like both redis and memcached require some unique key to identify the content.  Any concerns with using the web client's session cookie string?

Does my client polling strategy make sense to determine whether the object is available make sense?

Thanks!

Link to comment
Share on other sites

4 minutes ago, NotionCommotion said:

There was much content available describing how to set it up and storing strings, etc in it, but not much regarding persisting an PHP object with methods.  Appears that I will likely want to create a second class which will be injected with the serialized JSON object and implements a common interface to the original creator, true?

Methods are code so there's nothing to persist there.

Data can be serialized. Do try to serialize the data and not the object though - more portable and less dependent on your PHP.

 

4 minutes ago, NotionCommotion said:

Any thoughts on how to best spawn a new process. Is http://gearman.org/ worth considering for the forking of a PHP process, or maybe some other application is more relevant?  Or maybe just run it in the background and have it write to redis/memcached when complete?

Depends on the nature of the process. I don't have the answers to this one.

 

4 minutes ago, NotionCommotion said:

Looks like both redis and memcached require some unique key to identify the content.  Any concerns with using the web client's session cookie string?

All sorts of concerns, yeah. Such as the fact that you only have the one cookie so that means you get only the one key.

The key should be enough information to uniquely identify the data. Same key means the same data, though the same data could hypothetically exist under multiple keys.
If you wanted to cache the result of finding the 100th Fibonacci number then "fibonacci_100" would be a good cache key.

 

4 minutes ago, NotionCommotion said:

Does my client polling strategy make sense to determine whether the object is available make sense?

If you have to. Polling as a whole sucks. If it takes code to make the object available then that same code should be able to (somehow) notify a client. If there's no way to notify a client then give them expected/retry time periods (eg, "not available yet, try again at X time") based on some reasonably intelligent estimates.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.