axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Musser <chuc...@well.com>
Subject Re: standalone vs. servlet
Date Mon, 03 Feb 2003 04:17:31 GMT
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
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>
>
>  
>


Mime
View raw message