in reply to Mojo: non-blocking API calls
If feasible, please try to show some of the relevant code snips you have now, perhaps with comments in the areas you feel that could use some performance gains.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^2: Mojo: non-blocking API calls
by Beatnik (Parson) on Nov 27, 2016 at 22:35 UTC | |
Greetz Beatnik ... I'm belgian but I don't play one on TV. | [reply] |
by stevieb (Canon) on Nov 27, 2016 at 22:54 UTC | |
"I'll need to do some more reading on this, I guess" Quite probable. From what you're describing, it's a shot in the dark unless one of the monks has experience in exactly what you're dealing with. After reading more, and with some testing, you should be able to provide code snips that show the issue in action. I can think of a few things off the bat, but I'm afraid they'll be irrelevant and slant this thread sideways for no reason. For instance... in one of my apps recently using Dancer2, I had to sway from their db plugin so that I could run my db inserts/updates inside of an event outside the main application, so that there was no holdup. That won't work in all cases though, so keep us apprised on what you find when you can get a bit more specific. | [reply] |
Re^2: Mojo: non-blocking API calls
by Beatnik (Parson) on Nov 28, 2016 at 12:21 UTC | |
I don't need to call the API at that specific time. My original approach was to flag the record in my local database as 'created' or 'modified' and run a background process to make sure the local database synchronizes all flagged records with the application using the API. The list method would then only read from the database and make adjustments in the database. Greetz Beatnik ... I'm belgian but I don't play one on TV. | [reply] [d/l] |
by stevieb (Canon) on Nov 28, 2016 at 15:15 UTC | |
Perhaps something as simple as forking is all you need. Here's an example that kind of simulates what I think you're trying to do. Essentially, we create an API object with a couple of methods. Instead of calling them directly, we pass the object and the sub we want to call on it to a forking routine from within a local sub (save(), users()), and then let it work in the background while the main script carries on. At the end of the script, we wait until all forked processes have completed before we exit.
Output:
| [reply] [d/l] [select] |