As most of you are (or at least should be) aware of
FltGetFileNameInformation has a performance penalty. Most notably when a
normalized file name is queried in pre-create. But there was no actual
data.
During a recent interop testing with one of the antivirus product,
we found that a combination of our filter and the AV makes certain
operations extremely slower. Operations that you would not even consider
do any file I/O.
This is just preliminary data and may represent everyday cases, but
it is quite interesting that it is worth sharing.
We tested the following scenarios: Process monitor only (i.e. no
other filter), PM with our driver, PM with AV only (without our driver)
and all 3 together.
With PM alone, file open operations took a mere 0.0000100-0.0000300
(I am not sure whether PM measures in milliseconds or microseconds)
With PM and our filter, the operations take about 10-15 times
longer. And this is with virtually no additional processing over getting
the file name, and for a simple open processing (i.e. when FILE_OPEN is
specified) we do not even query the normalized file name in pre-create.
With PM and the AV engine, the operations take 50-60 times longer
than with PM alone. This may not be exactly a sign of FGFNI performance
hit, as with the AV I see that most file opens are listed twice in
Process Monitor, and I am guessing the AV is sending the call back to
the top of the stack instead of just below it. The performance hit could
also be due to the AV asking for the normalized name in pre-create
Quite expectedly with all 3 products together, the duration of file
opens is about 70-75 times higher than with PM alone.
Hope this helps.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
Dejan,
Querying normalized names has always been a HUGE hit. Before filter mgr
when I needed to implement name normalization myself I would always find
ways to improve the processing; cache component names commonly accessed,
etc. It’s just an ugly job and requires a lot of work. I mean if you
have a name with 5 components in it, all of them <= 8 characters in
length, this requires at least 4 opens and 5 directory queries, a non
trivial amount of work to perform to get a name.
That said, thanks for sharing the information, it does give some
concrete data to something which I have observed for a long time.
Pete
On 4/23/2011 6:23 AM, Dejan Maksimovic wrote:
As most of you are (or at least should be) aware of
FltGetFileNameInformation has a performance penalty. Most notably when a
normalized file name is queried in pre-create. But there was no actual
data.
During a recent interop testing with one of the antivirus product,
we found that a combination of our filter and the AV makes certain
operations extremely slower. Operations that you would not even consider
do any file I/O.
This is just preliminary data and may represent everyday cases, but
it is quite interesting that it is worth sharing.
We tested the following scenarios: Process monitor only (i.e. no
other filter), PM with our driver, PM with AV only (without our driver)
and all 3 together.
With PM alone, file open operations took a mere 0.0000100-0.0000300
(I am not sure whether PM measures in milliseconds or microseconds)
With PM and our filter, the operations take about 10-15 times
longer. And this is with virtually no additional processing over getting
the file name, and for a simple open processing (i.e. when FILE_OPEN is
specified) we do not even query the normalized file name in pre-create.
With PM and the AV engine, the operations take 50-60 times longer
than with PM alone. This may not be exactly a sign of FGFNI performance
hit, as with the AV I see that most file opens are listed twice in
Process Monitor, and I am guessing the AV is sending the call back to
the top of the stack instead of just below it. The performance hit could
also be due to the AV asking for the normalized name in pre-create
Quite expectedly with all 3 products together, the duration of file
opens is about 70-75 times higher than with PM alone.
Hope this helps.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
It is quite unfortunate we cannot figure if the file name contains a mount point without querying the file system.
IMO, that is the most problematic issue - without it, we could use the opened name a lot of the time and not need any
extra processing, which would remove 99% of the FGFNI overhead.
Dejan.
Peter Scott wrote:
Dejan,
Querying normalized names has always been a HUGE hit. Before filter mgr
when I needed to implement name normalization myself I would always find
ways to improve the processing; cache component names commonly accessed,
etc. It’s just an ugly job and requires a lot of work. I mean if you
have a name with 5 components in it, all of them <= 8 characters in
length, this requires at least 4 opens and 5 directory queries, a non
trivial amount of work to perform to get a name.
That said, thanks for sharing the information, it does give some
concrete data to something which I have observed for a long time.
Pete
On 4/23/2011 6:23 AM, Dejan Maksimovic wrote:
>
> As most of you are (or at least should be) aware of
> FltGetFileNameInformation has a performance penalty. Most notably when a
> normalized file name is queried in pre-create. But there was no actual
> data.
>
> During a recent interop testing with one of the antivirus product,
> we found that a combination of our filter and the AV makes certain
> operations extremely slower. Operations that you would not even consider
> do any file I/O.
> This is just preliminary data and may represent everyday cases, but
> it is quite interesting that it is worth sharing.
>
> We tested the following scenarios: Process monitor only (i.e. no
> other filter), PM with our driver, PM with AV only (without our driver)
> and all 3 together.
> With PM alone, file open operations took a mere 0.0000100-0.0000300
> (I am not sure whether PM measures in milliseconds or microseconds)
> With PM and our filter, the operations take about 10-15 times
> longer. And this is with virtually no additional processing over getting
> the file name, and for a simple open processing (i.e. when FILE_OPEN is
> specified) we do not even query the normalized file name in pre-create.
> With PM and the AV engine, the operations take 50-60 times longer
> than with PM alone. This may not be exactly a sign of FGFNI performance
> hit, as with the AV I see that most file opens are listed twice in
> Process Monitor, and I am guessing the AV is sending the call back to
> the top of the stack instead of just below it. The performance hit could
> also be due to the AV asking for the normalized name in pre-create
> Quite expectedly with all 3 products together, the duration of file
> opens is about 70-75 times higher than with PM alone.
>
> Hope this helps.
>
> –
> Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
> http://www.alfasp.com
> File system audit, security and encryption kits.
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.