SOAP/TCP makes Web services faster

Last month two important events happened related to SOAP/TCP.
First of all, as part of project Metro, SOAP/TCP 1.0 implementation is now available in Glassfish v2 release.

Next great thing is: SOAP/TCP now is .NET interoperable!!! Read more on Paul's blog.

Now I wanted to stop on topic, what advantages SOAP/TCP brings to Web services.

We always mentioned, that main target for SOAP/TCP is performance, however never showed any numbers. Here I would like to publish some benchmark results, which I've got using Japex.

Testing environment configuration:

  • localhost
  • Sun X4100 server, 4 CPUs
  • Sun Solaris 10
  • Sun JDK 1.5.0_13
  • Glassfish v2 release
  • 16 client threads

Web Service test operations: 

Most of tests are echo-like (except getOrder), it means the same data set (depending on test) is sent to and returned from a Web service. For example echoInt test executes Web service operation, which implements following logic:

public int echoInt(int value) {
    return value;

Here is complete description of tests (provided by Ken Cavanaugh):

  • EchoVoid: no data sent or returned
  • EchoString: "Hello World" sent and returned
  • EchoStruct: a small class with an int, a float, and a String sent and returned
  • EchoSynthetic: a small class with a String, a Struct (as in EchoStruct), and a variable-length byte[] sent and returned.  The size of the byte array is indicated by the name of the test.
  • EchoArray: basically an ArrayList of an Item, with each Item initialized to the same data (so Strings are shared in the marshaled representation).  The number of Items is given in the name of the test.  An Item contains:
    • String
    • String
    • float
    • int
    • Location, which is 3 Strings
    • XMLGregorianCalendar (standard Java type; the BigInt or BigDecimal fields are null)
  • GetOrder send a very small request (customer ID and order number), and returns a large Order class containing:
    • int
    • int
    • XMLGregorianCalendar
    • Customer, which is a class containing:
      • int
      • String
      • String
      • String
      • XMLGregorianCalendar
      • String
      • String
      • Address (which contains 7 Strings)
      • Address
    • ArrayOfLineItem which contains an ArrayList of LineItem, each of which contains:
      • int
      • int
      • int
      • String
      • int
      • float 

Test results are measured in "transactions per second %". SOAP/TCP benchmark result is taken as 100%. Red bar represents SOAP/TCP results, blue bar is FastInfoset encoded SOAP over HTTP, and green bar is regular SOAP/HTTP.

Let's start from results for smaller testcases.

benchmark results (small testcases)


We can see, that for small testcases, where HTTP headers could be even bigger than SOAP message - SOAP/TCP header compactness plays very big role. And we can get over 50% performance improvement with SOAP/TCP comparing to FastInfoset over HTTP, and over 70% comparing to SOAP/HTTP.

Medium testcases:

benchmark results (medium testcases)

Here we can see that for echoStruct and echoArray40 SOAP/TCP is getting less advantage comparing to FastInfoset/HTTP, because SOAP messages are getting bigger and header processing gets relatively cheaper. Though for bigger messages, SOAP/TCP stateful characteristic (FastInfoset stateful mode) does its work (in SOAP/TCP, FastInfoset vocabulary is not transferred with each message, but is kept alive both on client and server until SOAP/TCP connection is alive).

On echoSynthetic testcases we can see SOAP/TCP throughput advantages. With changing transferring byte buffer size from 4K to 12K - difference between SOAP/TCP and HTTP results grows.

Big testcases:

benchmark results (big testcases)

On bigger tests, when transferring complex structures, SOAP/TCP also wins regarding its stateful FastInfoset vocabulary and better throughput. Though, its advantage is not so huge as for smaller messages, 15% performance improvement is also significant.

So, from graphs above we can see, that SOAP/TCP makes Web services faster: over 50% for smaller structures, 15% for bigger ones.


Can you share your code?

Posted by guest on October 23, 2007 at 12:52 PM CEST #

Does SOAP/TCP allow multiplexing many transactions on the same connection? Do the benchmarks of SOAP over HTTP use persistent connections? Do your benchmarks measure only overhead?

Posted by Nico on October 23, 2007 at 03:33 PM CEST #

> Can you share your code?
Unfortunately not :(
But I think test structures are described clear.

> Does SOAP/TCP allow multiplexing many transactions on the same connection?
Not, SOAP/TCP realizes simple request/response pattern. And if connection is occupied with one WS operation execution, at the same time it could not be reused by another operation.

> Do the benchmarks of SOAP over HTTP use persistent connections?

> Do your benchmarks measure only overhead?
Which numbers are you interested in?

Posted by oleksiys on October 24, 2007 at 10:08 AM CEST #

I created a basic web service using NetBeans 6 (beta2) and enabling Soap/Tcp and fast infoset did not improve performance whatsoever.
Is there any hack/trick?
It would be nice to have some sample NetBeans projects to see how it should be done.

Posted by Bijan on October 24, 2007 at 12:03 PM CEST #

Also it would be nice to compare the performance with Java RMI.

Posted by Bijan on October 24, 2007 at 01:13 PM CEST #

> I created a basic web service using NetBeans 6 (beta2) and enabling Soap/Tcp and fast infoset did not improve performance whatsoever.
>Is there any hack/trick?

There are no tricks. Though benefits really depend on testcase you're using. There are some usecases, where FastInfoset stateful mode (which SOAP/TCP uses) is working worse than stateless one. For example situation, where WS operation deals with big amount of distinct, short String values. In this case FastInfoset stateful vocabulary will get overloaded with actually not-required information, and never will be cleared. In this case it's better to use the stateless mode. But thinkб most of the usecases benefit, when using stateful.

> It would be nice to have some sample NetBeans projects to see how it should be done.

It should be really easy to do with NetBeans. Just 2 checkboxes: one for server side, one for client :)

Posted by oleksiys on October 26, 2007 at 04:52 AM CEST #

I have created a ws to test infoset and soap.tcp transport to compare the improvement on performance.
I enabled both(on client and server) by the wsit plugin on netbeans.
But unfortunately no improvement was obtained.

Could it be that the encoding and transport continue being the same on both case? Because the option says ("select optimal...").

How could i know which transport and encoding are using the client to connect with the ws.

The code could be something like:
calc.CalcService service = new calc.CalcService();
calc.Calc calcPort = service.getCalcPort();
while( ( (Calendar.getInstance().getTimeInMillis() - beforeMillis)/1000 ) < numberSeconds )
println("N°transactions:"+i );
Many thanks.

Posted by Jose on January 13, 2008 at 10:24 AM CET #

If you want to enable just FastInfoset you need to choose just "Select Optimal Encoding" (currently it's FastInfoset). If you want to enable SOAP/TCP - please select "Select Optimal Transport".

From code it's not possible to see which Transport or Encoding is used. WSIT makes this automatically. If "optimized transport" was chosen - it will try SOAP/TCP (it's supposed currently as optimized transport)... FastInfoset will be silently chosen as optimal encoding.

Posted by oleksiys on January 15, 2008 at 06:35 AM CET #

How does SOAP/TCP compare to gSOAP? I am curious cause last time I checked gSOAP was much faster compared to Apache Axis.

Posted by Behrang on October 12, 2008 at 12:53 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed



« June 2016