You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Rich Scheuerle (JIRA)" <ji...@apache.org> on 2008/05/22 17:25:55 UTC

[jira] Created: (WSCOMMONS-349) Improved Large Attachment Performance

Improved Large Attachment Performance
-------------------------------------

                 Key: WSCOMMONS-349
                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-349
             Project: WS-Commons
          Issue Type: Improvement
          Components: AXIOM
            Reporter: Rich Scheuerle
            Assignee: Rich Scheuerle


Tim Hefele (IBM) has been running tests on the performance of large attachments.
Using this profile data, Tim and I have made several localized improvements to the 
attachment processing. 

Summary of Changes:

1) Larger Threshold Toleration

   Currently a user can specify (via Axis config) a file threshold for attachments.
   If an attachment is larger than the threshold, the attachment is stored in a backing 
   file.  This improves the memory footprint but can degrade performance.

   This code has been improved.  Now users can supply a much larger attachment threshold.
   The axiom PartFactory will automatically reduce the threshold if it appears that the
   Runtime is low on memory.  This allows users to choose a much higher
   threshold and get better performance throughput.

2) PartFactory.createPart Synchronization

   The createPart method is used to create an attachment part from the input stream.  In 
   normal operation, this input stream is an HTTP InputStream and the message is (assumed) chunked.
   If too many threads are allowed to operate in this section of the code, there tends to be
   a lot of thrashing.  By reducing the number of operating threads, the total throughput of 
   the system seems to increase.

3) Improved BAAInputStream and BAAOutputStream

   The BAAInputStream is like a ByteArrayInputStream except that the content is an array of 
   byte arrays.  Likewise for BAAOutputStream.
   
   The BAAInputStream now has a writeTo(OutputStream) method.  This allows the Axiom layer
   to directly write out the stream without additional buffer copies.

   In addition, the BAAOutputStream now has a receive(InputStream) method.  This allows the 
   BAAOutputStream to be built directly from an InputStream without excessive buffer copies.

4) Upgraded the BufferUtils code to take advantage of (3)

5) Added a verification test

Kudos to Tim Hefele, David Strite and Nikhil Thaker for their efforts on this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (WSCOMMONS-349) Improved Large Attachment Performance

Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WSCOMMONS-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rich Scheuerle resolved WSCOMMONS-349.
--------------------------------------

    Resolution: Fixed

> Improved Large Attachment Performance
> -------------------------------------
>
>                 Key: WSCOMMONS-349
>                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-349
>             Project: WS-Commons
>          Issue Type: Improvement
>          Components: AXIOM
>            Reporter: Rich Scheuerle
>            Assignee: Rich Scheuerle
>
> Tim Hefele (IBM) has been running tests on the performance of large attachments.
> Using this profile data, Tim and I have made several localized improvements to the 
> attachment processing. 
> Summary of Changes:
> 1) Larger Threshold Toleration
>    Currently a user can specify (via Axis config) a file threshold for attachments.
>    If an attachment is larger than the threshold, the attachment is stored in a backing 
>    file.  This improves the memory footprint but can degrade performance.
>    This code has been improved.  Now users can supply a much larger attachment threshold.
>    The axiom PartFactory will automatically reduce the threshold if it appears that the
>    Runtime is low on memory.  This allows users to choose a much higher
>    threshold and get better performance throughput.
> 2) PartFactory.createPart Synchronization
>    The createPart method is used to create an attachment part from the input stream.  In 
>    normal operation, this input stream is an HTTP InputStream and the message is (assumed) chunked.
>    If too many threads are allowed to operate in this section of the code, there tends to be
>    a lot of thrashing.  By reducing the number of operating threads, the total throughput of 
>    the system seems to increase.
> 3) Improved BAAInputStream and BAAOutputStream
>    The BAAInputStream is like a ByteArrayInputStream except that the content is an array of 
>    byte arrays.  Likewise for BAAOutputStream.
>    
>    The BAAInputStream now has a writeTo(OutputStream) method.  This allows the Axiom layer
>    to directly write out the stream without additional buffer copies.
>    In addition, the BAAOutputStream now has a receive(InputStream) method.  This allows the 
>    BAAOutputStream to be built directly from an InputStream without excessive buffer copies.
> 4) Upgraded the BufferUtils code to take advantage of (3)
> 5) Added a verification test
> Kudos to Tim Hefele, David Strite and Nikhil Thaker for their efforts on this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.