Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Message-ID: <18890650.1177153935786.JavaMail.jira@brutus>
Date: Sat, 21 Apr 2007 04:12:15 -0700 (PDT)
From: "Dirk Niededir (JIRA)" <jira@apache.org>
To: axis-dev@ws.apache.org
Subject: [jira] Updated: (AXIS2-2574) usage of attachments is very slow when
 they are cached on disk (Server-Side)
In-Reply-To: <26870049.1177151055553.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Dirk Niededir updated AXIS2-2574:
---------------------------------

    Description: 
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.

I have writte 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.


  was:
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.

I have writte 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.


    Environment: SUN JRE 5.0 Update 11, Apache Tomcat 5.5.23, Windows XP Professional  (was: Apache Tomcat 5.5.23, Windows XP Professional)

> 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
>
> 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.
> I have writte 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