dokan-dev / dokany

User mode file system library for windows with FUSE Wrapper
http://dokan-dev.github.io
5.21k stars 661 forks source link

Performnace drop in Dokany2.x when using mirror.exe #1063

Closed adropit closed 2 years ago

adropit commented 2 years ago

Feature request can skip this form. Bug report must complete it. Check List must be 100% match or it will be automatically closed without further discussion. Please remove this line.

Environment

Check List

Description

Hello, We upgraded our program from Dokany1.4.1 to Dokany2.0.0.2000 (later added a test using Dokany 2.0.1.1000). Unfortunately, instead of a performance improvement, we noticed actually a performance drop…

In some tests using your mirror.exe example run with Dokany1.4.1 vs Dokany2.0.0.2000 vs Dokany2.0.1.1000 we noticed that the administrative rights play a big role in the performance. The tests implied reading over 9000 files sequentially using the mirror.exe provided by the Dokany release. The reading of files in our test program was done using three different C/C++ methods. If both mirror.exe and our test program were run with administrator rights, the performance difference was slightly in favor of Dokany2.0.1.1000. But if both, mirror.exe and the test program (client), were run without administrative rights there was a massive performance drop when using Dokany 2.0.1.1000 if the files were read in chunks of 4KB. (See the attached document – section “DifferentRights”)

We also run a different set of tests using a Disk-Benchmark tool “ATTO”. This also shows some performance drop when using Dokany2.0.1.2000 compared to Dokany1.4.1. (See the attached document – section “Disk benchmark”). The Disk-Benchmark tool could only be run with elevated rights and we assume that without administrative rights the difference in performance drop would be bigger. The last test was done reading (different) over 9000 files with the same three C/C++ methods where both the mirror.exe and the test program (client) were run without administrative rights. There was also a performance drop between Dokany1.4.1 and Dokany2.0.1.2000 in the case of sequentially reading in chunks of 4KB. (See the attached document – section “Own benchmark”).

So here are some questions from our side: You provided some benchmark results for MemFS. Were the test run with elevated rights (both memfs.exe and your benchmark program)? (Can memfs.exe be run without elevated rights?) Could you run the same benchmark using mirror.exe? (both with and without elevated rights) Could you provide some benchmarks (Dokany 1.x vs Dokany 2.x) using the mirror.exe putting the accent on reading/writing files sequentially/random? Performance_dokany.xlsx

Liryna commented 2 years ago

Hi @adropit ,

The benchmarks were run against memfs 5 times and in a clean environment without antivirus (even with the Windows defender disabled) to actually avoid having resources taken, requests being disrupted by other components and most stable results. Mirror is totally contrary as it is under the mirrored disk activity constraint. If you add an antivirus, you will have biased results.

The Admin rights thing you are describing could be a sign of an antivirus or another app that interacts differently with the user filesystem.

You provided some benchmark results for MemFS. Were the test run with elevated rights (both memfs.exe and your benchmark program)? (Can memfs.exe be run without elevated rights?)

They were all run with admin rights but I do not expect to see a difference as memfs is not under external resource constraint and no antivirus was enabled.

Could you run the same benchmark using mirror.exe? (both with and without elevated rights) Could you provide some benchmarks (Dokany 1.x vs Dokany 2.x) using the mirror.exe putting the accent on reading/writing files sequentially/random?

As said previously, mirror is really not what should be used for benchmarks. It is really just a sample and it was never focused on perf.

Read/Write improvements were not specially improved in v2 compared in other scenarios and the results I shared are reflecting it. A real Read/Write improvement would be to implement caching. See https://github.com/dokan-dev/dokany/discussions/1047

Small remarks as I would not expect it to have any impact on your results: In your v1 benchmark you are using /t 8 which I imagine is due to the system having 8 cores. This is exactly what the v2 is fixing, using a system thread pool to use the right number of threads depending on the system it is run on. Most filesystems were just using the default 5 thread value.

Liryna commented 2 years ago

@adropit could you please redo your test with this change https://github.com/dokan-dev/dokany/commit/231fc23f5e0581aa5b401c838bebf72bef868e9d ? (it is not in the branch master yet)

adropit commented 2 years ago

@Liryna Unfortunately I cannot set my Windows in test mode. Therefore I can only test signed DLLs provided by your releases....

Liryna commented 2 years ago

I pushed multiple changes that improves the read/write scenarios. I still need to run the full benchmark but ATTO is giving good results especially on real world buffer size (4k -> 128k). 1.5.1: 1 5 1 vs head: with-mem-pool

Liryna commented 2 years ago

See https://github.com/dokan-dev/dokany/releases/tag/v2.0.3.1000

adropit commented 2 years ago

Thank you for the release. I will also run some tests during the day.

adropit commented 2 years ago

@Liryna I ran my own tests today (no admin rights, windows defender on, read about 1000 files, 3.3GB) and I'm getting an average improvement when using Dokany2.0.3.1000 of about 5% compared to Dokany1.4.1.1000. This is an actually improvement considering that Dokany 2.0.2.1000 was slower compared to 1.4.1. I think that you are on the right track regarding the performance improvements in v2.

Liryna commented 2 years ago

Awesome thanks for the feedback. Are you able to see which buffer size was used during the read?

adropit commented 2 years ago

In my tests I try to read the entire file at once using C and C++ methods. There was a minor improvement there. I also read the file in "chunks" of 8KB and 16KB. In this case I noticed the biggest improvement.

Liryna commented 2 years ago

I see. Thanks for your feedback and report!