I investigated this further and found that there definitely is a problem
in 1.0 with large messages using RPC encoding. With my particular test
data it started showing up at the 320KB message size and got
exponentially worse with larger sizes. I think I've tracked this down,
and have entered a
WJCarpenter wrote:
the times). These figures are from Sun JRE 1.3.1 on Linux, running on a
PIIIm with 256MB RAM. I used "-Xmx64M -Xms64M" options on the Java
command line to avoid a lot of threshing as the heap grew; running with
I am curious if you measured heap use and if 64 MB is enough?
> the times). These figures are from Sun JRE 1.3.1 on Linux, running on a
> PIIIm with 256MB RAM. I used "-Xmx64M -Xms64M" options on the Java
> command line to avoid a lot of threshing as the heap grew; running with
I am curious if you measured heap use and if 64 MB is enough? I haven't
done an
Martin,
I noticed this email a while ago and wanted to look into it. I see by
your recent email that you're now getting away from using Axis, but
thought it might be of interest to other people on the list anyway.
Assuming you were using separate client and server systems for this
test, I sus
I was doing some benchmarking to test how much it would impact on
performance to break up a single, large request into several smaller ones.
I was expecting of course that for a fixed volume of data, dividing it into
more separate messages would increase the overheads and make things slower.
What
