You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Chuck Musser <ch...@well.com> on 2003/02/01 06:25:31 UTC
standalone vs. servlet
I'm evaluating SOAP servers with an eye toward performance and ease of
deployment. My instinct is to prefer a native SOAP implementation over a
Java implementation and to prefer a standalone implementation over one
that lives inside a servlet container. But I'm new to this stuff, so I
really don't know. I do realize that Java has lots of built in
networking and database connectivity that native implementations don't
have. Has anyone evaluated these issues:
1.) Are there advantages to deploying Axis inside a servlet container
rather than using the standalone server?
2.) How does the performance compare for servlet vs. standalone?
3.) How does the throughput of Axis compare to a "native"
implementation, like gSOAP.
4.) What sort of testing tools are available for evaluating the
throughput of various SOAP servers.
Thanks,
Chuck
Re: standalone vs. servlet
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Dennis Sosnoski" <dm...@sosnoski.com>
To: <ax...@xml.apache.org>
Sent: Monday, February 03, 2003 10:44
Subject: Re: standalone vs. servlet
> Just in passing, one particular area that I suspect causes performance
> problems is the SAX event stream buffering that gets done for multiRefs
> in RPC encoded messages. This is an intriguing approach - if you need a
> reference to an object that's not defined yet, just skip ahead in the
> event stream to get the object definition, then continue on from where
> you are now. I suspect it'd be considerably faster (and simpler) to just
> create an object to track the forward reference, then fill it in when
> the reference is defined. This may be another area where the behavior is
> requried by JAX-RPC, though.
yes, if you can hack that with a placeholder, life is simpler.
...maybe we should all move to JAX-M with WSDL support added on, or at least
turn multiref encoding off altogether.
Re: standalone vs. servlet
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Steve Loughran wrote:
>>I suspect that the use of reflection has a lot to do with the issue. Java
>>platforms use reflection to enable a bunch of dynamic features which are
>>really hard to reproduce in a C++ environment. You'll find this to be true
>>in SOAP platforms, servlet engines, and J2EE servers.
>>
>I think Axis only reflects in the java invocation phase, and in
>serialisation/deserialisation of stuff. I bet the latter aspect of
>marshalling is the slowest bit of the process...and wonder how hard it would
>be to autogen the code to do the binding.
>
I suspect reflection doesn't really have much impact in the Axis
framework. When I looked into some of the performance issues back in
December (mainly with respect to large messages) I didn't find any one
aspect that was causing a big performance hit (aside from a bug in the
namespace handling, which now has a workaround in place). A lot of the
internal Axis structure is constrained by JAX-RPC compatibility, and
that makes it really difficult to implement big performance
improvements. For instance, JAX-RPC is based on SAX parsing which is
pretty horrible for structured data - you have to maintain state in your
handlers, and figure out what to do with each document component that
gets delivered to you. A pull parser approach would be *much* more
efficient for SOAP - but would be incompatible with JAX-RPC. Alek
Slominski was working in this area before he got into the WSIF stuff,
don't know what's going on with it now:
http://www.extreme.indiana.edu/xgws/xsoap/ (and the paper at
http://www.extreme.indiana.edu/xgws/papers/sc00_paper/index.html).
There *does* seem to be a lot of memory churn going on with Axis.
Running the client with -verbose:gc I saw a total of about 18MB garbage
on the client side for round-tripping a 320KB message - you can see full
details in the archive at
http://marc.theaimsgroup.com/?l=axis-user&m=103825449231468&w=2.
Reducing unnecessary object creation would certainly help performance.
Just in passing, one particular area that I suspect causes performance
problems is the SAX event stream buffering that gets done for multiRefs
in RPC encoded messages. This is an intriguing approach - if you need a
reference to an object that's not defined yet, just skip ahead in the
event stream to get the object definition, then continue on from where
you are now. I suspect it'd be considerably faster (and simpler) to just
create an object to track the forward reference, then fill it in when
the reference is defined. This may be another area where the behavior is
requried by JAX-RPC, though.
- Dennis
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services Support
http://www.sosnoski.com
Redmond, WA 425.885.7197
Re: standalone vs. servlet
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Anne Thomas Manes" <an...@manes.net>
To: <ax...@xml.apache.org>
Sent: Sunday, February 02, 2003 14:13
Subject: RE: standalone vs. servlet
> I suspect that the use of reflection has a lot to do with the issue. Java
> platforms use reflection to enable a bunch of dynamic features which are
> really hard to reproduce in a C++ environment. You'll find this to be true
> in SOAP platforms, servlet engines, and J2EE servers. It's a trade-off
> between function and performance, and in most circumstances , function
wins.
I think Axis only reflects in the java invocation phase, and in
serialisation/deserialisation of stuff. I bet the latter aspect of
marshalling is the slowest bit of the process...and wonder how hard it would
be to autogen the code to do the binding.
> From what I've seen, the two top performing Java SOAP platforms are WASP
and
> GLUE. BEA and XMLbus are close behind. All of these systems offer
> performance comparable to or better than .NET. I'd say that all of these
> implementations have been very well designed and optimized. But none of
them
> can touch the performance of gSOAP, LEIF, or WASP for C++. I'm not sure
how
> to explain it other than to blame the platform. (Perhaps it's something
> inherent to XML processing? There are some functions in which C++ really
> excels over Java -- maybe XML processing is one of them.)
That'd be a really interesting research paper that would, too bad I dont
have the time. Nb, remember, you arent allowed to discuss .net performance
or disclose benchmark details :(
Re: standalone vs. servlet
Posted by Chuck Musser <ch...@well.com>.
You both bring interesting points to light. I certainly get Anne's
"machine efficiency vs. programmer efficiency" argument. I've managed
to got lots done in Perl, Tcl and Javascript, so I'm biased against
on-the-metal system programming languages. Java seems wonderfully
expressive, but my concern was that its emphasis on being a nice
language somehow resulted in unusably slow applications. I'm encouraged
by Dennis's comment that slow Java applications are, more often than
not, the programmer's own damn fault. I also understand that distributed
systems have many potential bottlenecks. As an example, my proposed
application uses Mozilla as the front end, so any perceived sluggishness
may be the result of rendering lag, not SOAP message processing lag.
For the moment I'm going to fiddle with Axis and Jakarta-Tomcat (and
let's not forget Apache) and see I come up with. Thanks for the insight.
Chuck
Anne Thomas Manes wrote:
>I suspect that the use of reflection has a lot to do with the issue. Java
>platforms use reflection to enable a bunch of dynamic features which are
>really hard to reproduce in a C++ environment. You'll find this to be true
>in SOAP platforms, servlet engines, and J2EE servers. It's a trade-off
>between function and performance, and in most circumstances , function wins.
>
>As for "my" platforms -- please recognize that I'm not with Systinet any
>longer. I illustrated my point using WASP because Systinet is the only
>vendor that provides Java and C++ implementations.
>
>>>From what I've seen, the two top performing Java SOAP platforms are WASP and
>GLUE. BEA and XMLbus are close behind. All of these systems offer
>performance comparable to or better than .NET. I'd say that all of these
>implementations have been very well designed and optimized. But none of them
>can touch the performance of gSOAP, LEIF, or WASP for C++. I'm not sure how
>to explain it other than to blame the platform. (Perhaps it's something
>inherent to XML processing? There are some functions in which C++ really
>excels over Java -- maybe XML processing is one of them.)
>
>I don't want to sound as if I'm recommending C++ over Java. I'm just stating
>a fact that among all current SOAP implementations, C++ implementations
>offer better raw performance than Java implementations. I place a caveat on
>that statement by stating that it's easier to achieve massive scalability
>with Java by using a high-end Java application server. (You can certainly
>achieve comparable scalability with C++, but you need to build the resouce
>sharing and cluster facilities into your application -- which definitely
>isn't easy.)
>
>As far as I'm concerned, it's a pretty rare situation where performance
>requirements outweigh those for productivity and maintenance. You can almost
>always make up for performance by throwing more iron at the problem. You
>can't make up for schedule delays caused by some nasty memory leak that no
>one can find. From my perspective, Java is always my first choice for
>language. Go with Java unless you have a compelling reason not to (e.g.,
>your processing/memory capacity is fixed).
>
>- Anne
>
>
>
>>-----Original Message-----
>>From: Dennis Sosnoski [mailto:dms@sosnoski.com]
>>Sent: Sunday, February 02, 2003 3:12 PM
>>To: axis-user@xml.apache.org
>>Subject: Re: standalone vs. servlet
>>
>>
>>I think this is an artificial distinction, Anne. I'd suspect the
>>difference in performance of your SOAP platforms is due more to how
>>they're structured internally rather than to any inherent differences in
>>C++ vs Java. For instance, Java SOAP implementations commonly use
>>reflection to access data in objects, which is always slower than direct
>>access (even with the improvements that have been made in recent JVMs).
>>With C++ this is not an option. That said, there are also other issues
>>that may play into this particular application, such as the better
>>socket handling allowed by C++.
>>
>>I don't know about the Tuxedo vs app server comparison, though my
>>understanding is that Tuxedo handles only one particular portion of the
>>work that's done by an app server and hence can be heavily optimized for
>>that one purpose. Servlet/JSP engines such as Resin have certainly shown
>>much superior performance vs IIS/ASP in the past, even though IIS/ASP
>>was an "integrated" component of the OS. I haven't seen the latest
>>figures now that MS as adopted a JSP-style compiled code approach for
>>ASPs, so it's possible the advantage has swung back the other way again.
>>The point is that implementation and internal design (not just tuning,
>>which is a last minute attempt to clean up some of the worst excesses of
>>poorly performing code) matter more than the choice of language.
>>
>> - Dennis
>>
>>Anne Thomas Manes wrote:
>>
>>
>>
>>>Dennis,
>>>
>>>I absolutely agree with you regarding application code. Using
>>>
>>>
>>well-optimized
>>
>>
>>>code and a good application server, you ought to be able to make a Java
>>>application run at a speed that's reasonably comparable to a C++
>>>application. There's a bigger difference, though, when it comes to
>>>infrastructure code. In my experience, SOAP *platforms* built
>>>
>>>
>>with C++ run a
>>
>>
>>>lot faster than those built with Java. Just as you won't find a J2EE app
>>>server that can compare with Tuxedo.
>>>
>>>Best regards,
>>>Anne
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Dennis Sosnoski [mailto:dms@sosnoski.com]
>>>>Sent: Sunday, February 02, 2003 2:18 PM
>>>>To: axis-user@xml.apache.org
>>>>Subject: Re: standalone vs. servlet
>>>>
>>>>
>>>>Anne Thomas Manes wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>There's no doubt that a C++ environment will offer higher
>>>>>
>>>>>
>>>>>
>>>>>
>>>>performance than a
>>>>
>>>>
>>>>
>>>>
>>>>>Java environment. Ask Systinet. WASP for C++ is a *lot* faster
>>>>>
>>>>>
>>>>>
>>>>>
>>>>than WASP for
>>>>
>>>>
>>>>
>>>>
>>>>>Java. The two environments use basically the same
>>>>>
>>>>>
>>architecture, but C is
>>
>>
>>>>>just faster than Java. Even so I suspect that it would be
>>>>>
>>>>>
>>easier to make
>>
>>
>>>>>WASP for Java support massive scalability than WASP for C++. All
>>>>>
>>>>>
>>>>>
>>>>>
>>>>you have to
>>>>
>>>>
>>>>
>>>>
>>>>>do is deploy it in WebLogic. There isn't an app server comparable to
>>>>>WebLogic for the C++ world. (well -- there's Tuxedo -- but I
>>>>>
>>>>>
>>>>>
>>>>>
>>>>don't know of
>>>>
>>>>
>>>>
>>>>
>>>>>anyone who's developed a SOAP platform for Tuxedo yet). But
>>>>>
>>>>>
>>>>>
>>>>>
>>>>since C++ is so
>>>>
>>>>
>>>>
>>>>
>>>>>much faster than Java, the threshold at which you need a really
>>>>>
>>>>>
>>>>>
>>>>>
>>>>high-end app
>>>>
>>>>
>>>>
>>>>
>>>>>server is quite a bit higher.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>There's no reason for massive speed differences between C++ and Java
>>>>aside from developers not knowing what they're doing. Well designed Java
>>>>code should be no more than a maximum of about 30-40% slower than
>>>>equally well designed C++ code (after loading and initial JVM
>>>>optimization). If you're getting worse results than that it's due to
>>>>your developers, not to the language/platform.
>>>>
>>>>I've personally replaced C++ subsystems with Java subsystems that did
>>>>more work and did it several times faster, while being more maintainable
>>>>than the C++ code had been. I've also improved the performance of one
>>>>enterprise Java system by a factor of more than 100 in a few weeks work
>>>>(most of which was spent convincing the technical management of my
>>>>reasons, through a detailed timing analysis).
>>>>
>>>>There does seem to be a tendency for Java developers to write horrible
>>>>inefficient code. This may be a side effect of Java features - with
>>>>garbage collection behind the scenes, and threads so easy to create,
>>>>it's very easy to ignore the performance implications of what you're
>>>>doing. Don't blame the platform, though.
>>>>
>>>> - Dennis
>>>>
>>>>Dennis M. Sosnoski
>>>>Enterprise Java, XML, and Web Services Support
>>>>http://www.sosnoski.com
>>>>Redmond, WA 425.885.7197
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
>
>
>
RE: standalone vs. servlet
Posted by Anne Thomas Manes <an...@manes.net>.
I suspect that the use of reflection has a lot to do with the issue. Java
platforms use reflection to enable a bunch of dynamic features which are
really hard to reproduce in a C++ environment. You'll find this to be true
in SOAP platforms, servlet engines, and J2EE servers. It's a trade-off
between function and performance, and in most circumstances , function wins.
As for "my" platforms -- please recognize that I'm not with Systinet any
longer. I illustrated my point using WASP because Systinet is the only
vendor that provides Java and C++ implementations.
>From what I've seen, the two top performing Java SOAP platforms are WASP and
GLUE. BEA and XMLbus are close behind. All of these systems offer
performance comparable to or better than .NET. I'd say that all of these
implementations have been very well designed and optimized. But none of them
can touch the performance of gSOAP, LEIF, or WASP for C++. I'm not sure how
to explain it other than to blame the platform. (Perhaps it's something
inherent to XML processing? There are some functions in which C++ really
excels over Java -- maybe XML processing is one of them.)
I don't want to sound as if I'm recommending C++ over Java. I'm just stating
a fact that among all current SOAP implementations, C++ implementations
offer better raw performance than Java implementations. I place a caveat on
that statement by stating that it's easier to achieve massive scalability
with Java by using a high-end Java application server. (You can certainly
achieve comparable scalability with C++, but you need to build the resouce
sharing and cluster facilities into your application -- which definitely
isn't easy.)
As far as I'm concerned, it's a pretty rare situation where performance
requirements outweigh those for productivity and maintenance. You can almost
always make up for performance by throwing more iron at the problem. You
can't make up for schedule delays caused by some nasty memory leak that no
one can find. From my perspective, Java is always my first choice for
language. Go with Java unless you have a compelling reason not to (e.g.,
your processing/memory capacity is fixed).
- Anne
> -----Original Message-----
> From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> Sent: Sunday, February 02, 2003 3:12 PM
> To: axis-user@xml.apache.org
> Subject: Re: standalone vs. servlet
>
>
> I think this is an artificial distinction, Anne. I'd suspect the
> difference in performance of your SOAP platforms is due more to how
> they're structured internally rather than to any inherent differences in
> C++ vs Java. For instance, Java SOAP implementations commonly use
> reflection to access data in objects, which is always slower than direct
> access (even with the improvements that have been made in recent JVMs).
> With C++ this is not an option. That said, there are also other issues
> that may play into this particular application, such as the better
> socket handling allowed by C++.
>
> I don't know about the Tuxedo vs app server comparison, though my
> understanding is that Tuxedo handles only one particular portion of the
> work that's done by an app server and hence can be heavily optimized for
> that one purpose. Servlet/JSP engines such as Resin have certainly shown
> much superior performance vs IIS/ASP in the past, even though IIS/ASP
> was an "integrated" component of the OS. I haven't seen the latest
> figures now that MS as adopted a JSP-style compiled code approach for
> ASPs, so it's possible the advantage has swung back the other way again.
> The point is that implementation and internal design (not just tuning,
> which is a last minute attempt to clean up some of the worst excesses of
> poorly performing code) matter more than the choice of language.
>
> - Dennis
>
> Anne Thomas Manes wrote:
>
> >Dennis,
> >
> >I absolutely agree with you regarding application code. Using
> well-optimized
> >code and a good application server, you ought to be able to make a Java
> >application run at a speed that's reasonably comparable to a C++
> >application. There's a bigger difference, though, when it comes to
> >infrastructure code. In my experience, SOAP *platforms* built
> with C++ run a
> >lot faster than those built with Java. Just as you won't find a J2EE app
> >server that can compare with Tuxedo.
> >
> >Best regards,
> >Anne
> >
> >
> >
> >>-----Original Message-----
> >>From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> >>Sent: Sunday, February 02, 2003 2:18 PM
> >>To: axis-user@xml.apache.org
> >>Subject: Re: standalone vs. servlet
> >>
> >>
> >>Anne Thomas Manes wrote:
> >>
> >>
> >>
> >>>There's no doubt that a C++ environment will offer higher
> >>>
> >>>
> >>performance than a
> >>
> >>
> >>>Java environment. Ask Systinet. WASP for C++ is a *lot* faster
> >>>
> >>>
> >>than WASP for
> >>
> >>
> >>>Java. The two environments use basically the same
> architecture, but C is
> >>>just faster than Java. Even so I suspect that it would be
> easier to make
> >>>WASP for Java support massive scalability than WASP for C++. All
> >>>
> >>>
> >>you have to
> >>
> >>
> >>>do is deploy it in WebLogic. There isn't an app server comparable to
> >>>WebLogic for the C++ world. (well -- there's Tuxedo -- but I
> >>>
> >>>
> >>don't know of
> >>
> >>
> >>>anyone who's developed a SOAP platform for Tuxedo yet). But
> >>>
> >>>
> >>since C++ is so
> >>
> >>
> >>>much faster than Java, the threshold at which you need a really
> >>>
> >>>
> >>high-end app
> >>
> >>
> >>>server is quite a bit higher.
> >>>
> >>>
> >>>
> >>There's no reason for massive speed differences between C++ and Java
> >>aside from developers not knowing what they're doing. Well designed Java
> >>code should be no more than a maximum of about 30-40% slower than
> >>equally well designed C++ code (after loading and initial JVM
> >>optimization). If you're getting worse results than that it's due to
> >>your developers, not to the language/platform.
> >>
> >>I've personally replaced C++ subsystems with Java subsystems that did
> >>more work and did it several times faster, while being more maintainable
> >>than the C++ code had been. I've also improved the performance of one
> >>enterprise Java system by a factor of more than 100 in a few weeks work
> >>(most of which was spent convincing the technical management of my
> >>reasons, through a detailed timing analysis).
> >>
> >>There does seem to be a tendency for Java developers to write horrible
> >>inefficient code. This may be a side effect of Java features - with
> >>garbage collection behind the scenes, and threads so easy to create,
> >>it's very easy to ignore the performance implications of what you're
> >>doing. Don't blame the platform, though.
> >>
> >> - Dennis
> >>
> >>Dennis M. Sosnoski
> >>Enterprise Java, XML, and Web Services Support
> >>http://www.sosnoski.com
> >>Redmond, WA 425.885.7197
> >>
> >>
> >>
> >
> >
> >
>
Re: standalone vs. servlet
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
I think this is an artificial distinction, Anne. I'd suspect the
difference in performance of your SOAP platforms is due more to how
they're structured internally rather than to any inherent differences in
C++ vs Java. For instance, Java SOAP implementations commonly use
reflection to access data in objects, which is always slower than direct
access (even with the improvements that have been made in recent JVMs).
With C++ this is not an option. That said, there are also other issues
that may play into this particular application, such as the better
socket handling allowed by C++.
I don't know about the Tuxedo vs app server comparison, though my
understanding is that Tuxedo handles only one particular portion of the
work that's done by an app server and hence can be heavily optimized for
that one purpose. Servlet/JSP engines such as Resin have certainly shown
much superior performance vs IIS/ASP in the past, even though IIS/ASP
was an "integrated" component of the OS. I haven't seen the latest
figures now that MS as adopted a JSP-style compiled code approach for
ASPs, so it's possible the advantage has swung back the other way again.
The point is that implementation and internal design (not just tuning,
which is a last minute attempt to clean up some of the worst excesses of
poorly performing code) matter more than the choice of language.
- Dennis
Anne Thomas Manes wrote:
>Dennis,
>
>I absolutely agree with you regarding application code. Using well-optimized
>code and a good application server, you ought to be able to make a Java
>application run at a speed that's reasonably comparable to a C++
>application. There's a bigger difference, though, when it comes to
>infrastructure code. In my experience, SOAP *platforms* built with C++ run a
>lot faster than those built with Java. Just as you won't find a J2EE app
>server that can compare with Tuxedo.
>
>Best regards,
>Anne
>
>
>
>>-----Original Message-----
>>From: Dennis Sosnoski [mailto:dms@sosnoski.com]
>>Sent: Sunday, February 02, 2003 2:18 PM
>>To: axis-user@xml.apache.org
>>Subject: Re: standalone vs. servlet
>>
>>
>>Anne Thomas Manes wrote:
>>
>>
>>
>>>There's no doubt that a C++ environment will offer higher
>>>
>>>
>>performance than a
>>
>>
>>>Java environment. Ask Systinet. WASP for C++ is a *lot* faster
>>>
>>>
>>than WASP for
>>
>>
>>>Java. The two environments use basically the same architecture, but C is
>>>just faster than Java. Even so I suspect that it would be easier to make
>>>WASP for Java support massive scalability than WASP for C++. All
>>>
>>>
>>you have to
>>
>>
>>>do is deploy it in WebLogic. There isn't an app server comparable to
>>>WebLogic for the C++ world. (well -- there's Tuxedo -- but I
>>>
>>>
>>don't know of
>>
>>
>>>anyone who's developed a SOAP platform for Tuxedo yet). But
>>>
>>>
>>since C++ is so
>>
>>
>>>much faster than Java, the threshold at which you need a really
>>>
>>>
>>high-end app
>>
>>
>>>server is quite a bit higher.
>>>
>>>
>>>
>>There's no reason for massive speed differences between C++ and Java
>>aside from developers not knowing what they're doing. Well designed Java
>>code should be no more than a maximum of about 30-40% slower than
>>equally well designed C++ code (after loading and initial JVM
>>optimization). If you're getting worse results than that it's due to
>>your developers, not to the language/platform.
>>
>>I've personally replaced C++ subsystems with Java subsystems that did
>>more work and did it several times faster, while being more maintainable
>>than the C++ code had been. I've also improved the performance of one
>>enterprise Java system by a factor of more than 100 in a few weeks work
>>(most of which was spent convincing the technical management of my
>>reasons, through a detailed timing analysis).
>>
>>There does seem to be a tendency for Java developers to write horrible
>>inefficient code. This may be a side effect of Java features - with
>>garbage collection behind the scenes, and threads so easy to create,
>>it's very easy to ignore the performance implications of what you're
>>doing. Don't blame the platform, though.
>>
>> - Dennis
>>
>>Dennis M. Sosnoski
>>Enterprise Java, XML, and Web Services Support
>>http://www.sosnoski.com
>>Redmond, WA 425.885.7197
>>
>>
>>
>
>
>
Re: standalone vs. servlet
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Anne Thomas Manes" <an...@manes.net>
To: <ax...@xml.apache.org>
Sent: Sunday, February 02, 2003 11:46
Subject: RE: standalone vs. servlet
> Dennis,
>
> I absolutely agree with you regarding application code. Using
well-optimized
> code and a good application server, you ought to be able to make a Java
> application run at a speed that's reasonably comparable to a C++
> application. There's a bigger difference, though, when it comes to
> infrastructure code. In my experience, SOAP *platforms* built with C++ run
a
> lot faster than those built with Java. Just as you won't find a J2EE app
> server that can compare with Tuxedo.
Do you think that is an artifact of the C++ parsers, like MSXML4, actually
being pretty impressively good compared to those in the java space? Or is it
some other reason, like the dev team spent more time on tuning.
Getting back to Denis' observation: yes, badly written C++ apps can have
their own problems, esp. around concurrency, and as memory leaks tend to
show up faster, there are big barriers to writing 7x24 systems. Plus you
need to have people on the dev team who know the diff between strcpy() and
strncpy(), and how to use the latter properly.
That said, friends of mine do 7x24 stuff for telcos, and I have dabbled in
the performance area. if you really know what you are doing, and know the
target system (esp CPU cache properties and how its multiprocessor cache
coherency works), and can insert prefetch instructions into your source, you
can do stunningly fast code, at the risk of creating a maintenance nightmare
later on, by virtue of the aggressively unsynchronised code you've just
written. But perf tuned java has the same problem -if you write code knowing
that int reads and writes are atomic and dont need syncing, and someone
chanigns that field to a long, everything goes pear shaped.
-steve
RE: standalone vs. servlet
Posted by Anne Thomas Manes <an...@manes.net>.
Dennis,
I absolutely agree with you regarding application code. Using well-optimized
code and a good application server, you ought to be able to make a Java
application run at a speed that's reasonably comparable to a C++
application. There's a bigger difference, though, when it comes to
infrastructure code. In my experience, SOAP *platforms* built with C++ run a
lot faster than those built with Java. Just as you won't find a J2EE app
server that can compare with Tuxedo.
Best regards,
Anne
> -----Original Message-----
> From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> Sent: Sunday, February 02, 2003 2:18 PM
> To: axis-user@xml.apache.org
> Subject: Re: standalone vs. servlet
>
>
> Anne Thomas Manes wrote:
>
> >There's no doubt that a C++ environment will offer higher
> performance than a
> >Java environment. Ask Systinet. WASP for C++ is a *lot* faster
> than WASP for
> >Java. The two environments use basically the same architecture, but C is
> >just faster than Java. Even so I suspect that it would be easier to make
> >WASP for Java support massive scalability than WASP for C++. All
> you have to
> >do is deploy it in WebLogic. There isn't an app server comparable to
> >WebLogic for the C++ world. (well -- there's Tuxedo -- but I
> don't know of
> >anyone who's developed a SOAP platform for Tuxedo yet). But
> since C++ is so
> >much faster than Java, the threshold at which you need a really
> high-end app
> >server is quite a bit higher.
> >
> There's no reason for massive speed differences between C++ and Java
> aside from developers not knowing what they're doing. Well designed Java
> code should be no more than a maximum of about 30-40% slower than
> equally well designed C++ code (after loading and initial JVM
> optimization). If you're getting worse results than that it's due to
> your developers, not to the language/platform.
>
> I've personally replaced C++ subsystems with Java subsystems that did
> more work and did it several times faster, while being more maintainable
> than the C++ code had been. I've also improved the performance of one
> enterprise Java system by a factor of more than 100 in a few weeks work
> (most of which was spent convincing the technical management of my
> reasons, through a detailed timing analysis).
>
> There does seem to be a tendency for Java developers to write horrible
> inefficient code. This may be a side effect of Java features - with
> garbage collection behind the scenes, and threads so easy to create,
> it's very easy to ignore the performance implications of what you're
> doing. Don't blame the platform, though.
>
> - Dennis
>
> Dennis M. Sosnoski
> Enterprise Java, XML, and Web Services Support
> http://www.sosnoski.com
> Redmond, WA 425.885.7197
>
Re: standalone vs. servlet
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Anne Thomas Manes wrote:
>There's no doubt that a C++ environment will offer higher performance than a
>Java environment. Ask Systinet. WASP for C++ is a *lot* faster than WASP for
>Java. The two environments use basically the same architecture, but C is
>just faster than Java. Even so I suspect that it would be easier to make
>WASP for Java support massive scalability than WASP for C++. All you have to
>do is deploy it in WebLogic. There isn't an app server comparable to
>WebLogic for the C++ world. (well -- there's Tuxedo -- but I don't know of
>anyone who's developed a SOAP platform for Tuxedo yet). But since C++ is so
>much faster than Java, the threshold at which you need a really high-end app
>server is quite a bit higher.
>
There's no reason for massive speed differences between C++ and Java
aside from developers not knowing what they're doing. Well designed Java
code should be no more than a maximum of about 30-40% slower than
equally well designed C++ code (after loading and initial JVM
optimization). If you're getting worse results than that it's due to
your developers, not to the language/platform.
I've personally replaced C++ subsystems with Java subsystems that did
more work and did it several times faster, while being more maintainable
than the C++ code had been. I've also improved the performance of one
enterprise Java system by a factor of more than 100 in a few weeks work
(most of which was spent convincing the technical management of my
reasons, through a detailed timing analysis).
There does seem to be a tendency for Java developers to write horrible
inefficient code. This may be a side effect of Java features - with
garbage collection behind the scenes, and threads so easy to create,
it's very easy to ignore the performance implications of what you're
doing. Don't blame the platform, though.
- Dennis
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services Support
http://www.sosnoski.com
Redmond, WA 425.885.7197
RE: standalone vs. servlet
Posted by Jess Sightler <js...@eximtechnologies.com>.
On Sun, 2003-02-02 at 13:52, Anne Thomas Manes wrote:
> A servlet container is a container within an application server that can
> host Java servlets and JavaServer Pages (JSPs). All J2EE application
> services include a servlet container. They also include an EJB container.
> There are a number of application servers that provide a servlet container,
> but not an EJB container. These app servers are generally referred to as a
> servlet engine. Examples include Apache Tomcat, Jetty Server, Caucho Resin,
> and Orion Server. Tomcat and Jetty are open source. Resin and Orion are very
> low cost by comparison to J2EE app servers.
W/r/t Orion Server, this is completely false. Orion server is a full
J2EE solution WITH an EJB container (and a pretty good one at that).
> A servlet engine is a
> lightweight app server that offers a bunch of resource optimization features
> that support the 80/20 rule. Most people find that a servlet engine meets
> their scalability requirements. An EJB container uses a different set of
> optimization strategies that impose a lot more overhead, but turn out to be
> extremely valuable when dealing with very high scalability requirements and
> transaction and security management. (Note that the performance and
> scalability features of an application server -- whether it's just a servlet
> engine or a J2EE server -- varies dramatically by implementation. I really
> like Jetty for its lean and mean performance. Orion is one of the best
> scaling servlet engines. In my opinion, WebLogic offers the best scalability
> for both servlets and EJBs.)
>
> There's no doubt that a C++ environment will offer higher performance than a
> Java environment. Ask Systinet. WASP for C++ is a *lot* faster than WASP for
> Java. The two environments use basically the same architecture, but C is
> just faster than Java. Even so I suspect that it would be easier to make
> WASP for Java support massive scalability than WASP for C++. All you have to
> do is deploy it in WebLogic. There isn't an app server comparable to
> WebLogic for the C++ world. (well -- there's Tuxedo -- but I don't know of
> anyone who's developed a SOAP platform for Tuxedo yet). But since C++ is so
> much faster than Java, the threshold at which you need a really high-end app
> server is quite a bit higher.
>
> The first decision you need to make is whether you'd like to develop in Java
> or C++. C++ offers better performance. Java offers huge productivity gains.
>
> Anne
>
> > -----Original Message-----
> > From: Chuck Musser [mailto:chuckie@well.com]
> > Sent: Sunday, February 02, 2003 11:37 AM
> > To: axis-user@xml.apache.org
> > Subject: Re: standalone vs. servlet
> >
> >
> > Anne,
> >
> > Thanks for your response. As you probably suspected, when I said
> > "native", I meant something written in C, C++ or some other language
> > that gets compiled to machine code. Things of that nature are obviously
> > faster, so I guess my question really boiled down to: what are the
> > advantages of an application server such as Apache and Axis (lots of
> > built-in functionality, scalability) and what are the disadvantages
> > (complexity, possibly lower raw performance).
> >
> > Based on what you've said, I'm leaning more toward the server-based
> > solution. I'd not taken that into consideration until you mentioned it,
> > but my application would probably need multiple services. It looks like
> > a simple standalone solution won't support that, at least not elegantly.
> > I still don't know whether a given server is "fast enough", but that's
> > something I'll have to mock up and test myself.
> >
> > A final question: is a servlet container the same thing as a J2EE server?
> >
> > Thanks,
> >
> > Chuck
> >
> > Anne Thomas Manes wrote:
> >
> > >I'm not sure that I understand what you mean by "native" versus
> > Java. A SOAP
> > >implementation provides language bindings for SOAP. Axis supports Java.
> > >gSOAP supports C or C++. If your application is written in Java, then you
> > >need a SOAP implementation that supports Java. If your application is
> > >written in C or C++, then you need a SOAP implementation that
> > supports C or
> > >C++. If your application is written in Perl, then you need a SOAP
> > >implementation that support Perl. If you use multiple progamming
> > languages,
> > >then you need multiple SOAP implementations.
> > >
> > >Assuming that your SOAP service communicates using HTTP, then
> > you must have
> > >an HTTP server associated with the SOAP service. Most SOAP
> > implementations
> > >take the easy route and rely on an existing HTTP server.
> > >
> > >The main component of a SOAP implementation is a SOAP message
> > processor. The
> > >SOAP message processor processes SOAP messages, identifies what
> > to do with
> > >the message (i.e. identify what application to invoke to process the
> > >message), transforms the SOAP message body into native language
> > objects, and
> > >load/invoke the appropriate application. If the SOAP engine needs to load
> > >the program, it generally uses an application server/container
> > to host and
> > >manage the applications.
> > >
> > >There are three basic configurations: embedded, standalone, server-based.
> > >1 - The embedded option allows you to embed an HTTP server and the SOAP
> > >message processor within your application.
> > >2 - The standalone option essentially creates a dedicated
> > application server
> > >to load/manage your services.
> > >3 - The server-based option allows you to run the environment in
> > and rely on
> > >the application management facilities of an existing application server.
> > >
> > >In general, if you have only one service, the embedded option is the most
> > >efficient. Options 2 and 3 allow you to share resources, which
> > is important
> > >when you're dealing with multiple services and multiple clients.
> > A high-end
> > >application server often provides a number of features (clustering,
> > >multithreading, resources pooling, etc.) that you need for high
> > scalability.
> > >So in general, you'll achieve your best raw performance (highest
> > throughput
> > >for one user) when using option #1 or #2. You achieve your best
> > scalability
> > >(highest throughput for many users) when using option #3 with a highly
> > >scalable app server.
> > >
> > >C++ is faster than Java, so C++ SOAP is faster than Java SOAP --
> > in terms of
> > >raw performance.
> > >
> > >I believe that gSOAP only supports the first option. If you have only one
> > >service, it's a simple and easy way to implement a service. If
> > you have lots
> > >of services, it's not the most efficient use of system resources. One
> > >caution about gSOAP is that it only supports RPC/encoded, which
> > might cause
> > >interoperability issues. Your other C++ options include Systinet WASP for
> > >C++ and RogueWave LEIF. WASP supports all three options. For
> > option #3, it
> > >can be deployed within Apache Web Server, IIS, and Netscape Web
> > Server. LEIF
> > >only supports option #3 using RogueWave's C++ servlet-like engine.
> > >
> > >Axis doesn't provide a built-in HTTP server or application server, so it
> > >assumes that you will use a servlet engine to host the
> > environment. You can
> > >create a dedicated server (#2) or you can deploy it in pretty
> > much any J2EE
> > >application server (#3). You have more than 20 Java SOAP
> > implementations to
> > >choose from. Most implementations assume that you will deploy using a
> > >servlet engine or J2EE application server. Systinet WASP for Java and The
> > >Mind Electric GLUE both support all three options. Killdara
> > Vitiris supports
> > >only the embedded option.
> > >
> > >As far as performance testing tools, I can recommend Mindreef SOAPscope.
> > >It's really a diagnostic tool rather than a performance testing
> > tool, but it
> > >can measure throughput.
> > >
> > >Regards,
> > >Anne
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: Chuck Musser [mailto:chuckie@well.com]
> > >>Sent: Saturday, February 01, 2003 12:26 AM
> > >>To: axis-user@xml.apache.org
> > >>Subject: standalone vs. servlet
> > >>
> > >>
> > >>I'm evaluating SOAP servers with an eye toward performance and ease of
> > >>deployment. My instinct is to prefer a native SOAP implementation over a
> > >>Java implementation and to prefer a standalone implementation over one
> > >>that lives inside a servlet container. But I'm new to this stuff, so I
> > >>really don't know. I do realize that Java has lots of built in
> > >>networking and database connectivity that native implementations don't
> > >>have. Has anyone evaluated these issues:
> > >>
> > >>1.) Are there advantages to deploying Axis inside a servlet container
> > >>rather than using the standalone server?
> > >>2.) How does the performance compare for servlet vs. standalone?
> > >>3.) How does the throughput of Axis compare to a "native"
> > >>implementation, like gSOAP.
> > >>4.) What sort of testing tools are available for evaluating the
> > >>throughput of various SOAP servers.
> > >>
> > >>Thanks,
> > >>
> > >>Chuck
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
--
=======================================
Jess Sightler
Senior Developer
Exim Technologies
131 Falls Street
Greenville SC 29601
Phone: 864-679-4651
=======================================
RE: standalone vs. servlet
Posted by Anne Thomas Manes <an...@manes.net>.
A servlet container is a container within an application server that can
host Java servlets and JavaServer Pages (JSPs). All J2EE application
services include a servlet container. They also include an EJB container.
There are a number of application servers that provide a servlet container,
but not an EJB container. These app servers are generally referred to as a
servlet engine. Examples include Apache Tomcat, Jetty Server, Caucho Resin,
and Orion Server. Tomcat and Jetty are open source. Resin and Orion are very
low cost by comparison to J2EE app servers. A servlet engine is a
lightweight app server that offers a bunch of resource optimization features
that support the 80/20 rule. Most people find that a servlet engine meets
their scalability requirements. An EJB container uses a different set of
optimization strategies that impose a lot more overhead, but turn out to be
extremely valuable when dealing with very high scalability requirements and
transaction and security management. (Note that the performance and
scalability features of an application server -- whether it's just a servlet
engine or a J2EE server -- varies dramatically by implementation. I really
like Jetty for its lean and mean performance. Orion is one of the best
scaling servlet engines. In my opinion, WebLogic offers the best scalability
for both servlets and EJBs.)
There's no doubt that a C++ environment will offer higher performance than a
Java environment. Ask Systinet. WASP for C++ is a *lot* faster than WASP for
Java. The two environments use basically the same architecture, but C is
just faster than Java. Even so I suspect that it would be easier to make
WASP for Java support massive scalability than WASP for C++. All you have to
do is deploy it in WebLogic. There isn't an app server comparable to
WebLogic for the C++ world. (well -- there's Tuxedo -- but I don't know of
anyone who's developed a SOAP platform for Tuxedo yet). But since C++ is so
much faster than Java, the threshold at which you need a really high-end app
server is quite a bit higher.
The first decision you need to make is whether you'd like to develop in Java
or C++. C++ offers better performance. Java offers huge productivity gains.
Anne
> -----Original Message-----
> From: Chuck Musser [mailto:chuckie@well.com]
> Sent: Sunday, February 02, 2003 11:37 AM
> To: axis-user@xml.apache.org
> Subject: Re: standalone vs. servlet
>
>
> Anne,
>
> Thanks for your response. As you probably suspected, when I said
> "native", I meant something written in C, C++ or some other language
> that gets compiled to machine code. Things of that nature are obviously
> faster, so I guess my question really boiled down to: what are the
> advantages of an application server such as Apache and Axis (lots of
> built-in functionality, scalability) and what are the disadvantages
> (complexity, possibly lower raw performance).
>
> Based on what you've said, I'm leaning more toward the server-based
> solution. I'd not taken that into consideration until you mentioned it,
> but my application would probably need multiple services. It looks like
> a simple standalone solution won't support that, at least not elegantly.
> I still don't know whether a given server is "fast enough", but that's
> something I'll have to mock up and test myself.
>
> A final question: is a servlet container the same thing as a J2EE server?
>
> Thanks,
>
> Chuck
>
> Anne Thomas Manes wrote:
>
> >I'm not sure that I understand what you mean by "native" versus
> Java. A SOAP
> >implementation provides language bindings for SOAP. Axis supports Java.
> >gSOAP supports C or C++. If your application is written in Java, then you
> >need a SOAP implementation that supports Java. If your application is
> >written in C or C++, then you need a SOAP implementation that
> supports C or
> >C++. If your application is written in Perl, then you need a SOAP
> >implementation that support Perl. If you use multiple progamming
> languages,
> >then you need multiple SOAP implementations.
> >
> >Assuming that your SOAP service communicates using HTTP, then
> you must have
> >an HTTP server associated with the SOAP service. Most SOAP
> implementations
> >take the easy route and rely on an existing HTTP server.
> >
> >The main component of a SOAP implementation is a SOAP message
> processor. The
> >SOAP message processor processes SOAP messages, identifies what
> to do with
> >the message (i.e. identify what application to invoke to process the
> >message), transforms the SOAP message body into native language
> objects, and
> >load/invoke the appropriate application. If the SOAP engine needs to load
> >the program, it generally uses an application server/container
> to host and
> >manage the applications.
> >
> >There are three basic configurations: embedded, standalone, server-based.
> >1 - The embedded option allows you to embed an HTTP server and the SOAP
> >message processor within your application.
> >2 - The standalone option essentially creates a dedicated
> application server
> >to load/manage your services.
> >3 - The server-based option allows you to run the environment in
> and rely on
> >the application management facilities of an existing application server.
> >
> >In general, if you have only one service, the embedded option is the most
> >efficient. Options 2 and 3 allow you to share resources, which
> is important
> >when you're dealing with multiple services and multiple clients.
> A high-end
> >application server often provides a number of features (clustering,
> >multithreading, resources pooling, etc.) that you need for high
> scalability.
> >So in general, you'll achieve your best raw performance (highest
> throughput
> >for one user) when using option #1 or #2. You achieve your best
> scalability
> >(highest throughput for many users) when using option #3 with a highly
> >scalable app server.
> >
> >C++ is faster than Java, so C++ SOAP is faster than Java SOAP --
> in terms of
> >raw performance.
> >
> >I believe that gSOAP only supports the first option. If you have only one
> >service, it's a simple and easy way to implement a service. If
> you have lots
> >of services, it's not the most efficient use of system resources. One
> >caution about gSOAP is that it only supports RPC/encoded, which
> might cause
> >interoperability issues. Your other C++ options include Systinet WASP for
> >C++ and RogueWave LEIF. WASP supports all three options. For
> option #3, it
> >can be deployed within Apache Web Server, IIS, and Netscape Web
> Server. LEIF
> >only supports option #3 using RogueWave's C++ servlet-like engine.
> >
> >Axis doesn't provide a built-in HTTP server or application server, so it
> >assumes that you will use a servlet engine to host the
> environment. You can
> >create a dedicated server (#2) or you can deploy it in pretty
> much any J2EE
> >application server (#3). You have more than 20 Java SOAP
> implementations to
> >choose from. Most implementations assume that you will deploy using a
> >servlet engine or J2EE application server. Systinet WASP for Java and The
> >Mind Electric GLUE both support all three options. Killdara
> Vitiris supports
> >only the embedded option.
> >
> >As far as performance testing tools, I can recommend Mindreef SOAPscope.
> >It's really a diagnostic tool rather than a performance testing
> tool, but it
> >can measure throughput.
> >
> >Regards,
> >Anne
> >
> >
> >
> >>-----Original Message-----
> >>From: Chuck Musser [mailto:chuckie@well.com]
> >>Sent: Saturday, February 01, 2003 12:26 AM
> >>To: axis-user@xml.apache.org
> >>Subject: standalone vs. servlet
> >>
> >>
> >>I'm evaluating SOAP servers with an eye toward performance and ease of
> >>deployment. My instinct is to prefer a native SOAP implementation over a
> >>Java implementation and to prefer a standalone implementation over one
> >>that lives inside a servlet container. But I'm new to this stuff, so I
> >>really don't know. I do realize that Java has lots of built in
> >>networking and database connectivity that native implementations don't
> >>have. Has anyone evaluated these issues:
> >>
> >>1.) Are there advantages to deploying Axis inside a servlet container
> >>rather than using the standalone server?
> >>2.) How does the performance compare for servlet vs. standalone?
> >>3.) How does the throughput of Axis compare to a "native"
> >>implementation, like gSOAP.
> >>4.) What sort of testing tools are available for evaluating the
> >>throughput of various SOAP servers.
> >>
> >>Thanks,
> >>
> >>Chuck
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
Re: standalone vs. servlet
Posted by Chuck Musser <ch...@well.com>.
Anne,
Thanks for your response. As you probably suspected, when I said
"native", I meant something written in C, C++ or some other language
that gets compiled to machine code. Things of that nature are obviously
faster, so I guess my question really boiled down to: what are the
advantages of an application server such as Apache and Axis (lots of
built-in functionality, scalability) and what are the disadvantages
(complexity, possibly lower raw performance).
Based on what you've said, I'm leaning more toward the server-based
solution. I'd not taken that into consideration until you mentioned it,
but my application would probably need multiple services. It looks like
a simple standalone solution won't support that, at least not elegantly.
I still don't know whether a given server is "fast enough", but that's
something I'll have to mock up and test myself.
A final question: is a servlet container the same thing as a J2EE server?
Thanks,
Chuck
Anne Thomas Manes wrote:
>I'm not sure that I understand what you mean by "native" versus Java. A SOAP
>implementation provides language bindings for SOAP. Axis supports Java.
>gSOAP supports C or C++. If your application is written in Java, then you
>need a SOAP implementation that supports Java. If your application is
>written in C or C++, then you need a SOAP implementation that supports C or
>C++. If your application is written in Perl, then you need a SOAP
>implementation that support Perl. If you use multiple progamming languages,
>then you need multiple SOAP implementations.
>
>Assuming that your SOAP service communicates using HTTP, then you must have
>an HTTP server associated with the SOAP service. Most SOAP implementations
>take the easy route and rely on an existing HTTP server.
>
>The main component of a SOAP implementation is a SOAP message processor. The
>SOAP message processor processes SOAP messages, identifies what to do with
>the message (i.e. identify what application to invoke to process the
>message), transforms the SOAP message body into native language objects, and
>load/invoke the appropriate application. If the SOAP engine needs to load
>the program, it generally uses an application server/container to host and
>manage the applications.
>
>There are three basic configurations: embedded, standalone, server-based.
>1 - The embedded option allows you to embed an HTTP server and the SOAP
>message processor within your application.
>2 - The standalone option essentially creates a dedicated application server
>to load/manage your services.
>3 - The server-based option allows you to run the environment in and rely on
>the application management facilities of an existing application server.
>
>In general, if you have only one service, the embedded option is the most
>efficient. Options 2 and 3 allow you to share resources, which is important
>when you're dealing with multiple services and multiple clients. A high-end
>application server often provides a number of features (clustering,
>multithreading, resources pooling, etc.) that you need for high scalability.
>So in general, you'll achieve your best raw performance (highest throughput
>for one user) when using option #1 or #2. You achieve your best scalability
>(highest throughput for many users) when using option #3 with a highly
>scalable app server.
>
>C++ is faster than Java, so C++ SOAP is faster than Java SOAP -- in terms of
>raw performance.
>
>I believe that gSOAP only supports the first option. If you have only one
>service, it's a simple and easy way to implement a service. If you have lots
>of services, it's not the most efficient use of system resources. One
>caution about gSOAP is that it only supports RPC/encoded, which might cause
>interoperability issues. Your other C++ options include Systinet WASP for
>C++ and RogueWave LEIF. WASP supports all three options. For option #3, it
>can be deployed within Apache Web Server, IIS, and Netscape Web Server. LEIF
>only supports option #3 using RogueWave's C++ servlet-like engine.
>
>Axis doesn't provide a built-in HTTP server or application server, so it
>assumes that you will use a servlet engine to host the environment. You can
>create a dedicated server (#2) or you can deploy it in pretty much any J2EE
>application server (#3). You have more than 20 Java SOAP implementations to
>choose from. Most implementations assume that you will deploy using a
>servlet engine or J2EE application server. Systinet WASP for Java and The
>Mind Electric GLUE both support all three options. Killdara Vitiris supports
>only the embedded option.
>
>As far as performance testing tools, I can recommend Mindreef SOAPscope.
>It's really a diagnostic tool rather than a performance testing tool, but it
>can measure throughput.
>
>Regards,
>Anne
>
>
>
>>-----Original Message-----
>>From: Chuck Musser [mailto:chuckie@well.com]
>>Sent: Saturday, February 01, 2003 12:26 AM
>>To: axis-user@xml.apache.org
>>Subject: standalone vs. servlet
>>
>>
>>I'm evaluating SOAP servers with an eye toward performance and ease of
>>deployment. My instinct is to prefer a native SOAP implementation over a
>>Java implementation and to prefer a standalone implementation over one
>>that lives inside a servlet container. But I'm new to this stuff, so I
>>really don't know. I do realize that Java has lots of built in
>>networking and database connectivity that native implementations don't
>>have. Has anyone evaluated these issues:
>>
>>1.) Are there advantages to deploying Axis inside a servlet container
>>rather than using the standalone server?
>>2.) How does the performance compare for servlet vs. standalone?
>>3.) How does the throughput of Axis compare to a "native"
>>implementation, like gSOAP.
>>4.) What sort of testing tools are available for evaluating the
>>throughput of various SOAP servers.
>>
>>Thanks,
>>
>>Chuck
>>
>>
>>
>>
>
>
>
>
RE: standalone vs. servlet
Posted by Anne Thomas Manes <an...@manes.net>.
I'm not sure that I understand what you mean by "native" versus Java. A SOAP
implementation provides language bindings for SOAP. Axis supports Java.
gSOAP supports C or C++. If your application is written in Java, then you
need a SOAP implementation that supports Java. If your application is
written in C or C++, then you need a SOAP implementation that supports C or
C++. If your application is written in Perl, then you need a SOAP
implementation that support Perl. If you use multiple progamming languages,
then you need multiple SOAP implementations.
Assuming that your SOAP service communicates using HTTP, then you must have
an HTTP server associated with the SOAP service. Most SOAP implementations
take the easy route and rely on an existing HTTP server.
The main component of a SOAP implementation is a SOAP message processor. The
SOAP message processor processes SOAP messages, identifies what to do with
the message (i.e. identify what application to invoke to process the
message), transforms the SOAP message body into native language objects, and
load/invoke the appropriate application. If the SOAP engine needs to load
the program, it generally uses an application server/container to host and
manage the applications.
There are three basic configurations: embedded, standalone, server-based.
1 - The embedded option allows you to embed an HTTP server and the SOAP
message processor within your application.
2 - The standalone option essentially creates a dedicated application server
to load/manage your services.
3 - The server-based option allows you to run the environment in and rely on
the application management facilities of an existing application server.
In general, if you have only one service, the embedded option is the most
efficient. Options 2 and 3 allow you to share resources, which is important
when you're dealing with multiple services and multiple clients. A high-end
application server often provides a number of features (clustering,
multithreading, resources pooling, etc.) that you need for high scalability.
So in general, you'll achieve your best raw performance (highest throughput
for one user) when using option #1 or #2. You achieve your best scalability
(highest throughput for many users) when using option #3 with a highly
scalable app server.
C++ is faster than Java, so C++ SOAP is faster than Java SOAP -- in terms of
raw performance.
I believe that gSOAP only supports the first option. If you have only one
service, it's a simple and easy way to implement a service. If you have lots
of services, it's not the most efficient use of system resources. One
caution about gSOAP is that it only supports RPC/encoded, which might cause
interoperability issues. Your other C++ options include Systinet WASP for
C++ and RogueWave LEIF. WASP supports all three options. For option #3, it
can be deployed within Apache Web Server, IIS, and Netscape Web Server. LEIF
only supports option #3 using RogueWave's C++ servlet-like engine.
Axis doesn't provide a built-in HTTP server or application server, so it
assumes that you will use a servlet engine to host the environment. You can
create a dedicated server (#2) or you can deploy it in pretty much any J2EE
application server (#3). You have more than 20 Java SOAP implementations to
choose from. Most implementations assume that you will deploy using a
servlet engine or J2EE application server. Systinet WASP for Java and The
Mind Electric GLUE both support all three options. Killdara Vitiris supports
only the embedded option.
As far as performance testing tools, I can recommend Mindreef SOAPscope.
It's really a diagnostic tool rather than a performance testing tool, but it
can measure throughput.
Regards,
Anne
> -----Original Message-----
> From: Chuck Musser [mailto:chuckie@well.com]
> Sent: Saturday, February 01, 2003 12:26 AM
> To: axis-user@xml.apache.org
> Subject: standalone vs. servlet
>
>
> I'm evaluating SOAP servers with an eye toward performance and ease of
> deployment. My instinct is to prefer a native SOAP implementation over a
> Java implementation and to prefer a standalone implementation over one
> that lives inside a servlet container. But I'm new to this stuff, so I
> really don't know. I do realize that Java has lots of built in
> networking and database connectivity that native implementations don't
> have. Has anyone evaluated these issues:
>
> 1.) Are there advantages to deploying Axis inside a servlet container
> rather than using the standalone server?
> 2.) How does the performance compare for servlet vs. standalone?
> 3.) How does the throughput of Axis compare to a "native"
> implementation, like gSOAP.
> 4.) What sort of testing tools are available for evaluating the
> throughput of various SOAP servers.
>
> Thanks,
>
> Chuck
>
>