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:06:19 GMT
and i use caching

Philipp Perner schrieb:
> 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
>
>


---------------------------------------------------------------------
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