Since I've always wondered about this and never bothered to figure it out before....
In IIS 6 logs, the timetaken value represents the entire
time that IIS was touching the request. This at the very least includes time after IIS got the request, but is waiting to hand it off to ASP/ASP.Net for processing. It may also include time spend sending the bytes back to the client, but I don't have big enough data or slow enough networks to really answer that question well.
This does make a certain amount of sense. It's an web server log, not a web framework log, but it makes trying to troubleshoot "slow" pages really, really hard. We can't run multiple workers because it breaks classic ASP Session. So everything just queues up every time there's a long running request. So given a page with a large timetaken in the log, did that page really run for a long time? Or was it sitting on a queue waiting on another page that was running slowly? Sure the first page in order that was slow is prob. the root cause of all the following slowness, but how does one determine that root page?
What would be ideal would be separate timequeued, timeprocessing, timenetwork type columns... maybe those exist in IIS 7.... of course that would require getting our classic ASP certified for Windows 2008.