You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Derek Clayton <co...@hotmail.com> on 2007/03/01 04:04:48 UTC
MOTM and Encoding/Decoding
Hello all,
I have written a SOAP client using Axis2 which receives a binary file in the
response. The binary file is attached using MOTM XOP. When I use an http
sniffer to look at the response everything looks good...the response
contains an XOP:Include reference to the attached content. The attached
content in this case is sent as binary but it's just an XML file which I can
visually inspect.
However, when I print out the respsonse with the following code:
OMElement result = servClient.sendReceive(method);
System.out.println(result);
I get this body:
<soap:Body></soap:Envelope>
<PassExcelBinaryResponse
xmlns="http://XXXXXXXX/soap/WebServices.asp"><PassExcelBinaryResult>PD94bWwgdmVyc2lvbj0iMS4wIiBzdGFuZGFsb25lPSJ5ZXMiPz4NCjxOZXdEYXRhU2V0Pg0KICA8eHM6c2NoZW1hIGlkPSJOZXdEYXRhU2V0IiB4bWxucz0iIiB4bWxuczp4cz0iaHR0cDovL3d3d........LOTS
AND LOTS MORE
The size of the attached binary file is 900K. The size of the content in
PassExcelBinaryResult is suspiciously around 30% larger...it looks like
Axis2 (Axiom?) has encoded the attached file.
For reference here is my code to write the attached binary:
OMText binaryNode = (OMText)xmlElement.getFirstOMChild();
DataHandler dh = (DataHandler)binaryNode.getDataHandler();
FileOutputStream out = new FileOutputStream("../../test/data/temp.xml");
dh.writeTo(out);
out.close();
So my question: Is Axis2 encoding the binary attachment merely for display
purposes? Or will it try to encode the binary attachment and then have to
decode it when I write the file.
As mentioned using the above code is working however it is very slow..it is
about 4x slower to read the attachment than an equivalent client written for
.NET. This is what led me to start wondering why it was so slow and seeing
that the content seemed to be encoded after I receive the response.
Thanks,
Derek
_________________________________________________________________
Find out the restaurants participating in Winterlicious
http://local.live.com/default.aspx?v=2&cp=43.658648~-79.383962&style=r&lvl=15&tilt=-90&dir=0&alt=-1000&scene=3702663&cid=7ABE80D1746919B4!1329
>From January 26 to February 8, 2007
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: MTOM Attachments and PushbackInputStream
Posted by Thilina Gunarathne <cs...@gmail.com>.
Hi Derek,
My changes are finally in place.. I need to do a profiling to see
whether they have any good impact on performance...
If possible please drop the latest AXIOM binaries (from the nightly
build or a manual build from Axiom svn head) in to your test scenerio
and see whether if there's an improvment..
Thanks,
Thilina
On 3/7/07, Thilina Gunarathne <cs...@gmail.com> wrote:
> Hi Derek,
> It's great that you started to nail down the attachment performance
> issues.. I've also started to do some refactorings to the Attachments
> handling classes.. I still have some test cases failing., which means
> it'll take some more time to get the changes in..
>
> Let's crack this together :)... I'll also do some profiling to get more clues..
>
> ~Thilina
>
> On 3/7/07, Derek Clayton <co...@hotmail.com> wrote:
> > Hi Davanum
> >
> > Unfortunately, the server is in .NET so I would only be able to provide the
> > client and some other sample data which alone might not be useful.
> >
> > However, I did some research in to the Axis2 and Axiom source using a client
> > that was trying to read a ~1.8M binary attachment (XOP/MTOM). It was taking
> > just over 3 seconds to read in and save the file. I finally tracked down
> > that 98% of the time involved was occuring in the Class:
> >
> > org.apache.axiom.attachments.MIMEBodyPartInputStream specifically in the
> > read() method at the line:
> >
> > // read the next value from stream
> > int value = inStream.read();
> >
> > The inStream is a PushbackInputStream. On a simple isolated test (i.e.
> > plain old java reading from the file system) I tested reading in the file
> > using a BufferedInputStream vs a PushbackInputStream. It took 31 ms for the
> > BufferedInputStream and a whopping 1047 ms for the PushbackInputStream. (I
> > know there are reasons for the use of PushbackInputStream)
> >
> > I thought I had found the reason why it was slow and even in the Axiom
> > source just before it creates the PushbackInputStream it states in the Class
> > org.apache.axiom.attachments.Attachments:
> >
> > // do we need to wrap InputStream from a BufferedInputStream before
> > // wrapping from PushbackStream
> >
> > So I changed the source to first wrap in a BufferedInputStream however there
> > was no change in performance. The immediate Underlying InputStream is a
> > org.apache.commons.httpclient.AutoCloseInputStream and whatever it might
> > wrap (etc) I'm not sure.
> >
> > So basically I'm still not sure about what's going on. PushbackInputStream
> > is definitely a lot slower because it does not do any buffered reads.
> > However, I don't know why the performance wasn't improved when I wrapped it
> > in a BufferedInputStream. I was unable in my investigative time to find out
> > any other InputStreams that might have ultimately been wrapped by the
> > PushbackInputStream.
> >
> > Derek
> >
> >
> > >From: "Davanum Srinivas" <da...@gmail.com>
> > >Reply-To: dims@apache.org
> > >To: axis-user@ws.apache.org
> > >Subject: Re: MOTM and Encoding/Decoding
> > >Date: Thu, 1 Mar 2007 14:07:25 -0500
> > >
> > >Derek,
> > >
> > >Could you please log a JIRA bug and upload the sample code? Let's try
> > >to create the scenario on our boxes...
> > >
> > >thanks,
> > >dims
> > >
> > >On 3/1/07, Derek Clayton <co...@hotmail.com> wrote:
> > >>Thank you for the very fast response.
> > >>
> > >> >If possible please post us some numbers of the time comparison. Make
> > >> >sure to avoid the System.out part when doing the comparison (this
> > >> >encoding takes time :( )...
> > >>
> > >>First let me explain the setup. The two machines are identical
> > >>hardware...Pentium 4 2.8GHz with 1Gig memory. Software differs since
> > >>these
> > >>are two different developer machines.
> > >>
> > >>Machine 1 acts as the client and is written in Java using Axis2. It sends
> > >>an Excel file to Machine 2. When it receives the XML file back (see next
> > >>paragraph) is simply saves it as a file.
> > >>
> > >>Machine 2 acts as the server and is using .NET. It receives an Excel file
> > >>as binary, saves that file, uses an ActiveX control to read in the file
> > >>and
> > >>parse it to generate an XML representation of the data. It then sends
> > >>that
> > >>XML back to the Machine 1 in the SOAP response.
> > >>
> > >>I haven't written an isolated test but this setup would favor Java/Axis2
> > >>anyway since Machine 2 is having to do actual work in addition to reading
> > >>the binary file.
> > >>
> > >>For smaller Excel files the times are quite reasonable.
> > >>
> > >>Test 1
> > >>--------------------------
> > >>For a 302K send and a 922K response.
> > >>
> > >>Time to send and receive response: 1.6 secs.
> > >>Time to read response: 6 secs.
> > >>
> > >>It is taking about 3 times longer which is reasonable since the file size
> > >>is
> > >>3x as large even though the server is doing a lot more work than the
> > >>client.
> > >>
> > >>However, as the files get large the performance begins to break down.
> > >>
> > >>Test 2
> > >>--------------------------
> > >>For a 1.4M send and a 5.4M response.
> > >>
> > >>Time to send and receive response: 3 secs.
> > >>Time to read response: 37 secs.
> > >>
> > >>37 seconds to read the 5.4M binary file seems like a long time. As well
> > >>you
> > >>can see that the server processed a larger file (1.4M) in half the time as
> > >>did the client in Test 1. For even larger files the difference becomes
> > >>greater.
> > >>
> > >>Test 3
> > >>--------------------------
> > >>For a 8.5M and a 32M response.
> > >>
> > >>Time to send and receive response: 18 secs.
> > >>Time to read response: 220 secs.
> > >>
> > >>Here you can see the .NET is reading the 8.5M (along with parsing it and
> > >>generating XML) in 18 secs compared to where Java/Axis2 took 37 secs to
> > >>simply read and save a 5.4M file in Test 2.
> > >>
> > >>I know this is an informal test case. But is 37 seconds to read a 5.4M
> > >>binary attachment with no decoding similar to the experience of others?
> > >>
> > >>Thanks!
> > >>
> > >>Derek
> > >>
> > >>_________________________________________________________________
> > >>Don't waste time standing in line—try shopping online. Visit Sympatico /
> > >>MSN
> > >>Shopping today! http://shopping.sympatico.msn.ca
> > >>
> > >>
> > >>---------------------------------------------------------------------
> > >>To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > >>For additional commands, e-mail: axis-user-help@ws.apache.org
> > >>
> > >>
> > >
> > >
> > >--
> > >Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > >For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> >
> > _________________________________________________________________
> > Your Space. Your Friends. Your Stories. Share your world with Windows Live
> > Spaces. http://spaces.live.com/?mkt=en-ca
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
>
> --
> Thilina Gunarathne
> WSO2, Inc.; http://www.wso2.com/
> Home page: http://webservices.apache.org/~thilina/
> Blog: http://thilinag.blogspot.com/
>
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: MTOM Attachments and PushbackInputStream
Posted by Thilina Gunarathne <cs...@gmail.com>.
Hi Derek,
It's great that you started to nail down the attachment performance
issues.. I've also started to do some refactorings to the Attachments
handling classes.. I still have some test cases failing., which means
it'll take some more time to get the changes in..
Let's crack this together :)... I'll also do some profiling to get more clues..
~Thilina
On 3/7/07, Derek Clayton <co...@hotmail.com> wrote:
> Hi Davanum
>
> Unfortunately, the server is in .NET so I would only be able to provide the
> client and some other sample data which alone might not be useful.
>
> However, I did some research in to the Axis2 and Axiom source using a client
> that was trying to read a ~1.8M binary attachment (XOP/MTOM). It was taking
> just over 3 seconds to read in and save the file. I finally tracked down
> that 98% of the time involved was occuring in the Class:
>
> org.apache.axiom.attachments.MIMEBodyPartInputStream specifically in the
> read() method at the line:
>
> // read the next value from stream
> int value = inStream.read();
>
> The inStream is a PushbackInputStream. On a simple isolated test (i.e.
> plain old java reading from the file system) I tested reading in the file
> using a BufferedInputStream vs a PushbackInputStream. It took 31 ms for the
> BufferedInputStream and a whopping 1047 ms for the PushbackInputStream. (I
> know there are reasons for the use of PushbackInputStream)
>
> I thought I had found the reason why it was slow and even in the Axiom
> source just before it creates the PushbackInputStream it states in the Class
> org.apache.axiom.attachments.Attachments:
>
> // do we need to wrap InputStream from a BufferedInputStream before
> // wrapping from PushbackStream
>
> So I changed the source to first wrap in a BufferedInputStream however there
> was no change in performance. The immediate Underlying InputStream is a
> org.apache.commons.httpclient.AutoCloseInputStream and whatever it might
> wrap (etc) I'm not sure.
>
> So basically I'm still not sure about what's going on. PushbackInputStream
> is definitely a lot slower because it does not do any buffered reads.
> However, I don't know why the performance wasn't improved when I wrapped it
> in a BufferedInputStream. I was unable in my investigative time to find out
> any other InputStreams that might have ultimately been wrapped by the
> PushbackInputStream.
>
> Derek
>
>
> >From: "Davanum Srinivas" <da...@gmail.com>
> >Reply-To: dims@apache.org
> >To: axis-user@ws.apache.org
> >Subject: Re: MOTM and Encoding/Decoding
> >Date: Thu, 1 Mar 2007 14:07:25 -0500
> >
> >Derek,
> >
> >Could you please log a JIRA bug and upload the sample code? Let's try
> >to create the scenario on our boxes...
> >
> >thanks,
> >dims
> >
> >On 3/1/07, Derek Clayton <co...@hotmail.com> wrote:
> >>Thank you for the very fast response.
> >>
> >> >If possible please post us some numbers of the time comparison. Make
> >> >sure to avoid the System.out part when doing the comparison (this
> >> >encoding takes time :( )...
> >>
> >>First let me explain the setup. The two machines are identical
> >>hardware...Pentium 4 2.8GHz with 1Gig memory. Software differs since
> >>these
> >>are two different developer machines.
> >>
> >>Machine 1 acts as the client and is written in Java using Axis2. It sends
> >>an Excel file to Machine 2. When it receives the XML file back (see next
> >>paragraph) is simply saves it as a file.
> >>
> >>Machine 2 acts as the server and is using .NET. It receives an Excel file
> >>as binary, saves that file, uses an ActiveX control to read in the file
> >>and
> >>parse it to generate an XML representation of the data. It then sends
> >>that
> >>XML back to the Machine 1 in the SOAP response.
> >>
> >>I haven't written an isolated test but this setup would favor Java/Axis2
> >>anyway since Machine 2 is having to do actual work in addition to reading
> >>the binary file.
> >>
> >>For smaller Excel files the times are quite reasonable.
> >>
> >>Test 1
> >>--------------------------
> >>For a 302K send and a 922K response.
> >>
> >>Time to send and receive response: 1.6 secs.
> >>Time to read response: 6 secs.
> >>
> >>It is taking about 3 times longer which is reasonable since the file size
> >>is
> >>3x as large even though the server is doing a lot more work than the
> >>client.
> >>
> >>However, as the files get large the performance begins to break down.
> >>
> >>Test 2
> >>--------------------------
> >>For a 1.4M send and a 5.4M response.
> >>
> >>Time to send and receive response: 3 secs.
> >>Time to read response: 37 secs.
> >>
> >>37 seconds to read the 5.4M binary file seems like a long time. As well
> >>you
> >>can see that the server processed a larger file (1.4M) in half the time as
> >>did the client in Test 1. For even larger files the difference becomes
> >>greater.
> >>
> >>Test 3
> >>--------------------------
> >>For a 8.5M and a 32M response.
> >>
> >>Time to send and receive response: 18 secs.
> >>Time to read response: 220 secs.
> >>
> >>Here you can see the .NET is reading the 8.5M (along with parsing it and
> >>generating XML) in 18 secs compared to where Java/Axis2 took 37 secs to
> >>simply read and save a 5.4M file in Test 2.
> >>
> >>I know this is an informal test case. But is 37 seconds to read a 5.4M
> >>binary attachment with no decoding similar to the experience of others?
> >>
> >>Thanks!
> >>
> >>Derek
> >>
> >>_________________________________________________________________
> >>Don't waste time standing in line—try shopping online. Visit Sympatico /
> >>MSN
> >>Shopping today! http://shopping.sympatico.msn.ca
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >>For additional commands, e-mail: axis-user-help@ws.apache.org
> >>
> >>
> >
> >
> >--
> >Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >For additional commands, e-mail: axis-user-help@ws.apache.org
> >
>
> _________________________________________________________________
> Your Space. Your Friends. Your Stories. Share your world with Windows Live
> Spaces. http://spaces.live.com/?mkt=en-ca
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: MTOM Attachments and PushbackInputStream
Posted by Derek Clayton <co...@hotmail.com>.
Hi Davanum
Unfortunately, the server is in .NET so I would only be able to provide the
client and some other sample data which alone might not be useful.
However, I did some research in to the Axis2 and Axiom source using a client
that was trying to read a ~1.8M binary attachment (XOP/MTOM). It was taking
just over 3 seconds to read in and save the file. I finally tracked down
that 98% of the time involved was occuring in the Class:
org.apache.axiom.attachments.MIMEBodyPartInputStream specifically in the
read() method at the line:
// read the next value from stream
int value = inStream.read();
The inStream is a PushbackInputStream. On a simple isolated test (i.e.
plain old java reading from the file system) I tested reading in the file
using a BufferedInputStream vs a PushbackInputStream. It took 31 ms for the
BufferedInputStream and a whopping 1047 ms for the PushbackInputStream. (I
know there are reasons for the use of PushbackInputStream)
I thought I had found the reason why it was slow and even in the Axiom
source just before it creates the PushbackInputStream it states in the Class
org.apache.axiom.attachments.Attachments:
// do we need to wrap InputStream from a BufferedInputStream before
// wrapping from PushbackStream
So I changed the source to first wrap in a BufferedInputStream however there
was no change in performance. The immediate Underlying InputStream is a
org.apache.commons.httpclient.AutoCloseInputStream and whatever it might
wrap (etc) I'm not sure.
So basically I'm still not sure about what's going on. PushbackInputStream
is definitely a lot slower because it does not do any buffered reads.
However, I don't know why the performance wasn't improved when I wrapped it
in a BufferedInputStream. I was unable in my investigative time to find out
any other InputStreams that might have ultimately been wrapped by the
PushbackInputStream.
Derek
>From: "Davanum Srinivas" <da...@gmail.com>
>Reply-To: dims@apache.org
>To: axis-user@ws.apache.org
>Subject: Re: MOTM and Encoding/Decoding
>Date: Thu, 1 Mar 2007 14:07:25 -0500
>
>Derek,
>
>Could you please log a JIRA bug and upload the sample code? Let's try
>to create the scenario on our boxes...
>
>thanks,
>dims
>
>On 3/1/07, Derek Clayton <co...@hotmail.com> wrote:
>>Thank you for the very fast response.
>>
>> >If possible please post us some numbers of the time comparison. Make
>> >sure to avoid the System.out part when doing the comparison (this
>> >encoding takes time :( )...
>>
>>First let me explain the setup. The two machines are identical
>>hardware...Pentium 4 2.8GHz with 1Gig memory. Software differs since
>>these
>>are two different developer machines.
>>
>>Machine 1 acts as the client and is written in Java using Axis2. It sends
>>an Excel file to Machine 2. When it receives the XML file back (see next
>>paragraph) is simply saves it as a file.
>>
>>Machine 2 acts as the server and is using .NET. It receives an Excel file
>>as binary, saves that file, uses an ActiveX control to read in the file
>>and
>>parse it to generate an XML representation of the data. It then sends
>>that
>>XML back to the Machine 1 in the SOAP response.
>>
>>I haven't written an isolated test but this setup would favor Java/Axis2
>>anyway since Machine 2 is having to do actual work in addition to reading
>>the binary file.
>>
>>For smaller Excel files the times are quite reasonable.
>>
>>Test 1
>>--------------------------
>>For a 302K send and a 922K response.
>>
>>Time to send and receive response: 1.6 secs.
>>Time to read response: 6 secs.
>>
>>It is taking about 3 times longer which is reasonable since the file size
>>is
>>3x as large even though the server is doing a lot more work than the
>>client.
>>
>>However, as the files get large the performance begins to break down.
>>
>>Test 2
>>--------------------------
>>For a 1.4M send and a 5.4M response.
>>
>>Time to send and receive response: 3 secs.
>>Time to read response: 37 secs.
>>
>>37 seconds to read the 5.4M binary file seems like a long time. As well
>>you
>>can see that the server processed a larger file (1.4M) in half the time as
>>did the client in Test 1. For even larger files the difference becomes
>>greater.
>>
>>Test 3
>>--------------------------
>>For a 8.5M and a 32M response.
>>
>>Time to send and receive response: 18 secs.
>>Time to read response: 220 secs.
>>
>>Here you can see the .NET is reading the 8.5M (along with parsing it and
>>generating XML) in 18 secs compared to where Java/Axis2 took 37 secs to
>>simply read and save a 5.4M file in Test 2.
>>
>>I know this is an informal test case. But is 37 seconds to read a 5.4M
>>binary attachment with no decoding similar to the experience of others?
>>
>>Thanks!
>>
>>Derek
>>
>>_________________________________________________________________
>>Don't waste time standing in linetry shopping online. Visit Sympatico /
>>MSN
>>Shopping today! http://shopping.sympatico.msn.ca
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
>--
>Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>For additional commands, e-mail: axis-user-help@ws.apache.org
>
_________________________________________________________________
Your Space. Your Friends. Your Stories. Share your world with Windows Live
Spaces. http://spaces.live.com/?mkt=en-ca
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: MOTM and Encoding/Decoding
Posted by Davanum Srinivas <da...@gmail.com>.
Derek,
Could you please log a JIRA bug and upload the sample code? Let's try
to create the scenario on our boxes...
thanks,
dims
On 3/1/07, Derek Clayton <co...@hotmail.com> wrote:
> Thank you for the very fast response.
>
> >If possible please post us some numbers of the time comparison. Make
> >sure to avoid the System.out part when doing the comparison (this
> >encoding takes time :( )...
>
> First let me explain the setup. The two machines are identical
> hardware...Pentium 4 2.8GHz with 1Gig memory. Software differs since these
> are two different developer machines.
>
> Machine 1 acts as the client and is written in Java using Axis2. It sends
> an Excel file to Machine 2. When it receives the XML file back (see next
> paragraph) is simply saves it as a file.
>
> Machine 2 acts as the server and is using .NET. It receives an Excel file
> as binary, saves that file, uses an ActiveX control to read in the file and
> parse it to generate an XML representation of the data. It then sends that
> XML back to the Machine 1 in the SOAP response.
>
> I haven't written an isolated test but this setup would favor Java/Axis2
> anyway since Machine 2 is having to do actual work in addition to reading
> the binary file.
>
> For smaller Excel files the times are quite reasonable.
>
> Test 1
> --------------------------
> For a 302K send and a 922K response.
>
> Time to send and receive response: 1.6 secs.
> Time to read response: 6 secs.
>
> It is taking about 3 times longer which is reasonable since the file size is
> 3x as large even though the server is doing a lot more work than the client.
>
> However, as the files get large the performance begins to break down.
>
> Test 2
> --------------------------
> For a 1.4M send and a 5.4M response.
>
> Time to send and receive response: 3 secs.
> Time to read response: 37 secs.
>
> 37 seconds to read the 5.4M binary file seems like a long time. As well you
> can see that the server processed a larger file (1.4M) in half the time as
> did the client in Test 1. For even larger files the difference becomes
> greater.
>
> Test 3
> --------------------------
> For a 8.5M and a 32M response.
>
> Time to send and receive response: 18 secs.
> Time to read response: 220 secs.
>
> Here you can see the .NET is reading the 8.5M (along with parsing it and
> generating XML) in 18 secs compared to where Java/Axis2 took 37 secs to
> simply read and save a 5.4M file in Test 2.
>
> I know this is an informal test case. But is 37 seconds to read a 5.4M
> binary attachment with no decoding similar to the experience of others?
>
> Thanks!
>
> Derek
>
> _________________________________________________________________
> Don't waste time standing in line—try shopping online. Visit Sympatico / MSN
> Shopping today! http://shopping.sympatico.msn.ca
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: MOTM and Encoding/Decoding
Posted by Derek Clayton <co...@hotmail.com>.
Thank you for the very fast response.
>If possible please post us some numbers of the time comparison. Make
>sure to avoid the System.out part when doing the comparison (this
>encoding takes time :( )...
First let me explain the setup. The two machines are identical
hardware...Pentium 4 2.8GHz with 1Gig memory. Software differs since these
are two different developer machines.
Machine 1 acts as the client and is written in Java using Axis2. It sends
an Excel file to Machine 2. When it receives the XML file back (see next
paragraph) is simply saves it as a file.
Machine 2 acts as the server and is using .NET. It receives an Excel file
as binary, saves that file, uses an ActiveX control to read in the file and
parse it to generate an XML representation of the data. It then sends that
XML back to the Machine 1 in the SOAP response.
I haven't written an isolated test but this setup would favor Java/Axis2
anyway since Machine 2 is having to do actual work in addition to reading
the binary file.
For smaller Excel files the times are quite reasonable.
Test 1
--------------------------
For a 302K send and a 922K response.
Time to send and receive response: 1.6 secs.
Time to read response: 6 secs.
It is taking about 3 times longer which is reasonable since the file size is
3x as large even though the server is doing a lot more work than the client.
However, as the files get large the performance begins to break down.
Test 2
--------------------------
For a 1.4M send and a 5.4M response.
Time to send and receive response: 3 secs.
Time to read response: 37 secs.
37 seconds to read the 5.4M binary file seems like a long time. As well you
can see that the server processed a larger file (1.4M) in half the time as
did the client in Test 1. For even larger files the difference becomes
greater.
Test 3
--------------------------
For a 8.5M and a 32M response.
Time to send and receive response: 18 secs.
Time to read response: 220 secs.
Here you can see the .NET is reading the 8.5M (along with parsing it and
generating XML) in 18 secs compared to where Java/Axis2 took 37 secs to
simply read and save a 5.4M file in Test 2.
I know this is an informal test case. But is 37 seconds to read a 5.4M
binary attachment with no decoding similar to the experience of others?
Thanks!
Derek
_________________________________________________________________
Dont waste time standing in linetry shopping online. Visit Sympatico / MSN
Shopping today! http://shopping.sympatico.msn.ca
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: MOTM and Encoding/Decoding
Posted by Thilina Gunarathne <cs...@gmail.com>.
Hi,
> OMElement result = servClient.sendReceive(method);
> System.out.println(result);
>
> I get this body:
>
> <soap:Body></soap:Envelope>
> <PassExcelBinaryResponse
> xmlns="http://XXXXXXXX/soap/WebServices.asp"><PassExcelBinaryResult>PD94bWwgdmVyc2lvbj0iMS4wIiBzdGFuZGFsb25lPSJ5ZXMiPz4NCjxOZXdEYXRhU2V0Pg0KICA8eHM6c2NoZW1hIGlkPSJOZXdEYXRhU2V0IiB4bWxucz0iIiB4bWxuczp4cz0iaHR0cDovL3d3d........LOTS
> AND LOTS MORE
>
> The size of the attached binary file is 900K. The size of the content in
> PassExcelBinaryResult is suspiciously around 30% larger...it looks like
> Axis2 (Axiom?) has encoded the attached file.
Yes..When asking for the Text value, axiom does an base64 encoding to
the binary data. Unless the data remains as Binary..
> For reference here is my code to write the attached binary:
>
> OMText binaryNode = (OMText)xmlElement.getFirstOMChild();
> DataHandler dh = (DataHandler)binaryNode.getDataHandler();
> FileOutputStream out = new FileOutputStream("../../test/data/temp.xml");
> dh.writeTo(out);
> out.close();
>
> So my question: Is Axis2 encoding the binary attachment merely for display
> purposes? Or will it try to encode the binary attachment and then have to
> decode it when I write the file.
Only for the display purposes.. It won't undergo any encoding/decoding
if you are writing directly to a file..
>
> As mentioned using the above code is working however it is very slow..it is
> about 4x slower to read the attachment than an equivalent client written for
> .NET. This is what led me to start wondering why it was so slow and seeing
> that the content seemed to be encoded after I receive the response.
If possible please post us some numbers of the time comparison. Make
sure to avoid the System.out part when doing the comparison (this
encoding takes time :( )...
Thanks,
Thilina
>
> Thanks,
>
> Derek
>
> _________________________________________________________________
> Find out the restaurants participating in Winterlicious
> http://local.live.com/default.aspx?v=2&cp=43.658648~-79.383962&style=r&lvl=15&tilt=-90&dir=0&alt=-1000&scene=3702663&cid=7ABE80D1746919B4!1329
> From January 26 to February 8, 2007
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org