[
https://issues.apache.org/jira/browse/WICKET-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antti S. Lankila updated WICKET-3788:
-------------------------------------
Description:
I benchmarked the FileChannelPool, which is used in the pagemanager's
DiskStore, against a simple unpooled 'new RandomAccessFile(name,
"rw").getChannel()' implementation. The filechannelpool caches 50 handles by
default to 50 session diskstore files, and keeps these handles open as long as
possible or necessary.
The benchmark results are performed from 1 to 7 threads and with active file
set size varied. I tested 10, 50, 60 and 100 active files. To understand the
results, FCP stands for the time spent on wicket's FileChannelPool. FC stands
for time spent on unpooled FileChannel.
The times are the time it took to perform 100000 per thread of the following:
- open a randomly chosen file from set of active files
- read a randomly positioned 10k chunk of a simulated session file that is
100000 bytes long (seek to 0 .. 90000 and then read 10000 bytes)
- close file
Results for 10 files:
FCP: 75 146 311 448 741 1177 1296 ms
FC: 539 682 895 951 1232 1281 1379 ms
Results for 50 files:
FCP: 95 172 295 587 1126 1214 970 ms
FC: 531 639 807 941 1183 1286 1397 ms
Results for 60 files:
FCP: 213 931 2598 3748 4664 5652 5860 ms
FC: 547 663 1011 1105 1268 1370 1491 ms
Results for 100 files:
FCP: 500 3073 6148 8433 10153 11870 13496 ms
FC: 543 653 902 1120 1251 1364 1471 ms
Discussion of the results: it appears that there is little difference in
performance on the unpooled file channel for any active set size. This is not
unexpected: there are no synchronization points and the kernel doesn't much
care either because all these files together only took 100 * 100k of memory, or
about 10 MB -- easily cached in entirely in my 4 GB. However, the
FileChannelPool shows significant performance degradation as soon as the active
set exceeds the pool's size. It seems to perform order of magnitude worse with
100 files as opposed to 50, indicating that wicket websites may suffer rapid
performance degradation under load.
It may be possible to mitigate FileChannelPool's performance regression, but
considering that the performance figures for either implementation are
comparable for the 5 .. 8 threads case, it seems to me that FileChannelPool is
probably not worth it. FileChannelPool's key problem is that it optimizes
performance for the lightly loaded case, and actively harms performance when
load gets higher. For this reason, I propose removing it entirely.
was:
I benchmarked the FileChannelPool, which is used in the pagemanager's
DiskStore, against a simple unpooled 'new RandomAccessFile(name,
"rw").getChannel()' implementation. The filechannelpool caches 50 handles by
default to 50 session diskstore files, and keeps these handles open as long as
possible or necessary.
The benchmark results are performed from 1 to 7 threads and with active file
set size varied. I tested 10, 50, 60 and 100 active files. To understand the
results, FCP stands for the time spent on wicket's FileChannelPool. FC stands
for time spent on unpooled FileChannel.
The times are the time it took to perform 100000 per thread of the following:
- open a randomly chosen file from set of active files
- read a randomly positioned 10k chunk of a simulated session file that is
100000 bytes long (seek to 0 .. 90000 and then read 10000 bytes)
- close file
Results for 10 files:
FCP: 75 146 311 448 741 1177 1296 ms
FC: 539 682 895 951 1232 1281 1379 ms
Results for 50 files:
FCP: 95 172 295 587 1126 1214 970 ms
FC: 531 639 807 941 1183 1286 1397 ms
Results for 60 files:
FCP: 213 931 2598 3748 4664 5652 5860 ms
FC: 547 663 1011 1105 1268 1370 1491 ms
Results for 100 files:
FCP: 500 3073 6148 8433 10153 11870 13496 ms
FC: 543 653 902 1120 1251 1364 1471 ms
Discussion of the results: it appears that there is little difference in
performance on the unpooled file channel for any active set size. This is not
unexpected: there are no synchronization points and the kernel doesn't much
care either because all these files together only took 100 * 100k of memory, or
about 10 MB -- easily cached in entirely in my 4 GB. However, the
FileChannelPool shows significant performance degradation as soon as the active
set exceeds the channel's size. It seems to perform order of magnitude worse
with 100 files as opposed to 50, indicating that wicket websites may suffer
rapid performance degradation under load.
It may be possible to mitigate FileChannelPool's performance regression, but
considering that the performance figures for either implementation are
comparable for the 5 .. 8 threads case, it seems to me that FileChannelPool is
probably not worth it. FileChannelPool's key problem is that it optimizes
performance for the lightly loaded case, and actively harms performance when
load gets higher. For this reason, I propose removing it entirely.
> wicket FileChannelPool has scalability issues
> ---------------------------------------------
>
> Key: WICKET-3788
> URL: https://issues.apache.org/jira/browse/WICKET-3788
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-core
> Affects Versions: 1.5-RC4
> Environment: Linux + i7 CPU + 4 GB RAM
> Reporter: Antti S. Lankila
> Labels: performance, scalability
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I benchmarked the FileChannelPool, which is used in the pagemanager's
> DiskStore, against a simple unpooled 'new RandomAccessFile(name,
> "rw").getChannel()' implementation. The filechannelpool caches 50 handles by
> default to 50 session diskstore files, and keeps these handles open as long
> as possible or necessary.
> The benchmark results are performed from 1 to 7 threads and with active file
> set size varied. I tested 10, 50, 60 and 100 active files. To understand the
> results, FCP stands for the time spent on wicket's FileChannelPool. FC stands
> for time spent on unpooled FileChannel.
> The times are the time it took to perform 100000 per thread of the following:
> - open a randomly chosen file from set of active files
> - read a randomly positioned 10k chunk of a simulated session file that is
> 100000 bytes long (seek to 0 .. 90000 and then read 10000 bytes)
> - close file
> Results for 10 files:
> FCP: 75 146 311 448 741 1177 1296 ms
> FC: 539 682 895 951 1232 1281 1379 ms
> Results for 50 files:
> FCP: 95 172 295 587 1126 1214 970 ms
> FC: 531 639 807 941 1183 1286 1397 ms
> Results for 60 files:
> FCP: 213 931 2598 3748 4664 5652 5860 ms
> FC: 547 663 1011 1105 1268 1370 1491 ms
> Results for 100 files:
> FCP: 500 3073 6148 8433 10153 11870 13496 ms
> FC: 543 653 902 1120 1251 1364 1471 ms
> Discussion of the results: it appears that there is little difference in
> performance on the unpooled file channel for any active set size. This is not
> unexpected: there are no synchronization points and the kernel doesn't much
> care either because all these files together only took 100 * 100k of memory,
> or about 10 MB -- easily cached in entirely in my 4 GB. However, the
> FileChannelPool shows significant performance degradation as soon as the
> active set exceeds the pool's size. It seems to perform order of magnitude
> worse with 100 files as opposed to 50, indicating that wicket websites may
> suffer rapid performance degradation under load.
> It may be possible to mitigate FileChannelPool's performance regression, but
> considering that the performance figures for either implementation are
> comparable for the 5 .. 8 threads case, it seems to me that FileChannelPool
> is probably not worth it. FileChannelPool's key problem is that it optimizes
> performance for the lightly loaded case, and actively harms performance when
> load gets higher. For this reason, I propose removing it entirely.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
