Re: [ebxmlms-develop] Re-visiting on Hermes 1 performance

[Ladislav U. <lad...@we...>]

Hi David,
we have not tried bigger payloads than 30MB. If you have several
messages about this size I would consider to look on tomcat settings and
check if tomcat (java container, OS) tries to swap. 
The reason is I have not seen any size limit that would cause additional
serialization. Are there such?

Ladislav

On Wed, 2006-06-28 at 10:03 -0700, David RR Webber (XML) wrote:
> Ladislav,
>  
> Supplemental question - you mentioned sending 25Mb payloads with
> Hermes 1 - have you tried bigger payloads - say 50MB?
>  
> Appears somewhere around 25MB is the threshold where we start to see
> issues - so I'd be interested to know if you have tried bigger
> payloads?
>  
> Thanks, DW
> 
> 
> 
>         -------- Original Message --------
>         Subject: Re: Re-visiting on Hermes 1 performance
>         From: Ladislav Urban <lad...@we...>
>         Date: Fri, June 23, 2006 8:24 pm
>         To: "David RR Webber (XML)" <da...@dr...>
>         Cc: Ashique Tanveer <tan...@od...>, Sacha Schlegel
>         <sa...@sc...>,  Patrick Yee <kc...@ce...>
>         
>         Hi David,
>         I have some questions about the problem.
>         
>         Firstly, How long does take when you run Send method with
>         large payload 
>         on given registered application context?
>         
>         
>         The code in hermes is here
>         
>         try {
>                    responseCode = connection.getResponseCode();
>                    responseMessage = connection.getResponseMessage();
>                } catch (IOException ioe) {
>                    throw new RequestException(ioe.getMessage());
>                }
>         
>         
>         
>         Do you have performance problems during receiving large
>         messages? Do you
>         use encryption and DSigs? 
>         
>         Could you please send me code lines from msh.jar that cause
>         the slow?
>         Is it inside EbxmlMessage.java
>         
>         public void writeTo(
>         OutputStream out,
>         String soapEncoding,
>         String payloadEncoding)
>         throws IOException, SOAPException {
>         // we now keep the SOAP message object away from attachment to
>         avoid
>         // it to load the payload to memory, therefore we are doing
>         our own
>         // writeTo() here
>         //        soapMessage.writeTo(out);
>         serialize(out, soapEncoding, payloadEncoding, false);
>         }
>         
>         As you can see they use custom method 
>         
>         private long serialize(
>         OutputStream out,
>         String soapEncoding,
>         String payloadEncoding,
>         boolean getLengthOnly)
>         
>         to prevent keeping large payloads in memory
>         
>         Instead JAXM's SOAPMessage.writeTo
>         
>         
>         
>         On Thu, 2006-06-22 at 07:04 -0700, David RR Webber (XML)
>         wrote:
>         > Ladislav,
>         >  
>         > OK - here's the saga so far.  We thought that replacing the
>         JAXM and
>         > SAAJ libraries with the very latest ones would resolve the
>         issue with
>         > large payloads.
>         >  
>         > After spending two days setting up and swapping out those
>         libraries -
>         > it made no difference.
>         >  
>         > So now we're thinking that the issue is in how Hermes itself
>         is
>         > packaging the payload and using JAXM calls.
>         >  
>         > Because with Hermes 2 this is not an issue - and in Hermes 2
>         the JAXM
>         > is not present - we're thinking the solution is to re-factor
>         the
>         > Hermes 1 code to use SAAJ directly - just like Hermes 2 is
>         doing.
>         >  
>         > My understanding is that JAXM serializes the payload first -
>         instead
>         > of direct streaming from memory - and over course if the
>         payload is
>         > bigger than the magic 10MB threshold - it does this via disk
>         i/o and
>         > hence it runs 100 times slower!   All this came about I
>         believe
>         > because of the need to support SMTP delivery - but frankly -
>         that is
>         > now history.
>         >  
>         > So - can you give any insights?  Have you examined the code
>         at this
>         > depth - and is there a simple way to change Hermes 1 to use
>         SAAJ
>         > directly?
>         >  
>         > All ideas / code fragments - et al gratefully received!
>         >  
>         > Thanks, DW
>         -- 
>         Ladislav Urban
>         CEO
>         Webswell Inc.
>         1333 Howe Avenue, Suite 100
>         Sacramento, 95825 CA
>         email: lad...@we...
>         phone: +1 (916) 290-2040
>         fax: +1 (916) 921-2850
>         http://www.webswell.com 
-- 
Ladislav Urban
CEO
Webswell Inc.
1333 Howe Avenue, Suite 100
Sacramento, 95825 CA
email: lad...@we...
phone: +1 (916) 290-2040
fax: +1 (916) 921-2850
http://www.webswell.com