Clear questions and runnable code
get the best and fastest answer
Database queueing and signalsby Marcello (Hermit)
|on Apr 07, 2004 at 07:55 UTC||Need Help??|
Marcello has asked for the wisdom of the Perl Monks concerning the following question:
Hi wise monks,
First, a short description of the perl application. At startup a server process forks of approx. 5 child processes. These persistent child processes (let's name them A, B, C, D and E) each query a MySQL database queue to see if messages are waiting. Simplified database record example:
Each child process queries the database approx. 2 times per second, processes only its own messages and deletes the record from the queue, so process A only processes the records where the Process field equals A etc.
Everything is working fine, but the database is queried a lot. Five processes means approx. 5x2 = 10 queries per second just to determine if there are any messages waiting for the process.
A more efficient solution would be to let the server process do the querying, and then inform the corresponding child process(es) that messages are waiting to be processed:
Then a child process only accesses the database when needed, preventing a lot of database selects.
Now my question: I was thinking about using signals. Each time the server process finds messages in the queue, it sends a signal to the corresponding child process. The child process set a flag upon receiving the signal:
- Has anybody used a similar approach using signals?
- Is it a good solution?
- What are the disadvantages of such a solution?
- Any other options?
Any information is highly appreciated!