4

I am putting together an interface for our employees to upload a list of products for which they need industry stat's (currently doing 'em manually one at a time).
Each product will then be served up to our stat's engine via a webservice api.
I will be replying. The Stat's-engine will be requesting the "next victim" from my api.

Each list the users upload will have between 50 and 1000 products, and will be its own queue.
For now, Queues/Lists will likely be added (& removed via completion) aprox 10-20 times per day.
If successful, traffic will probably rev up after a few months to something like 700-900 lists per day.

We're just planning to go with a simple round-robin approach to direct the traffic evenly across queues.
The multiplexer would grab the top item off of List A, then List B, then List C and so on until looping back around to List A again ... keeping in mind that lists/queues can be added/removed at any time.

The issue I'm facing is just conceptualizing the management of this.
I thought about storing each queue as a flat file and managing the rotation via relational DB (MySQL). Thought about doing it the reverse. Thought about going either completely flat-file or completely relational DB ... bottom line, I'm flexible.
Regardless, my brain is just vapor locking when I try to statelessly meld a variable list of participants with a circular rotation (I just got back from a quick holiday, and I don't think my brain's made it home yet ;)

Has anyone done something like this?
How did you handle it?
What would you improve if you had to do it again?

Any & all tips/suggestions/advice are welcome.

NOTE: Since each request from our stat's engine/tool will be separated by many seconds, if not a couple minutes, I need to keep this stateless.

mOrloff
  • 2,547
  • 4
  • 29
  • 48
  • Add'l info: **1)** When the final item from a specific queue/list is issued to the stat's engine, our notifier will be triggered notifying the user that they can view their results (no status checking needed .. yay!!). **2)** The Stat's engine takes a single product, runs the stat's and loads them into our cache pool. – mOrloff Jul 24 '12 at 23:52

3 Answers3

1

List data should be stored in a database, for sure. Your PHP side should have a view giving the status of the system, and the form to add lists.

Since each request becomes its own queue, and all the request-queues are considered equal in priority, the ideal number of tables is probably three. One to list requests and their priority relative to another (to determine who goes next in the round-robin) and processing status, another to list the contents (list-items) of each request that are yet to be processed, and a third table to list the processed items from each queue.

You will also need a script that does the actual processing, that is not driven by a user request, but instead by a system-scheduled job that executes periodically (throttled to whatever you desire). This can of course also be in PHP. This is where you would set up your 10-at-a-time list checks and updates.

The processing would be something like:

  1. Select the next set of at most 10 items from the highest-priority queue.
  2. Process them, Updating their DB status as they complete.
  3. Update the priority of the above queue so that it is now the lowest priority.

And if new queues are added, they would be added with lowest priority.

Priority could be represented with an integer.

Your users would need to wait patiently for their list to be processed and then view or download the result. You might setup an auto-refresh script for this on your view page.

T.W.R. Cole
  • 4,106
  • 1
  • 19
  • 26
  • Thx a bunch .. many of the components R done already. The hurdle I'm facing is simply the prioritizing of the next item (has 2 B 1 at a time, unfortunately). As I understand your suggestion (as it applies to my boundaries), the idea is simply have a tbl for priorities .. I like it .. nice and simple :). My main concern is updating the priority value for **ALL** records in that table **EACH** time a record is processed. If I have to do that for something like 900 records each time, wouldn't that be an unnecessary burden on resources?? – mOrloff Jul 24 '12 at 23:28
  • To clarify, using this Priorities Tbl approach, I would be prioritizing the Queues/Lists .. then once my multiplexer knows which list to hit next, it would retrieve the next item from that list/queue. – mOrloff Jul 24 '12 at 23:42
  • I think it would work equally well to select the MIN() priority, then update the highest-priority row with MIN() - 1 – T.W.R. Cole Jul 25 '12 at 20:08
0

It sounds like you're trying to implement something that Gearman already does very well. For each upload / request, you can simply send off a job to the Gearman server to be queued.

Gearman can be configured to be persistent (just in case things go to hell), which should eliminate the need for you logging requests in a relational database.

Then, you can start as many workers as you'd like. I know you suggest running all jobs serially, which you can still do, but you can also parallelize the work, so that your user isn't sitting around quite as long as they would've been if all jobs had been processed in a serial fashion.

Chris Henry
  • 11,914
  • 3
  • 30
  • 31
0

After a good nights sleep, I now have my wits about me (I hope :).
A simple solution is a flat file for the priorities.
Have a text file simply with one List/Queue ID on each line.
Feed from one end of the list, and add to the other ... simple.

Criticisms are welcome ;o)

Thanks @Trylobot and @Chris_Henry for the feedback.

mOrloff
  • 2,547
  • 4
  • 29
  • 48