Hi Rodrigo,
Thanks for your quick and very useful reply. I would appreciate, if
somebody else could join the discussion too.
Now I would like to comment on your comments. :)
Rodrigo Ruiz wrote:
> * I think the benchmark is basically OK. I suppose you are measuring
> total round-trip times, aren't you?
I think so. What I understand as total round-trip time is from
executing
the stub until getting the response.
> * You don't mention anything about mean times. Although a single
> execution may be enough for large attachments, for small ones it
would
> be useful to repeat the invocation several times, and obtain means
and
> deviations.
I tried every file size with 4 different file types: executable, jpeg,
zip, xml
From these roundtrips I calculated the mean time - this is the one
displayed
The deviation of the roundtrips can be neglected.
> * Personally, my opinion is that having both, client and server, on
> the same host is not the most typical scenario, but I think it still
> must be included in any benchmark, as it has its own particularities.
> I will come back to this later.
For development purposes I don't have the possibilities to test in a
distributed area. But in near future I can provide data of "real"
remote
invocation.
> * In order to ensure that the results can be compared, sooner or
later
> a common source code should be used. This one smells to a project ;-)
You are absolutely right. I can provide my wsdl file, to give other
people the chance to test it.
> * You have not included information about your disk in your
> configuration. As you are writing the attachment to disk, its
> characteristics are relevant (IDE / SATA, rpm, and the like).
> Depending on the OS, the filesystem should be also specified.
Ok, you are right. Here is some data:
Chipset Intel 945G
CPU Name Intel Pentium 4
CPU MHz 3200
No. of processors 1
System Bus 533 MHz FSB
Memory 1024 MB DDR2 SD-RAM
HDD SATA-II 80GB 7200 rpm
Filesystem NTFS
LAN Broadcom BCM5751, 1000 Mbit/s
OS Windows2000 SP4
> * TCP/IP stack implementations are totally different between OSs, and
> the same can be said about disk I/O. It also influence the default
JVM
> settings.
TCP/IP Stack implementations?
Concerning disc I/O:
write speed average: 22,37 MB/s
read speed average: 1342,09 MB/s
> * The JVM version is another important field to include in the
> configuration. And also its configuration flags (GC policies, etc.)
The axis server runs on j2sdk1.4.2 whereas my client application , i.e.
a second tomcat web application for upload, runs on jdk1.5.0_08
Due to Java Heap Space errors, I started the axis2 client with the java
option -Xms128M -Xmx1024M
> * Just for curiosity, do you really have 1028MB, or is it an
errata? :-D
of course not ;) 1024
> * The file sizes look a bit arbitrary. Maybe it would be better to
use
> "nicer" sizes ;-)
I took sizes of files I found on my computer in the types I mentioned
above. And so these sizes "occurred"
> * The times you have obtained show a rather poor performance. I am
> just guessing now but, does your client get the attachment data
from a
> file?
You are right i'm reading and writing from the same hard disc.
> Reading and writing on the same disk may be the cause for these long
> times. If this is the case, you could try to generate the data on the
> fly and see how the figures change. You are using rather small sizes,
> so you could use in-memory byte arrays with random data.
That's a good idea
> Hey, this seems to me a very good subject to work on, specially now
> that SPEC has cancelled its web service benchmark project
(AppPlatform).
That was my intention. Do you have some benchmarks I can compare to
mine?
What do you mean with publishing in a wiki? Is there already existing a
wiki we can publish our results?
thanks for your very useful comments,
cheers Philipp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
