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]
