Faster than soap ?

[jeteve]

Wise monks,

I'm currently using SOAP::Lite to make calls between different component of my application.

I use SOAP::Lite under mod_perl/apache

My usefull server side function call take something like 10ms to execute. But the SOAP communication layer introduce an overhead of something like 300ms ..

SOAP is definitely great to easily expose an API to the world. But internally, I'm wondering if something as simple and more performant could exist.

My Ideal module (which I may write if it doesn't exist ..) would have those features:

• Be as easy to use as SOAP::Lite
• Be only dedicated to perl <-> perl communication
• Be a lot faster than soap, using something like Data::Dumper / eval for data marshalling/unmarshalling

Any idea ?

Thanks for your emlightments.

[derby]

REST to replace SOAP and JSON for the marshalling -- but then again are you really sure it's SOAP causing the overhead and not the network?

[mda2]

I using SOAP 3 years ago, for 2 applications, but with standalone server.
For many time I deny questions about performance, but when working at a client side and many requests, the problems is more evident. But I think the great problem is the tcp negotiate.
Some times ago I see some work around keep-alive methods on SOAP::Lite code, but don't really understand the use.
Some benchmarks are need to identify the really problem, but I think the great problem at client site are a tcp connect...
After other some needs I'm used Connection Cache(LWP::ConnCache) on LWP::UserAgent, and waiting time for find/write other SOAP::Transport Client/Daemon my use (some external clients are java ;) )
Sorry, but I only have more questions ;)
For some practical samples, see my check code for single benchmark on standalone server:
Read more... (5 kB)

[jhourcle]

I don't know exactly what you're passing , so I can't help you too much in a specific module that might suit your needs -- but my benchmarks with SOAP::Lite and the data I passed suggested the majority of the time was spent in serializing/deserializing the data.

I replaced the serializer and deserializer, so that it didn't do nearly as much inspection of the values in trying to guess what the variable types were. It's possible that a document/literal serializer might be viable, as we could remove all of the inspection on serialization, but I haven't had a chance to test it.

We're also looking at alternate formats for data encoding, as we have a whole lot of small fields, and the XML format accounts for the majority of the message (and still would, even if we switched to doc/lit).

Although REST has been mentioned -- I'm reluctant to suggest that path without knowing what you're passing. It's fine for making data available, but I'm working on search engines, and I haven't found a good way to define the search parameters in a manner that works for us. (if someone knows of good examples of REST being used for seaches w/ over a dozen independant paramters (that might change in the future), please let me know, as I'd love to see how other people are dealing with the problem).

Other things to try to speed up your access -- (note: I haven't tried either, so I don't know how much they'll help) -- try accessing the service via a WSDL, as it should change how serialization is handled. Or try specifying the type of each item using SOAP::Data objects ... it may speed up serialization at the very least.

[holcapek]

Does 100 calls of that function take (10+300)*100 ms, or something like 10*100+300 ms?

[jeteve]

(10 + 300) * 100

[Fendaria]

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.