[
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/default.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.
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.
> 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/default.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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
