At 09:56 AM 11/15/2002 -0700, Rob Nagler wrote: >Stephen Adkins writes: >> QUICK AND DIRTY SINGLE-SERVER SOLUTION >> >> I implemented a quick-and-dirty single-server solution, where >> I use a single server to process requests. I simply poll the >> request table in the database once a minute for new requests, >> and if they exist, I process them. >> >> Now I am looking to upgrade this for higher throughput (multiple >> parallel servers), lower background load (no polling during quiet >> periods), and lower latency (immediate response to queue insertion >> rather than waiting for the next poll interval). > >I like this solution. Are you finding performance problems?
The server(s) connect to a mainframe and perform time-consuming, repetitive transactions to collect the data that has been requested. Thus, these servers are slow, waiting several seconds for each response, but they do not put a large load on the local processor. So I want many of them running in parallel. >One thing is to execute "process_queue" right after doing the insert. >Remember that databases are great at assuring atomicity and >persistency. > >Apache/mod_perl is the best all around application server available. Are you proposing that I use Apache/mod_perl child processes to do the transactions to the mainframe? That doesn't seem right. They are then no available to listen for HTTP requests, which is the whole purpose of an apache child process. >What's simpler than LWP::Request with an URL and a return of a Perl >(or XML if it's another language) data structure? Run eval >(or XML::Parser) and off you go. You can wrap this, but how many >message types do you have? You seem to advocate Apache/mod_perl for end-user (returning HTML) and server-to-server (RPC) use. That makes sense. But it doesn't seem to make sense for my family of servers that spend all of their time waiting for the mainframe to return their next transaction. Stephen
