axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Performance issues with Axis 1.1/1.2 (Java)
Date Mon, 19 Jan 2004 18:08:47 GMT
I actually made various performance fixes in 1.1/1.2, as did some others.
Most of the problems had to do with uncached reflection code.  

Also, it's pretty easy to get bad performance from axis if you're motivated
to do so -- just use a large set of types and don't reuse Port objects.  Of
course, no one who cares about performance would do that, but if you were
trying to show that your product was better than axis, that's exactly what'd
you do.


-----Original Message-----
From: Steve Loughran []
Sent: Monday, January 19, 2004 10:04 AM
Subject: Re: Performance issues with Axis 1.1/1.2 (Java)

Chetan Lalye wrote:
> Hi,
> With regards to  performance, has there been any performance 
> analysis/measurements \
> done with Axis.  I've been reading articles where other WS vendors claim 
> that their \
> implementation is 4x times faster then Axis. (However the comparison was 
> with Axis \
> 1.0 ) 
> Can the axis developers please comment on this issue with respect to 1.1 
> and the \
> upcoming 1.2 ? Are there any performance improvements in 1.2 ? 

There has been some encoding tuning which should make messages smaller, 
but otherwise I dont know of any major performance tunes.

I think nobody would disagree that performance profiling and tuning of 
Axis would be a good thing. It just so happens that the few developers 
that are highly active in the project (mostly Dims and Tom, right now), 
are too busy with firefighting fundamental bugs to worry about 
performance. i.e. if we cannot get intraoperability between Axis and 
Axis on the same machine sending xsd:time info around, performance seems 
less of an issue.

Also the system was designed for flexiblity, rather than out and out 

That said, if you want to put in some effort profiling Axis on your 
system, identifying areas of trouble, that would be a good move. 
Submitting patches to tune performance would be even better, because it 
can take time to fix performance issues.

I dont know if we could get a 4X speedup however, I wonder what 
'benchmark' they are using. XML parsing has a lot to do with the overall 


View raw message