Hi,
Ensuring your drivers are up to date is important, but in our case updating them made no difference.
FREB was usefull in trapping error events but for us in the end we put some network sniffing tools in place and managed to catch one of the events in the logs. What we noticed was the number of active connections went through the roof...... using nestat -an also showed similar numbers once we knew what to look for.
Going through the process pipeline from NIC to ASP.Net worker we suddenly hit on a significant difference between our old implementation (IIS5) and the new one (IIS7). In the old models the .Net is offloaded whilst static content is handled in line; in the new intergrated model all is handled in the same pipeline by default. We had effectively reduced our processing pipelines from 2 to 1!
Once we realised this a whole bunch of stuff suddenly came under scrutiny. What we did in the end was:
( note we don't have keepalives turned)
1) created seperate application pools for active and static content.
2) increased the maximum concurrect connections from the default of 12 to 5000, depending on your version/patch level this will either require a reg key for windows 2008sp1 without MS09-36 or an entry in the aspnet.config file. reg=Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0]
"maxConcurrentRequestsPerCPU"=dword:00001388
or config file
<?xml version="1.0" encoding="utf-8"?><configuration> <system.web> <applicationPool maxConcurrentRequestsPerCPU="5000" maxConcurrentThreadsPerCPU="0" requestQueueLimit="5000"/> </system.web></configuration>
3) For our application we also implemented our old machine.configs, IIS7 config viewer editor under system.web/processModel shows the running values.
<system.web>
<processModel autoConfig = "false" maxWorkerThreads = "150" maxIoThreads = "150"/>
4) we are also planning on lowering the ConnectionTimeout in order to force closure should transfers take too long a time to complete. In IIS the default is a 2 mins, however if the value is set too low, say 10 secs, devices on slow connections ( like mobiles) will suffer. Note: we have not done this yet.....
I hope this helps.
Regards