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
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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
