Skip to Content.
Sympa Menu

perfsonar-dev - Re: [pS-dev] Conf call: Optimizing large data transfers (including Push Interface)

Subject: perfsonar development work

List archive

Re: [pS-dev] Conf call: Optimizing large data transfers (including Push Interface)


Chronological Thread 
  • From: "Michael Bischoff" <>
  • To: "Maciej Glowiak" <>
  • Cc:
  • Subject: Re: [pS-dev] Conf call: Optimizing large data transfers (including Push Interface)
  • Date: Wed, 16 Apr 2008 02:00:30 +0200 (CEST)
  • Importance: Normal

hi again Maciej,

>Michael Bischoff wrote:
>> hi Maciej,
>>
>> Didn't know we already fired away with the a new base, is there a place
>> where this code
>> resides? Also for clarity, when we talk about the base does this include
>> nmwg?
>
>Yes, but it wasn't published yet. We have it locally (on PSNC svn).
>The new base contains also NMWG.
I'd love to take a look at it is there anon read access?

>> On a other note: the discussion about incoming (xml-> Object model) is
>> pretty empty
>> even if we have to build the whole document anyway stream should still
>> improve memory
>> footprint.
>Yes, I know. But there wasn't good solution to combine all goals:
>- make new API similar to old one (to ease developers migration of their
>code)
>- make use of new Axis2 but keep the NMWG classes generic; so separate
>transport
> layer (Axis2) from internal representation
>- make them faster.
The only code that needs to migrate is that of the services, as long as the
Object
model(internal representation) is build they shouldn't care how it's build.
I'm missing the
point as to why or what the problem is.

On an other note, changing internal representation might yield other benefits
and the amount
of 'hurt' in my opinion isn't that great.

>> Improve quality:
>> Assert FindBugs results.
>
>Do you mean http://findbugs.sourceforge.net/ ?
>I haven't been using that so far.

Yes I find that static code analysers add value when used as a supporting
tool. in the old
base it certain highlighted weak parts.

New topic:

About XML Payload complains:

Did a little analysing of a random service request-response and it would seem
the protocol
itself isn't that efficient itself.

Original request: total=2.2 MB (2258887 bytes)
2514 x
<nmwg:metadata id="result2514">
<nmwg:subject id="subject-result2514"/>
<nmwg:parameters id="param1">
<nmwg:parameter value="Zagreb_CARNET" name="receiver"/>
<nmwg:parameter value="9" name="groupsize"/>
<nmwg:parameter value="result2514" name="metadataIdRef"/>
<nmwg:parameter value="60" name="interval"/>
<nmwg:parameter value="7633" name="mid"/>
<nmwg:parameter value="0x0" name="precedence"/>
<nmwg:parameter value="193.198.229.170" name="receiver_ip"/>
<nmwg:parameter value="PetachTikve_IUCC" name="sender"/>
<nmwg:parameter value="128.139.223.10" name="sender_ip"/>
<nmwg:parameter value="41" name="packetsize"/>
</nmwg:parameters>
</nmwg:metadata>

have values as attributes: total=1.1 MB (1109532 bytes)
(ok there is a 'value=' that I forgot to remove and missing '"' and offcourse
the key value
is swapped, the amount of data is what counts)

<nmwg:metadata id="result2514">
<nmwg:subject id="subject-result2514"/>
<nmwg:parameters id="param1">
<nmwg:parameter value="Zagreb_CARNET=receiver" 9=groupsize"
result2514=metadataIdRef" 60=interval" 7633=mid" 0x0=precedence"
193.198.229.170=receiver_ip" PetachTikve_IUCC=sender"
128.139.223.10=sender_ip" 41=packetsize"/>
</nmwg:parameters>
</nmwg:metadata>

removed useless wrappers: total=618.6 KB (633485 bytes)
(key value pairs are still swapped)

<tag Geneva_GEANT="receiver" 9="groupsize" result0="metadataIdRef"
60="interval" 2615="mid"
0xb8="precedence" 62.40.122.3="receiver_ip" Frankfurt_GEANT="sender"
62.40.122.11="sender_ip"
41="packetsize"/>

2.2 MB (2258887 bytes) 100% ---
1.1 MB (1109532 bytes) 49% -51%
618.6 KB (633485 bytes) 28% -72%
(next to payload, changing the protocol also limits object creation(by 14 *
2514 less classes)

on the other hand if we enable compression the repeativeness would get
insanely well
compressed. http://www.thomas-bayer.com/soap-compression-howto.htm axis1
http://wso2.org/library/3007 axis2 (first hits there might be better
resources)

Have we tried this approach?



Archive powered by MHonArc 2.6.16.

Top of Page