axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thilina Gunarathne (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AXIS2-2574) usage of attachments is very slow when they are cached on disk (Server-Side)
Date Thu, 26 Apr 2007 10:15:15 GMT

    [ https://issues.apache.org/jira/browse/AXIS2-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491950
] 

Thilina Gunarathne commented on AXIS2-2574:
-------------------------------------------

Seems like you are calling the getText method of the Binary OMText object.. This will eventually
force the content to be read in to the memory as the whole content needs to be base64 encoded
inorder to return it as a string...

> usage of attachments is very slow when they are cached on disk (Server-Side)
> ----------------------------------------------------------------------------
>
>                 Key: AXIS2-2574
>                 URL: https://issues.apache.org/jira/browse/AXIS2-2574
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>    Affects Versions: 1.1.1
>         Environment: SUN JRE 5.0 Update 11, Apache Tomcat 5.5.23, Windows XP Professional
>            Reporter: Dirk Niededir
>         Assigned To: Thilina Gunarathne
>
> I have implemented a small AXIOM based Service using the AXIS2 1.1.1 WAR-file.
> I am using the DataHandler to receive big Byte-Arrays (base64binary). Using MTOM, AXIS2
is converting them to attachments. This works fine using small Byte-Arrays. To avoid a OutOfMemoryError,
I enabled the file based cache using the parameters cacheAttachments=true, attachmentDIR=cachedir
and sizeThreshold=30000 in the axis2.conf. This still works fine but very slow, if the size
is greater than sizeThreshold. I know File access should be slower than using RAM. But this
works much slower than it should and the CPU is at maximum. 
> Using the Windows-Tool "Process Monitor" ( http://www.microsoft.com/technet/sysinternals/utilities/processmonitor.mspx
), I saw that the axis*.att files are written in blocks with size=1. This might be a hint.
> For this I have written a small test, which writes a 50MB file to disk either buffered
or unbuffered:
> --------------------------
> 	File file = new File( "C:/java/temp/test.txt");
> 	if( file.exists())
> 		file.delete();
> 	file.createNewFile();
> 	long startTime = System.currentTimeMillis();
> 	
> 	OutputStream fos = new FileOutputStream( file);
> 	boolean buffered = true;
> 	if( buffered)
> 		fos = new BufferedOutputStream( fos);
> 	
> 	int count = 0;
> 	while( count < 50*1000000) {
> 		count++;
> 		fos.write( 'a');
> 	}
> 	fos.close();
> 	
> 	long endTime = System.currentTimeMillis();
> 	
> 	System.out.println("time = "+(endTime-startTime)+"ms");
> --------------------------
> if the buffered-flag is false, then time = 203360ms and CPU ~ 90%
> if the buffered-flag is true,  then time = 2763ms       and CPU ~ 30%
> The buffered version is 73.6 times faster with a much lower CPU utilization!
> This confirms to the hint. So decoration of the FileOutputStream for the axis*.att-Files
with a BufferedOutputStream will fix this "bug". 
> Maybe it is a Windows-Problem, but the decoration will not be a disadvantage for other
systems.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message