axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philipp Perner <philipp.per...@healthgate.at>
Subject Re: MTOM Benchmarks
Date Wed, 13 Dec 2006 11:05:03 GMT
you are right.

I missed this significant property.
I'm just working on benchmarks concerning outflow security of the client including:

-) optimizeParts
-) encryptionSymAlgorithm
-) encryptionKeyTransportAlgorithm

like provided here [0]

cheers, 
Philipp

[0] http://ws.apache.org/axis2/modules/rampart/1_0/security-module.html



Paul Fremantle schrieb:
> Philipp
>
> One more question. Are you using the ability of Axis2 to stream the
> file directly to disk?
>
> <parameter name="cacheAttachments" locked="false">true</parameter>
> <parameter name="attachmentDIR" locked="false">/temp</parameter>
> <parameter name="sizeThreshold" locked="false">4000</parameter>
>
> Paul
>
> On 12/13/06, Philipp Perner <philipp.perner@healthgate.at> wrote:
>> 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: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


Mime
View raw message