performance when accessing a file on a network server sequentially after having accessed it randomly

Question

I'm working on a native C++/Win32/MFC app on Windows 7. I'm using CFile to open a file stored on a remote server (with the flags, CFile::modeRead | CFile::shareDenyWrite). The server is running Windows Server 2008 and I'm accessing the file on a shared drive via regular windows file sharing. Once I open the file, I'm reading it as described below.

First, I'm seeking to multiple locations in the file (10 locations) and reading small (128 byte) sections. Then, I'm seeking to the beginning and reading sequentially through the entire file.

What I noticed is that doing the above was MUCH slower than just opening the file and reading through it. The initial random seeks and sampling is very quick, almost instant even with a large file. What's interesting is that even though this is quick, the next part, scanning through the file is very slow when compared with just scanning through it without the initial random access.

In trying to figure out what was going on I pulled up performance monitor and watched the network traffic. If I just do the sequential read through the file, I'm getting 3.5MB/s download over the wireless adapter. If I first randomly seek around, then sequentially read through I'm only getting 300kB/s during the sequential read.

The solution was to close and re-open the file after doing the random access part. When I did this, the sequential read sped right up.

So it seems that doing the random access reads (the seek and read) did something on the server which then caused the sequential read to be slow. I'm wondering, does anyone know for sure whats going on here and what the actual cause is of the behavior I'm seeing? Although I have a fix for it I'd like to better understand what's going on under the hood to cause this.

Answer 1

Mooing Duck's comment is right on. The operating system starts out assuming sequential access as a 'soft' option -- enabled until proven harmful. But the random accesses causes the read ahead to make performance worse, and the 'smart' caching behavior turns read ahead off.

You would think a few sequential accesses would cause Windows to turn it back on. But unfortunately, the flag is no longer 'soft' at this point. Windows considers random access proven from then on, just as if you had forced it into that mode.

You can pass CreateFile the FILE_FLAG_SEQUENTIAL_SCAN option to force it to keep read ahead on no matter what. But your re-open solution is probably about as good as anything. And it's about the only way if you don't call CreateFile directly.