You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Dirk Niededir (JIRA)" <ji...@apache.org> on 2007/04/21 12:24:15 UTC
[jira] Created: (AXIS2-2574) usage of attachments is very slow when
are stored on disk (Server-Side)
usage of attachments is very slow when are stored 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: 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 also works fine but very slow, if the size is greater than sizeThreshold. I know File access shold 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
[jira] Commented: (AXIS2-2574) usage of attachments is very slow
when they are cached on disk (Server-Side)
Posted by "Thilina Gunarathne (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (AXIS2-2574) usage of attachments is very slow when
they are cached on disk (Server-Side)
Posted by "Dirk Niededir (JIRA)" <ji...@apache.org>.
[ 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.
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/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.
> 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.
> 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
[jira] Commented: (AXIS2-2574) usage of attachments is very slow
when they are cached on disk (Server-Side)
Posted by "Thilina Gunarathne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490685 ]
Thilina Gunarathne commented on AXIS2-2574:
-------------------------------------------
We have done many improvements to the performance of the file caching after the 1.1 release ... Please try using the latest axiom binaries...
We even fixed the 1 byte at a time issue too...
I'll also try with buffering the FileOutStream ad will commit it if it gives any more perf improvements...
> 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.
> 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
[jira] Updated: (AXIS2-2574) usage of attachments is very slow when
they are cached on disk (Server-Side)
Posted by "Dirk Niededir (JIRA)" <ji...@apache.org>.
[ 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 also works fine but very slow, if the size is greater than sizeThreshold. I know File access shold 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.
Summary: usage of attachments is very slow when they are cached on disk (Server-Side) (was: usage of attachments is very slow when are stored on disk (Server-Side))
> 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: 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
[jira] Assigned: (AXIS2-2574) usage of attachments is very slow
when they are cached on disk (Server-Side)
Posted by "Thilina Gunarathne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thilina Gunarathne reassigned AXIS2-2574:
-----------------------------------------
Assignee: Thilina Gunarathne
> 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
[jira] Updated: (AXIS2-2574) usage of attachments is very slow when
they are cached on disk (Server-Side)
Posted by "Dirk Niededir (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (AXIS2-2574) usage of attachments is very slow when
they are cached on disk (Server-Side)
Posted by "Dirk Niededir (JIRA)" <ji...@apache.org>.
[ 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-2574) usage of attachments is very slow
when they are cached on disk (Server-Side)
Posted by "Dirk Niedenführ (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491960 ]
Dirk Niedenführ commented on AXIS2-2574:
----------------------------------------
I am not calling the getText-Method. It is not my code. Its between writing the file and the RawXMLINOutMessageReceiver's invokeBusinessLogic. My code starts in invokeBusinessLogic.
I tried to disable the SOAPMonitor but there still is one line of it in the Stack. Ist his the problem?
> 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
[jira] Closed: (AXIS2-2574) usage of attachments is very slow when
they are cached on disk (Server-Side)
Posted by "Dirk Niededir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dirk Niededir closed AXIS2-2574.
--------------------------------
Usage of the AXIOM 1.2.4 within the AXIS 1.1.1 Webapp fixed this Problem.
(My second problem, the OutOfMemory-Error was thrown because of the SOAPMonitor, which was active)
> 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
[jira] Resolved: (AXIS2-2574) usage of attachments is very slow
when they are cached on disk (Server-Side)
Posted by "Dirk Niededir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dirk Niededir resolved AXIS2-2574.
----------------------------------
Resolution: Incomplete
I've updated the AXIOM to 1.4 within the Webapp. The blocksize has changed from 1 byte to 4000. So this is fixed.
But now I get an OutOfMemory-Error after the Axis*.att-File has been written completely to Disk. The Error is thrown before the Method invokeBusinessLogic of my class (RawXMLINOutMessageReceiver) is reached. Whats wrong? The file is about 50MB and "-Xmx=256m"
Stacktrace:
Thread [http-8081-Processor24] (Suspended (exception java.lang.OutOfMemoryError))
org.apache.axiom.om.impl.llom.OMTextImpl.getText() line: 223
org.apache.axiom.om.impl.llom.OMTextImpl.writeOutput(javax.xml.stream.XMLStreamWriter) line: 209
org.apache.axiom.om.impl.llom.OMTextImpl.internalSerializeLocal(javax.xml.stream.XMLStreamWriter) line: 387
org.apache.axiom.om.impl.llom.OMTextImpl.internalSerialize(javax.xml.stream.XMLStreamWriter) line: 197
org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(javax.xml.stream.XMLStreamWriter, boolean) line: 766
org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(javax.xml.stream.XMLStreamWriter) line: 750
org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(javax.xml.stream.XMLStreamWriter, boolean) line: 766
org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(javax.xml.stream.XMLStreamWriter) line: 750
org.apache.axiom.soap.impl.llom.soap11.SOAP11BodyImpl(org.apache.axiom.om.impl.llom.OMElementImpl).internalSerialize(javax.xml.stream.XMLStreamWriter, boolean) line: 766
org.apache.axiom.soap.impl.llom.soap11.SOAP11BodyImpl(org.apache.axiom.om.impl.llom.OMElementImpl).internalSerialize(javax.xml.stream.XMLStreamWriter) line: 750
org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(javax.xml.stream.XMLStreamWriter, boolean) line: 207
org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl(org.apache.axiom.om.impl.llom.OMElementImpl).internalSerialize(javax.xml.stream.XMLStreamWriter) line: 750
org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl(org.apache.axiom.om.impl.llom.OMNodeImpl).serialize(javax.xml.stream.XMLStreamWriter) line: 342
org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl(org.apache.axiom.om.impl.llom.OMElementImpl).toString() line: 907
org.apache.axis2.handlers.soapmonitor.SOAPMonitorHandler.invoke(org.apache.axis2.context.MessageContext) line: 98
org.apache.axis2.engine.Phase.invoke(org.apache.axis2.context.MessageContext) line: 382
org.apache.axis2.engine.AxisEngine.invoke(org.apache.axis2.context.MessageContext) line: 522
org.apache.axis2.engine.AxisEngine.receive(org.apache.axis2.context.MessageContext) line: 487
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(org.apache.axis2.context.MessageContext, java.io.InputStream, java.io.OutputStream, java.lang.String, java.lang.String, java.lang.String) line: 328
org.apache.axis2.transport.http.AxisServlet.doPost(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) line: 254
org.apache.axis2.transport.http.AxisServlet(javax.servlet.http.HttpServlet).service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) line: 710
org.apache.axis2.transport.http.AxisServlet(javax.servlet.http.HttpServlet).service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) line: 803
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse) line: 269
org.apache.catalina.core.ApplicationFilterChain.doFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse) line: 188
org.apache.catalina.core.StandardWrapperValve.invoke(org.apache.catalina.connector.Request, org.apache.catalina.connector.Response) line: 210
org.apache.catalina.core.StandardContextValve.invoke(org.apache.catalina.connector.Request, org.apache.catalina.connector.Response) line: 174
org.apache.catalina.valves.AccessLogValve.invoke(org.apache.catalina.connector.Request, org.apache.catalina.connector.Response) line: 542
org.apache.catalina.core.StandardHostValve.invoke(org.apache.catalina.connector.Request, org.apache.catalina.connector.Response) line: 127
org.apache.catalina.valves.ErrorReportValve.invoke(org.apache.catalina.connector.Request, org.apache.catalina.connector.Response) line: 117
org.apache.catalina.core.StandardEngineValve.invoke(org.apache.catalina.connector.Request, org.apache.catalina.connector.Response) line: 108
org.apache.catalina.connector.CoyoteAdapter.service(org.apache.coyote.Request, org.apache.coyote.Response) line: 151
org.apache.coyote.http11.Http11Processor.process(java.io.InputStream, java.io.OutputStream) line: 870
org.apache.coyote.http11.Http11Protocol$JmxHttp11ConnectionHandler(org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler).processConnection(org.apache.tomcat.util.net.TcpConnection, java.lang.Object[]) line: 665
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(java.net.Socket, org.apache.tomcat.util.net.TcpConnection, java.lang.Object[]) line: 528
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(java.lang.Object[]) line: 81
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run() line: 685
org.apache.tomcat.util.threads.ThreadWithAttributes(java.lang.Thread).run() line: 595
> 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
[jira] Updated: (AXIS2-2574) usage of attachments is very slow when
they are cached on disk (Server-Side)
Posted by "Dirk Niededir (JIRA)" <ji...@apache.org>.
[ 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.
> 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