axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yakulis, Ross (Ross)" <>
Subject RE: web services in C++
Date Thu, 22 May 2003 23:10:15 GMT
Peter asked my to clarify my comment.  I with draw the comment on price and leave it at that
and that for what ever reason we have chosen to use Axis until it we hit an impassable road

-----Original Message-----
From: Yakulis, Ross (Ross) 
Sent: Thursday, May 22, 2003 2:53 PM
To: ''
Subject: RE: web services in C++

Peter's comments are true based on my performance testing (I am not affiliated with any web
service vendor), however, that comes at a high $$ cost.  We looked at Systinet but opted for
Axis as Systinet was too pricey.
Is there an ongoing concerted effort to continually improve Axis performance?

-----Original Message-----
From: Peter Lacey []
Sent: Thursday, May 22, 2003 2:45 PM
Subject: Re: web services in C++

Full disclosure, I work for Systinet the makers of WASP.

In reference to Mark Volkmann's assertion that Glue and WASP do much worse than Axis when
processing large (>20K) messages.  Our own benchmarking (unbiased, I assure you) demonstrates
that for all message types, for all message sizes, and for all numbers of simultaneous clients
(threads), WASP (I can't speak for Glue) routinely outperforms Axis.  In fact, when processing
an array of structures - each structure holding an int, a double, and the String "Systinet
Benchmarks" - Axis fell over and died somewhere between 100 & 125 simultaneous connections.
 Before this, though, WASP was 250 times faster than Axis on average.  WASP was processing
roughly 43 of these 100 element arrays per second while Axis was procsessing 12.

Our benchmarks were performed on a big ol' 4-way Solaris 8 box with 32GB of RAM and using
the 1.4.1_02 JVM with the WebLogic 8.1 servlet engine.  The Axis tests were run using Doc/Literal
and Axis using RPC/Encoded.  I can't find the WASP RPC/Encoded numbers, though they are generally
superior to the Doc/Lit numbers.

Mark, Michael, I would be happy to share the results of our benchmarks with you.  My email
address should be attached to this reply, but if not I can be reached at
 If you want, I can also examine your benchmarking code and environment to help discern what
might be the reason for the results you're seeing.

To answer Michael's question.  The numbers above (good or bad) are not necessarily reflective
of message processing when dealing with attachements.  These numbers are a reflection of (among
other things) the SOAP stack's XML/Java serialization.  Regarding WASP; our Java and C++ products
support MIME attachements.  In addition the C++ product supports DIME attachements today,
and the Java product will in June.  During our tests we wanted to see what (if any) sized
attachment would cause WASP to fail.  We got up to a 165MB MIME attachment without a hiccup.
 We have not tried anything larger, but are confident WASP will continue to perform.  This
is not to say that SOAP with Attachments is the right design for you, but to say that should
you go this route WASP could undoubtedly handle the load.

I should also note that I in particular and Systinet in general hold the open source and Apache
communities in the highest regard.  The above statements are not meant to disparage the valuable
and exciting work being done here.  Please view these benchmarking results as neutral, and
this message as an attempt to set the record straight regarding WASP performance.


Volkmann, Mark wrote:

I don't have experience with that, but it's my understanding from reading the posts of others
that when you are sending large amounts of binary data, attachments are the way to go.  If
you try to stuff it in the actual SOAP message it will consume more space than putting it
in an attachment even if you don't compress it.  This has something to do with special encoding
of the data that must be done when the data is in the SOAP message.  Perhaps someone can more
clearly explain this.

-----Original Message-----
From: Allen, Michael E. []
Sent: Thursday, May 22, 2003 1:39 PM
Subject: RE: web services in C++

That's *very* interesting!  I am planning on returning some results as compressed attachments
that could be 100s of Mb large... does this imply that I would do better using SOAP for messaging
only and find another way to actually deliver the data?

-----Original Message-----
From: Volkmann, Mark []
Sent: Thursday, May 22, 2003 1:24 PM
Subject: RE: web services in C++

In my testing, message size matters a lot when it comes to performance of various web service
toolkits.  GLUE and WASP do much better than Axis for small messages, but in my testing they
do much worse than Axis for large messages.  By large I mean over 20k.

-----Original Message-----
From: Anne Thomas Manes []
Sent: Thursday, May 22, 2003 9:37 AM
Subject: Re: web services in C++

You're right -- Axis can only invoke methods on Java classes, so to use Axis, you'll need
to create Java wrappers. You'll take a hit in performance if you do this.
There are three SOAP systems for portable C++:
- Systinet WASP
- Rogue Wave LEIF
All of them support significantly better performance than Axis (or any other Java implementation).

----- Original Message ----- 
From: Allen, Michael E. <>  
Sent: Thursday, May 22, 2003 10:24 AM
Subject: web services in C++

Not exactly on the topic, but I think this group must have dealt with this issue.  What is
the best way to incorporate web services written in C++?  I have used gSoap, but I am would
like something that integrates with Axis.  I believe I am right in assuming that Axis can
only directly make calls on Java classes (is that right?).  I suppose I could right Java wrappers
for my C++ classes (are there any tools to automate that?), but I'd like to know if there
is a cleaner/more-apache like way to do things.
Btw, my need for C++ is motivated both by some performance concerns and even more by needing
to use legacy systems.

WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.

View raw message