If the work behind your SOAP process is simple (which it sounds like it is), a significant portion of your time is spent opening the connection and shoving the data back and forth with very little time actually processing. This leads to a few possibilities:

Bulk up your soap call. Instead of just doing one piece of work, send a whole list of items to do. Now your paying the connection cost once for 10x (or more) processes instead of 1x.

Threaded soap calls. Most SOAP connections and servers can't process one call quickly, but they can handle a bunch at the same time. This lets the calls overlap so you can get more done in the same time. From some rough tests, I think you can thread SOAP::Lite if your careful and test well (I wont guarentee this).

Dump SOAP and open a simple telnet/TCPIP connection to send strings to eval back and forth. Or you could use FreezeThaw or something else to encode data structures to send back and forth. You can see a big benifit in this if you are able to keep a connection open for a while and many calls instead of constantly opening new connections. This will require much more work and testing to get up and going than the SOAP route. Start with an echo server/client and build from there. Probably though, there is a better solution. Also, don't forget about security issues inherent with this method.