Understanding Performance Impact of Fast Trickling Option on TMG 2010

Introduction

When the EMP feature is enabled, TMG will accumulate data downloaded by the client and scan all the content for malware before transferring it to the client. Accumulating the entire file and scanning it, may take a significant time. During this period of time, the client doesn't receive any data and as a result a software timeout can occur or the user can even cancel the download. Therefore, actions need to be taken to avoid this. There are number of ways to deal with this problem which are collectively called “client comforting”. When downloading a file from the Internet through TMG a user can experience different comforting methods. For more information on Forefront TMG comforting method read Configuring malware inspection content delivery at Microsoft TechNet. This post describes potential performance impact by changing the default content delivery method from Standard Trickling to Fast Trickling.

Trickling

Trickling is based on sending successive small portions of the response data to the client before completing the final scan (inspection of the whole response). This mechanism guaranties that the underlying connection is kept alive with the client until the final scan of the whole file.

These portions are scanned in order to reduce the risk of passing malicious code to the client. Standard trickling minimizes the performance overhead of the additional scanning by sending small portions of the response to keep the connection alive. Once the entire response has been accumulated, TMG will perform the final scan and send the remaining data at the maximum possible speed to the client, if content is safe.

Performance

In some scenarios, such as media streaming, throttling down the download speed has adverse effect to the user experience as the downloaded content is used even before it has completed (e.g. playing a movie as it is being downloaded). When using fast trickling option for the Content Delivery method in Malware Inspection, Forefront TMG sends the data as fast as possible to the user, by scanning scan every chunk before sending it. This method requires more resources from the Forefront TMG server, but provides a better experience for the user.

Because of the performance impact, it is recommended to use fast trickling only when important for the user experience (e.g. for media files which are played by online players like YouTube. This is different for non-HTTP audio or video streaming which is exempted from inspection). The requirement to scan every sent portion still applies, so the filter performs O (size) scans. Since every scan starts from the beginning (the entire available prefix is submitted) depending on the file type the overall complexity may become X (where X is size ^ 2). To reduce the number of scans the filter applies some level of buffering. The parameter for the fast trickling is the tradeoff between the user experience (less buffering on TMG, more scans) and performance (more buffering on TMG, less scans) .

Changing all downloads to Fast Tricking (as shown below) may cause a rise in CPU utilization when the server is too busy performing malware inspection operation. It is recommended to use this setting only when most of the traffic is streamed. In other scenarios it is recommended to use Standard trickling by default and set fast trickling for the content types only.

Troubleshooting

When Fast Trickling is used as default method, you will notice that standard tricking is never used by monitoring the following counters (for complete lists of Malware Inspection Counters see this article) on perfmon:

Conclusion

To balance performance and user’s experience we recommend using Standard Tricking as default method and Fast Trickling for content types which are streamed by the clients. This way you better balance performance with better user’s experience.

Authors
Yuri Diogenes
Senior Support Escalation Engineer
Microsoft CSS Forefront Edge Team

Ori Yosefi
Senior Program Manager
Forefront TMG Team

Technical Reviewer
Lars Bentzen
Escalation Engineer
Microsoft CSS Forefront Edge Team

Eric Detoc
Escalation Engineer
Microsoft CSS Forefront Edge Team