Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Message-ID: <40B5EAA3.9030407@lse.com>
Date: Thu, 27 May 2004 09:18:27 -0400
From: "David D. Lucas" <ddlucas@lse.com>
Organization: Lucas Software Engineering, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a) Gecko/20040415
MIME-Version: 1.0
To: axis-dev@ws.apache.org, tomj@macromedia.com
Subject: Re: Base64 Multithreaded Locks Slow Performance
References: 
 <CB1FF0A474AEA84EA0206D5B05F6A4CB081F1009@S1001EXM02.macromedia.com>
In-Reply-To: 
 <CB1FF0A474AEA84EA0206D5B05F6A4CB081F1009@S1001EXM02.macromedia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Tom,

After spending time in the code I found that the Axis Utils ByteArray is 
using a backing store to write the bytes out to a file for anything over 
8KB. I have posted a bug to JIRA on it and can provide the source code 
if you all want it.  I added properties to be able to tune this.  I also 
set the defaults high enough that this would not be the normal case.

I was puzzled as to why this backing store was done, but I am sure there 
was a reason at one point.  The problem with the ByteArray is actually 
impacting both client and server.  The temp file creation uses a Global 
Mutex internal to Sun's File code.  This means that it effectively 
serializes anything over 8KB.  :-(

So I make the changes and tested on my servers and I saw it double its 
performance capabilities.

I am investigating other performance bottlenecks too, so if I find 
anything else I will pass it on.

Do you want me to attach the code in the JIRA bug ?

Let me know.

Thanks,
Dave


Tom Jordahl wrote:
> Dave,
> 
> I think we would welcome any improvements to the Base64 serializer.
> 
> Perhaps the code indicated why a file is being used?  I am not sure who did
> this implementation.
> 
> --
> Tom Jordahl
> Macromedia Server Development
> 
> -----Original Message-----
> From: David D. Lucas [mailto:ddlucas@lse.com] 
> Sent: Tuesday, May 25, 2004 8:25 PM
> To: axis-dev@ws.apache.org
> Cc: ddlucas@lse.com
> Subject: Re: Base64 Multithreaded Locks Slow Performance
> 
> After further investigation, it appears that Sun is really locking a mutex
> for creating a temporary file at the global level.  I do not understand
> why they need to do that as a static.  Any ideas?  Is this a Sun bug ?
> 
> Why are we using a temporary file as a backing store anyway ?
> If we have to get this thing out as a byte array, don't we still need all
> that memory to handle it ?  So what is the point or am i missing
> something?
> 
> Any help appreciated.
> 
> Thanks,
> Dave
> 

-- 

+------------------------------------------------------------+
| David Lucas                      mailto: ddlucas @ lse.com |
| Lucas Software Engineering, Inc.   (740) 964-6248 Voice    |
| Unix,Java,C++,CORBA,XML,EJB        (614) 668-4020 Mobile   |
| Middleware,Frameworks              (888) 866-4728 Fax/Msg  |
+------------------------------------------------------------+
| GPS Location:  40.0150 deg Lat,  -82.6378 deg Long         |
| IMHC: "Jesus Christ is the way, the truth, and the life."  |
| IMHC: "I know where I am; I know where I'm going."    <><  |
+------------------------------------------------------------+

Notes: PGP Key Block=http://www.lse.com/~ddlucas/pgpblock.txt
IMHO="in my humble opinion" IMHC="in my humble conviction"
All trademarks above are those of their respective owners.