[
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.
