Public/winfsp
1
0
Fork 0
mirror of https://github.com/winfsp/winfsp.git synced 2025-04-22 08:23:05 -05:00
Code Issues Packages Projects Releases Wiki Activity

doc: perf-tests: typos

Browse Source
This commit is contained in:
Bill Zissimopoulos 2016-11-30 09:43:10 -08:00
parent 595a77bd2e
commit 7769a2c062
1 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
doc/perf-tests.adoc
View File

@ -32,16 +32,16 @@ Fsbench currently includes the following tests:
=== NTFS
The comparison to NTFS is very important to establish a baseline. It is also very misleading because NTFS is a disk file system and MEMFS (either the WinFsp or Dokany) variants is an in memory file system. The tests will show that MEMFS is faster than NTFS. This should not be taken to mean that we are trying to make a bogus claim that an in memory file system is faster than a disk file system, but to show that the approach of writing a file system in user mode is a valid proposition and can be efficient.
The comparison to NTFS is very important to establish a baseline. It is also very misleading because NTFS is a disk file system and MEMFS (either the WinFsp or Dokany variants) is an in memory file system. The tests will show that MEMFS is faster than NTFS. This should not be taken to mean that we are trying to make the (obvious) claim that an in memory file system is faster than a disk file system, but to show that the approach of writing a file system in user mode is a valid proposition and can be efficient.
=== WinFsp/MEMFS
MEMFS is the sample file system used to test WinFsp and shipped bundled with WinFsp in the WinFsp installer. MEMFS is a simple in memory file system and as such very fast under most conditions. This is desirable because our goal with performance testing is to measure the speed of the WinFsp FSD and DLL rather the performance of a complex user mode file system. MEMFS has minimal overhead and as such is ideal for this purpose.
MEMFS is the file system used to test WinFsp and shipped as a sample bundled with the WinFsp installer. MEMFS is a simple in memory file system and as such is very fast under most conditions. This is desirable because our goal with this performance testing is to measure the speed of the WinFsp system components rather the performance of a complex user mode file system. MEMFS has minimal overhead and is ideal for this purpose.
WinFsp/MEMFS can be run in different configurations, which enable or disable WinFsp caching features. The tested configurations were:
- An infinite FileInfoTimeout, which enables caching of metadata and data
- A FileInfoTimeout of 1s, which enables caching of metadata but disables caching of data.
- A FileInfoTimeout of 1s (second), which enables caching of metadata but disables caching of data.
- A FileInfoTimeout of 0, which completely disables caching.
The WinFsp git commit at the time of testing was 7bdca634aaf503e12b4442e42554449756771a6d.
@ -56,7 +56,7 @@ The Dokany version used for testing was 1.0.1.
== Test Environment
Tests were performed on an idle computer/VM. There was a reboot of both the computer and VM before each file system test run. Each test was run twice and the smaller time value chosen. The assumption is that even in a seemingly idle desktop system there is some activity which will affect the results; the smaller value is the preferred one to use because it reflects the time when there is less or no other activity.
Tests were performed on an idle computer/VM. There was a reboot of both the computer and VM before each file system was tested. Each test was run twice and the smaller time value chosen. The assumption is that even in a seemingly idle desktop system there is some activity which will affect the results; the smaller value is the preferred one to use because it reflects the time when there is less or no other activity.
The test environment was as follows:
----
@ -77,7 +77,7 @@ Windows 10 (64-bit) Version 1511 (OS Build 10586.420)
=== file_create_test
This test measures the performance of CreateFileW(CREATE_NEW)/CloseHandle or equivalently the IRP sequence IRP_MJ_CREATE/FILE_CREATE, IRP_MJ_CLEANUP, IRP_MJ_CLOSE.
This test measures the performance of CreateFileW(CREATE_NEW)/CloseHandle or equivalently the IRP sequence IRP_MJ_CREATE(FILE_CREATE), IRP_MJ_CLEANUP, IRP_MJ_CLOSE.
Dokany seems to perform rather badly in this test. NTFS is better (the spike when the file count is 4000 is likely due to some other system activity), but it has of course to also update disk data structures, which takes time. WinFsp has very good performance in all cases, with the best performance when a non-0 FileInfoTimeout is used.
@ -86,7 +86,7 @@ ifdef::env-github[image::perf-tests/file_create_test.png[]]
=== file_open_test
This test measures the performance of CreateFileW(OPEN_EXISTING) or equivalently the IRP sequence IRP_MJ_CREATE/FILE_OPEN, IRP_MJ_CLEANUP, IRP_MJ_CLOSE.
This test measures the performance of CreateFileW(OPEN_EXISTING) or equivalently the IRP sequence IRP_MJ_CREATE(FILE_OPEN), IRP_MJ_CLEANUP, IRP_MJ_CLOSE.
Dokany and WinFsp with a FileInfoTimeout of 0, have the worst performance with WinFsp slightly better than Dokany. NTFS has very good performance in this test, but this is likely because the test is run immediately after file_create_test, so all file metadata information is still cached. WinFsp with a FileInfoTimeout of 1 or +∞ performs very well (better than NTFS), because it maintains its own metadata cache, which is used to speed up extraneous IRP_MJ_QUERY_INFORMATION queries, etc.
@ -95,16 +95,16 @@ ifdef::env-github[image::perf-tests/file_open_test.png[]]
=== file_overwrite_test
This test measures the performance of CreateFileW(CREATE_ALWAYS) or equivalently the IRP sequence IRP_MJ_CREATE/FILE_OVERWRITE_IF, IRP_MJ_ClEANUP, IRP_MJ_CLOSE.
This test measures the performance of CreateFileW(CREATE_ALWAYS) or equivalently the IRP sequence IRP_MJ_CREATE(FILE_OVERWRITE_IF), IRP_MJ_ClEANUP, IRP_MJ_CLOSE.
Dokany again has the worst performance here, followed by NTFS. I suspect that NTFS has bad performance here, because it needs to hit the disk to update its data structures and cannot rely on the cache. WinFsp has very good performance in all cases, with the best performance when a non-0 FileInfoTimeout is used.
Dokany again has the worst performance, followed by NTFS. I suspect that NTFS has bad performance here, because it needs to hit the disk to update its data structures and cannot rely on the cache. WinFsp has very good performance in all cases, with the best performance when a non-0 FileInfoTimeout is used.
ifndef::env-github[chart::line[data-uri="perf-tests/file_overwrite_test.csv",file="perf-tests/file_overwrite_test.png",opt="x-label=file count,y-label=time"]]
ifdef::env-github[image::perf-tests/file_overwrite_test.png[]]
=== file_list_test
This test measures the performance of FindFirstFileW/FindNextFile/FindClose or equivalently the IRP's IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY.
This test measures the performance of FindFirstFileW/FindNextFile/FindClose or equivalently the IRP IRP_MJ_DIRECTORY_CONTROL(IRP_MN_QUERY_DIRECTORY).
WinFsp performance is embarrasing here. Not only it has the worst performance of the group, it seems that its performance is quadratic rather than linear. Furthermore performance is the same regardless of the value of FileInfoTimeout. Dokany performs well and NTFS performs even better, likely because results are cached from the prior I/O operations.
@ -113,7 +113,7 @@ ifdef::env-github[image::perf-tests/file_list_test.png[]]
=== file_delete_test
This test measures the performance of DeleteFileW or equivalently the IRP sequence IRP_MJ_CREATE, IRP_MJ_SET_INFORMATION/FileDispositionInformation, IRP_MJ_CLEANUP, IRP_MJ_CLOSE.
This test measures the performance of DeleteFileW or equivalently the IRP sequence IRP_MJ_CREATE, IRP_MJ_SET_INFORMATION(FileDispositionInformation), IRP_MJ_CLEANUP, IRP_MJ_CLOSE.
NTFS has the worst performance, which makes sense as it likely needs to update its on disk data structures. Dokany is slighlty better, but WinFsp has the best performance.
@ -142,7 +142,7 @@ ifdef::env-github[image::perf-tests/rdwr_cc_read_test.png[]]
This test measures the performance of non-cached WriteFile (FILE_FLAG_NO_BUFFERING) or equivalently IRP_MJ_WRITE.
NTFS has very bad performance here, which of course make sense as we are asking it to write all data to the disk. WinFsp has much better performance (because MEMFS is an in-memory file system), but is outperformed by Dokany, which is a rather surprising result.
NTFS has very bad performance, which of course make sense as we are asking it to write all data to the disk. WinFsp has much better performance (because MEMFS is an in-memory file system), but is outperformed by Dokany, which is a rather surprising result.
ifndef::env-github[chart::line[data-uri="perf-tests/rdwr_nc_write_test.csv",file="perf-tests/rdwr_nc_write_test.png",opt="x-label=iterations,y-label=time"]]
ifdef::env-github[image::perf-tests/rdwr_nc_write_test.png[]]
@ -193,4 +193,4 @@ ifdef::env-github[image::perf-tests/mmap_read_test.png[]]
== Conclusion
WinFsp appears to perform best in most of these tests with the notable exception of file_list_test and the rather dubious exception of rdwr_nc_write_test. The best performance is always when an infinite FileInfoTimeout because this enables metadata and data caching. User mode file systems that have consistency issues (e.g. network file systems) can choose a non-0 FileInfoTimeout (a conservative value is 1 second), which enables metadata caching but disables data caching. User mode file systems may also choose to use a FileInfoTimeout of 0, which will disable all caching and still know that they will extract maximum performance from WinFsp.
WinFsp appears to perform best in most of these tests with the notable exception of file_list_test and the rather dubious exception of rdwr_nc_write_test. The best performance is always with an infinite FileInfoTimeout because this enables metadata and data caching. User mode file systems that have consistency issues (e.g. network file systems) can choose a non-0 FileInfoTimeout (a conservative value is 1 second), which enables metadata caching but disables data caching. User mode file systems may also choose to use a FileInfoTimeout of 0, which will disable all caching and still know that they will extract maximum performance from WinFsp.