axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@apache.org
Subject [jira] Updated: (AXIS-1371) ByteArray causes performance degradation
Date Fri, 28 May 2004 13:20:01 GMT
The following issue has been updated:

    Updater: David Lucas (mailto:ddlucas@lse.com)
       Date: Fri, 28 May 2004 6:19 AM
    Comment:
Okay, last one for today.  I noticed that this needs to be further analyzed due to expanding
buffer behavior.  I tried to make it get smarter over time to see if we can get enough buffer
up front.  I think I improved the numbers more, but I need you to run it on one of your machines.
 Maybe even compare these three (so far :-> ) patches to see which one looks better.

Also, the samples perf test does not give the JVM enough time to optimize code on the client
and server side.  I recommend at least two loops for comparison.  Maybe even look at using
the junitperf for making sure it stays below a certain time threshold.

Let me know which one works best.  If the third one looks better, I need to add another property
to the AxisEngine property or other location you deem fit.  :-)

Thanks,
Dave

    Changes:
             Attachment changed to ByteArray.patch
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://issues.apache.org/jira/browse/AXIS-1371?page=history

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/AXIS-1371

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: AXIS-1371
    Summary: ByteArray causes performance degradation
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Axis
 Components: 
             Basic Architecture
   Versions:
             1.2 Beta

   Assignee: 
   Reporter: David Lucas

    Created: Thu, 27 May 2004 5:39 AM
    Updated: Fri, 28 May 2004 6:19 AM
Environment: Standard client and server messaging using SOAPParts

Description:
ByteArray has a mechanism in it to provide a "file" as a backing store for any arrays that
are larger than 8KB.  In most cases, this is all of my responses.  We are passing images back
as BASE64 and we see major performance hit.  After performaning a thread dump on poorly performing
tests, we found that many threads were blocked in the Sun File.createTempFile method which
has a global mutex that is serializing all of my SOAP responses.

Solution:  Change ByteArray to provide a larger amount of memory usage for RESIDENT SIZE (like
512MB compared to 8KB).  The RESIDENT SIZE is not preallocated, but used to determine when
to turn on backing storage.  I also propose a change to allow control over RESIDENT SIZE,
CACHE INCREMENT, ENABLE/DISABLE BACKING STORE, and a WORKING BUFFER SIZE for when the backing
store is written or read via a stream.

In my internal tests, this change has seen a major improvement on performance.  And seeing
that SOAPParts are used on the client side as well, this might have a dramatic increase performance.
 My tests indicate at a minimum of 50% improvement.   I was able to double my test throughput
after making this change.

I have a working ByteArray coded that includes my changes and I can send it if you want it.



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message