EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Performance

Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.
#16097
Posted: 03/21/2011 02:24:37
by Eugene Mayevski (EldoS Corp.)

Thank you for details. As Mapper (and your code is based on Mapper sample, as I understood) doesn't do any caching, did you consider adding a caching layer to avoid writing small chunks to real disk until the file is closed?


Sincerely yours
Eugene Mayevski
#16098
Posted: 03/21/2011 06:03:55
by Chris Schirlinger (Standard support level)
Joined: 02/18/2010
Posts: 38

Our code is similar to the Mapper sample yes

Our code does not write anything to disk, essentially the temporary files the 3rd party app writes to are written to a memory stream. There is only 2 or 3 reads from disk to get the tree list and to retrieve a 2 index files the 3rd party app looks for.

These temp files are basically deleted by the 3rd party app when the user browses to a different folder, so we don't need to persist them in any way.

I imagine the extra 2 seconds the Mapper example app takes to do the same thing is because it is writing directly to and from disk.

When checking the profile, reading and writing the stream does not take much time from the 6 seconds.
#16099
Posted: 03/21/2011 09:46:44
by Eugene Mayevski (EldoS Corp.)

I don't see why Mapper sample is slow, while VMounter/VDisk are not.

I think we need to carry some tests to understand, what causes slowness.


Sincerely yours
Eugene Mayevski
#16100
Posted: 03/21/2011 15:19:10
by Chris Schirlinger (Standard support level)
Joined: 02/18/2010
Posts: 38

The difference between the Mapper sample and the VMounter/VDisk is that the Mapper allows us to point to a folder containing very specific files on physical disk

The VMounter/VDisk just produce a couple of text files

The problem 3rd party app is looking for very specific files, the files our service provides. Data files and index files. If it finds these files, it loads the 2 index files, and then creates several temp files, and reads/writes 130,000 times in 28 byte packets

If we point the 3rd party app to a VMounter/VDisk, it does not find the Index Files and does *not* create any temp files, and is very fast simple because it does nothing.

The issue is the 3rd party writing many times in small byte packets to the temp files.
It only does this if it finds the specific index files
It only finds the specific index files when Mapper points to the correct folder or if it uses our own service that has those files.

What I am worried about is that 6 seconds is simple as fast as CBFS can do 130,000 read/write calls. All other apps we tried work fine on the virtual drives, just one is slow (unfortunately it is *THE* one we need to support)
#16101
Posted: 03/21/2011 17:38:53
by Bob Ferguson (Standard support level)
Joined: 01/24/2011
Posts: 6

I'd like to get back to basics.

We have created an app to supply data to a popular stock market charting program.
This charting program takes up to 7 seconds to open a folder using our CBFS vdisk.
It takes less then a second when using the same data from a hard disk.

Note that this is not a simple enumeration.
It is reading 3 normal disk files for the info to return to it's file open dialog.

Our vdisk does not read from the HDD in this process - all data is pre-cached in memory.
As Chris has said, the charting app makes 97000 calls to CbfsReadFile in its process of enumerating the folder.

This is rather extreme, but we have to live with it.
Our own charting app only makes around 6000 calls to achieve the same purpose.
And appears to be as fast as the HDD.

What I am trying to ascertain is: if what we have is as good as it gets, or can we expect to match, or get close to HDD performance.

So the generic question is:
Should CBFS in general be able to match HDD performance when serving data from a memory cache?
#16102
Posted: 03/21/2011 19:20:23
by Chris Schirlinger (Standard support level)
Joined: 02/18/2010
Posts: 38

Just did another test. I compiled and ran the example app VDisk

I then copied a folder across to it that contained the files required by the charting app (some index files and some data files)

I then browsed to it using the 3rd party app. It was just as slow, so the same results can be seen in VDisk as in Mapper
#16103
Posted: 03/22/2011 01:40:38
by Bastian Moldenhauer (Standard support level)
Joined: 06/04/2009
Posts: 40

just for reference.

Microsoft excel just does something similar. it reads a file in chunks of 8 Bytes if i remember correctly. This is also really odd.

Maybe you(eldos) could implement a cache in the kernel which could prevent those little request.
for example, let the driver always at least request chunks of 64kbyte (maybe make it configurable, maybe even on a file by file basis) and store it until the file gets closed or data outside of that array is requested, resulting in another request of 64kbyte. this way the driver can feed those small requests and save a lot of those user/kernel-mode transitions and requests. my guess is that this will speed up those issues.

thats my opinion ;-)
regards
#16104
Posted: 03/22/2011 04:41:22
by Eugene Mayevski (EldoS Corp.)

Quote
nisaus wrote:
Should CBFS in general be able to match HDD performance when serving data from a memory cache?


No. The reason is the extra set of context switches to and from the user mode, as well as certain locks performed on kernel level during those switches. We can't get rid of those switches as they are the nature of what CBFS offers - a mechanism of letting you write file system code in user mode.

Still it's not clear why the OS doesn't perform read-ahead caching of data in this case. Maybe the originator application (the one that does 97000 calls) uses some flags that tell the OS not to use caches.

Quote
Bastian Moldenhauer wrote:
Maybe you(eldos) could implement a cache in the kernel which could prevent those little request.


There's a cache there (both in the driver and in the OS). The developers need to study, why the cache is not used in this case.


Sincerely yours
Eugene Mayevski
#16107
Posted: 03/22/2011 16:21:55
by Chris Schirlinger (Standard support level)
Joined: 02/18/2010
Posts: 38

Quote
Eugene Mayevski wrote:
Still it's not clear why the OS doesn't perform read-ahead caching of data in this case. Maybe the originator application (the one that does 97000 calls) uses some flags that tell the OS not to use caches.


Is there anything we can do to test this or verify exactly what is happening so we can give you guys more information?
#16108
Posted: 03/23/2011 01:12:42
by Eugene Mayevski (EldoS Corp.)

As I understood, it's one specific application that behaves badly. So the most obvious way would be to check it's source code somehow to see how exactly the files are opened (what flags are passed), what the access strategy use is (maybe the calls are performed from several threads at the same time) etc.


Sincerely yours
Eugene Mayevski
Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.

Reply

Statistics

Topic viewed 16943 times

Number of guests: 8, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!