#Steps:
#Fields: date time threadId stepName
#---------------------------------------------------
2009-07-09 16:48:01.752 0024 BeginRequest
2009-07-09 16:48:01.752 0024 AuthenticateRequest
2009-07-09 16:48:01.752 0024 PostAuthenticateRequest
2009-07-09 16:48:01.752 0024 AuthorizeRequest
2009-07-09 16:48:01.752 0024 PostAuthorizeRequest
2009-07-09 16:48:01.752 0024 ResolveRequestCache
2009-07-09 16:48:01.752 0024 PostResolveRequestCache
2009-07-09 16:48:01.752 0024 PostMapRequestHandler
2009-07-09 16:48:06.284 0007 AcquireRequestState
2009-07-09 16:48:06.284 0007 PostAcquireRequestState
2009-07-09 16:48:06.284 0007 PreRequestHandlerExecute
2009-07-09 16:48:06.284 0007 EndRequest
#---------------------------------------------------
#End of steps.
也就是说，在PostMapRequestHandler之后，AcquireRequestState之前，有一大段的等待时间。而这个报告后面的堆栈情况，则显得很奇怪：线程7从第一次截快照的时候开始，一直到结束都是空白的！甚至在其他的一些报告中甚至会发现这个线程已经被分派处理其他页面的工作了（堆栈中的调用很明显指出是另一个aspx页面的代码）。结果一Google“PostMapRequestHandler”和“AcquireRequestState”这两个关键字，就找到了国外另一个有类似遭遇的受害者：
http://forums.iis.net/t/1147300.aspx
这个楼主是一个aspx页面里面有好几个iframe，并且每一个iframe里面都是访问同一个Web应用下的Aspx页面。现象就是iframe内的页面会一个个蹦出来，尤其是这些页面都比较慢的时候。和我这里截获到的情况一样，也是PostMapRequestHandler事件到AcquireRequestState之间有很长的空白时间。顺藤摸瓜，又找到了这么一个帖子：
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.dotnet.framework.aspnet&mid=7f56033f-caac-47c2-bd9c-95512aa14b47
原来，在AcquireRequestState之前，需要等待上一个同SessionId的页面处理完毕之后，才会继续处理当前页面。其根本原因是：同一个SessionId下面的Session对象不应该被同时写入，否则就会全乱套了，原理和多线程竞争是一样的。因此在设计上，同一个SessionId的页面（或者IHttpHandler）就会顺序执行。
好了，到这里真相又一次大白了！（指不定还有别的问题，还会有下一次大白的时候）在我们的系统中，由于特殊的原因，对图片的输出我们会通过Asp.Net来处理，比如说加上一些合适的缓存标记，甚至会动态生成图片输出（令人惊讶的是，这个动态输出的总时间消耗甚至不到100毫秒，所以不要说动态生成是一种不好的实施方式）。但是，由于没有经过特殊处理，Asp.Net底层认为这些访问时需要对Session进行写操作的，于是就在AcquireRequestState之前挂起，等待上一次同SessionId访问结束。可想而知，图片多了就会导致排队，甚至排很长的队。如果在排队结束之前访问下一个页面，正好系统又没有丢掉之前的队列，则这次访问就会变得比较漫长了。那么怎么做呢？ 在一次顺藤摸瓜，找到了确切的说法：
