Somthing like SOAP::Lite connected to HTTP::Daemon or Apache with some kind of tied hash would seem to be the obvious choice, but without a full description of the entire processing cycle it's kind of difficult to say "here's the definitive answer...".

rdfield

Hi,

It's really simple and not important for the question, clients send a request using a fixed protocol:

SEND:COMMAND,PARAMS
[download]

The (Perl) server returns an OK, and processes the request ASAP. Therefore, I want to accept commands as fast as possible (store them as files or in a database), and then process them (read the files or from database).

Using files the bottleneck is storing the commands in separate files, using a database the bottleneck is processing the commands (SELECTs).

Regards,
Marcel

one of the bits missing from the picture is how big is each inbound request. 200 x 10 bytes/min is a different problem to 100 * 1000 bytes/min for example.

If your inbound requests are less than 200 bytes for instance, it might make sense to not write the data into a file, but instead the request as the nameof the file itself. That way, the receiving task only need create an empty file in the queue directory, the processing task need only read the directory entries, perhaps sorting them by timestamp, to have the information it needs to proceed. Skipping the need to open the file would probably save a fair amount of time.

Another possibility is to not use permenant storage at all. Have the receiving task forward the requests directly to the processing task using sockets or even named pipes. If the volumes and delays are such that you encounter buffer overflows doing that, then the next step would be to have a third task in the chain who's job is to simply act as a buffer (and possibly logger). The receiver passes the requests to the buffer via ne socket, it stores them in memory (and optionally logs them to disc) and feeds them to the processing task on demand via a second socket or pipe. Any replies from the processing task could either go directly back to the reciever for return to the caller, or via the buffer depending on their size and costs.

So many possibilites, but much easier to make suggestions if you gave a clearer picture of the sizes and uses of the data involved.

---

Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.