Menu
▾
▴
Re: [ebxmlms-develop] Re-visiting on Hermes 1 performance
|
From: David RR W. \(XML\) <da...@dr...> - 2006-06-29 16:57:29
|
<div>Ladislav,</div>
<div> </div>
<div>At this point we are suspecting some of the old code we inherited on
the project that is interfacing with Hermes 1.</div>
<div> </div>
<div>To be sure though - we're just trying to see if anyone else had sent
a really large payload 30MB+ across Hermes 1 and see that it takes upto
30+ minutes to send? Typically with a fast link - we'd expect it
to take only 3+ minutes to send.</div>
<div> </div>
<div>If someone else is able to verify that for us - using just bare
Hermes 1 <-> Hermes 1 - then we will know for sure that the issue
is somewhere in the old code that the previous contractor
implemented.</div>
<div> </div>
<div>We've pretty much eliminated everything else at this point! We
did manage to re-build and use the new JAXM and SAAJ libraries with
Hermes 1 - but that made no difference to performance.</div>
<div> </div>
<div>Thanks, DW<BR></div>
<DIV id=wmMessageComp name="wmMessageComp"><BR><BR>
<BLOCKQUOTE style="PADDING-LEFT: 8px; MARGIN-LEFT: 8px; BORDER-LEFT:
blue 2px solid">-------- Original Message --------<BR>Subject: RE:
Re-visiting on Hermes 1 performance<BR>From: Ladislav Urban
<lad...@we...><BR>Date: Wed, June 28, 2006 7:45
pm<BR>To: "David RR Webber (XML)" <da...@dr...>,
ebxmlms-develop<BR><ebx...@li...>,
Vladimir Alexovic<BR><vla...@we...><BR><BR>Hi
David,<BR>we have not tried bigger payloads than 30MB. If you have
several<BR>messages about this size I would consider to look on tomcat
settings and<BR>check if tomcat (java container, OS) tries to swap.
<BR>The reason is I have not seen any size limit that would cause
additional<BR>serialization. Are there such?<BR><BR>Ladislav<BR><BR>On
Wed, 2006-06-28 at 10:03 -0700, David RR Webber (XML) wrote:<BR>>
Ladislav,<BR>> <BR>> Supplemental question - you mentioned
sending 25Mb payloads with<BR>> Hermes 1 - have you tried bigger
payloads - say 50MB?<BR>> <BR>> Appears somewhere around
25MB is the threshold where we start to see<BR>> issues - so I'd be
interested to know if you have tried bigger<BR>> payloads?<BR>>
<BR>> Thanks, DW<BR>> <BR>> <BR>> <BR>>
-------- Original Message --------<BR>>
Subject: Re: Re-visiting on Hermes 1
performance<BR>> From: Ladislav Urban
<lad...@we...><BR>>
Date: Fri, June 23, 2006 8:24 pm<BR>> To:
"David RR Webber (XML)" <da...@dr...><BR>>
Cc: Ashique Tanveer <tan...@od...>, Sacha
Schlegel<BR>> <sa...@sc...>,
Patrick Yee <kc...@ce...><BR>>
<BR>> Hi David,<BR>>
I have some questions about the
problem.<BR>> <BR>>
Firstly, How long does take when you run Send method
with<BR>> large payload <BR>>
on given registered application context?<BR>>
<BR>>
<BR>> The code in hermes is here<BR>>
<BR>> try
{<BR>>
responseCode = connection.getResponseCode();<BR>>
responseMessage = connection.getResponseMessage();<BR>>
} catch (IOException
ioe) {<BR>>
throw new RequestException(ioe.getMessage());<BR>>
}<BR>>
<BR>> <BR>>
<BR>> Do you
have performance problems during receiving large<BR>>
messages? Do you<BR>> use
encryption and DSigs? <BR>> <BR>>
Could you please send me code lines from
msh.jar that cause<BR>> the
slow?<BR>> Is it inside
EbxmlMessage.java<BR>> <BR>>
public void writeTo(<BR>>
OutputStream out,<BR>> String
soapEncoding,<BR>> String
payloadEncoding)<BR>> throws
IOException, SOAPException {<BR>> // we
now keep the SOAP message object away from attachment to<BR>>
avoid<BR>> // it to
load the payload to memory, therefore we are doing<BR>>
our own<BR>> //
writeTo() here<BR>> //
soapMessage.writeTo(out);<BR>>
serialize(out, soapEncoding, payloadEncoding, false);<BR>>
}<BR>>
<BR>> As you can see they use custom
method <BR>> <BR>>
private long serialize(<BR>>
OutputStream out,<BR>> String
soapEncoding,<BR>> String
payloadEncoding,<BR>> boolean
getLengthOnly)<BR>> <BR>>
to prevent keeping large payloads in
memory<BR>> <BR>>
Instead JAXM's SOAPMessage.writeTo<BR>>
<BR>> <BR>>
<BR>> On Thu,
2006-06-22 at 07:04 -0700, David RR Webber (XML)<BR>>
wrote:<BR>> >
Ladislav,<BR>> > <BR>>
> OK - here's the saga so far. We
thought that replacing the<BR>> JAXM
and<BR>> > SAAJ libraries with the
very latest ones would resolve the<BR>>
issue with<BR>> > large
payloads.<BR>> > <BR>>
> After spending two days setting up and
swapping out those<BR>> libraries
-<BR>> > it made no
difference.<BR>> > <BR>>
> So now we're thinking that the issue
is in how Hermes itself<BR>> is<BR>>
> packaging the payload and using JAXM
calls.<BR>> > <BR>>
> Because with Hermes 2 this is not an issue -
and in Hermes 2<BR>> the JAXM<BR>>
> is not present - we're thinking the
solution is to re-factor<BR>>
the<BR>> > Hermes 1 code to use SAAJ
directly - just like Hermes 2 is<BR>>
doing.<BR>> > <BR>>
> My understanding is that JAXM serializes the
payload first -<BR>> instead<BR>>
> of direct streaming from memory - and
over course if the<BR>> payload
is<BR>> > bigger than the magic 10MB
threshold - it does this via disk<BR>>
i/o and<BR>> > hence it runs 100
times slower! All this came about I<BR>>
believe<BR>> > because of the
need to support SMTP delivery - but frankly -<BR>>
that is<BR>> > now
history.<BR>> > <BR>>
> So - can you give any insights? Have you
examined the code<BR>> at this<BR>>
> depth - and is there a simple way to
change Hermes 1 to use<BR>> SAAJ<BR>>
> directly?<BR>>
> <BR>> > All ideas /
code fragments - et al gratefully received!<BR>>
> <BR>> > Thanks,
DW<BR>> -- <BR>>
Ladislav Urban<BR>> CEO<BR>>
Webswell Inc.<BR>>
1333 Howe Avenue, Suite 100<BR>>
Sacramento, 95825 CA<BR>> email:
lad...@we...<BR>> phone:
+1 (916) 290-2040<BR>> fax: +1 (916)
921-2850<BR>> http://www.webswell.com
<BR>-- <BR>Ladislav Urban<BR>CEO<BR>Webswell Inc.<BR>1333 Howe Avenue,
Suite 100<BR>Sacramento, 95825 CA<BR>email:
lad...@we...<BR>phone: +1 (916) 290-2040<BR>fax: +1
(916) 921-2850<BR>http://www.webswell.com </BLOCKQUOTE></DIV>
|
