]
Dan Berindei commented on ISPN-1808:
------------------------------------
Manik, I don't think we can use FileChannel's locks for our needs. To quote from
the
[
]:
{quote}
File locks are held on behalf of the entire Java virtual machine. They are not suitable
for controlling access to a file by multiple threads within the same virtual machine.
{quote}
FileCacheStore performance issues
---------------------------------
Key: ISPN-1808
URL:
https://issues.jboss.org/browse/ISPN-1808
Project: Infinispan
Issue Type: Enhancement
Components: Loaders and Stores, Marshalling
Affects Versions: 5.1.0.CR4, 5.1.0.FINAL
Reporter: Johann Burkard
Assignee: Dan Berindei
Labels: marshalling, passivation, performance, serialization
Fix For: 5.1.1.FINAL
While InfiniSpan is very fast in-memory, once passivation is turned on, things get slow
for me.
On my i5-2400 with a Crucial C300 SSD, it takes about 11 ms to passivate a 2964 B value.
This comes down to a write speed of 250 to 300 KB/s. The disk can write up to 180 MB/s so
it's not the bottleneck.
Clearly, passivation should be faster than that.
Profiling with YourKit shows most of the hot spots are centered around
{{FileCacheStore}}, the JBoss Marshalling library and various bucket and
{{ImmortalCacheEntry}} methods. Locking also seems to play a role. Here's a
screenshot:
!http://i.imgur.com/LzkPw.png!
To make profiling easier for you, I've taken my test case and turned it into a small
Maven project. Simply running {{mvn install}} should run the test, ready for profiling.
Of course, it could also be that my configuration is suboptimal. However, in my
experiments, many configurations were unusable (hitting the file handle limit), which is
not a good thing.
The project is available at
http://johannburkard.de/resources/Johann/infinispan-performance.zip
I've also found one or two other things I think are more costly than they would need
to be
In {{FileCacheStore}}
{code}
byte[] buffer = new byte[streamBufferSize];
...
fileInStream = new FileInputStream(file);
...
bis = new BufferedInputStream(fileInStream);
...
bytesRead = bis.read(buffer, 0, streamBufferSize);
{code}
wrapping the {{FileInputStream}} in a {{BufferedInputStream}} is unnecessary because you
already have a buffer in {{byte[] buffer}}. I think I have seen this before in InfiniSpan,
so you might want to check for occurrences of {{BufferedInputStream}} or
{{BufferedOutputStream}}.
Another one
{code}
if (bytes.length == 0) {
// Short circuit
if (f.exists()) f.delete();
return;
}
{code}
{{f.exists()}} is essentially a syscall. Just calling {{f.delete()}} is enough.
{code}
if (!root.exists()) {
if (!root.mkdirs()) {
log.problemsCreatingDirectory(root);
}
}
if (!root.exists()) {
throw new ConfigurationException("Directory " + root.getAbsolutePath()
+ " does not exist and cannot be created!");
}
{code}
This could also be shortened to
{code}
if (!root.mkdirs()) {
throw new ConfigurationException("Directory " + root.getAbsolutePath()
+ " does not exist and cannot be created!");
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: