解决方法
>使用HTTP缓存工具.一个是用户代理缓存.其次,整个Web主干充满了可以缓存您的请求的代理,因此可以充分利用它.一个甚至落在你的服务器上的请求将为你的负载增加0,你不能优于那个:)
>就上述问题而言,使用CDN(Content Delivery Network,如CloudFront)作为静态内容.可以从CDN提供CSS,JPG,JS,静态HTML和更多页面,从而从Web请求中保存Web服务器.
>第一点的第二个推论：为动态内容添加过期缓存提示.即使像10秒这样的短缓存生命周期也会节省大量的命中,而这些命中将由客户端和服务器之间的所有代理服务.
>最小化HTTP请求的数量.看似基本,但可能是最容易被忽视的优化.实际上,雅虎最佳实践将此作为最重要的优化,请参阅Best Practices for Speeding Up Your Web Site.以下是他们的投注实践列表：
>最小化HTTP请求
>使用内容分发网络
>添加Expires或Cache-Control标头
> Gzip组件
> …(实际列表很长,只需阅读上面的链接)
现在,在您从多余的点击中尽可能地消除之后,您仍然可以优化实际命中服务器的任何请求.一旦你的ASP代码开始运行,与数据库请求相比,一切都会变得苍白：
>减少每页数据库调用次数.显然,可能的最佳优化不是首先向DB提出请求.有人说每次4次读取和1次写入是高负载服务器应该处理的最多,其他人说每页一次数据库调用,还有一次说每页10次调用就可以了.关键在于,总是越少越好,写入的成本远远高于读取.检查您的UI设计,也许页面一角的点击计数没人看到不需要那么准确…
>确保优化发送到sql Server的每个数据库请求.查看每个查询计划,确保您有适当的covering indexes,确保您不进行任何表扫描,检查您的clustered index design策略,检查所有IO负载,存储设计等.真的,没有捷径你可以带她,你必须分析和优化你的数据库,这将是你的chocking点.
>消除争用.没有读者等待作家.对于你的堆栈,SNAPSHOT ISOLATION是必须的.
>缓存结果.通常这是饼干崩溃.设计一个好的缓存实际上很难实现.我建议你观看Facebook SOCC主题演讲：Building Facebook: Performance at Massive Scale.在幻灯片47的某处,它们展示了典型的内部Facebook API如何：
.
cache_get ( $ids,'cache_function',$cache_params,'db_function',$db_params);
从缓存中请求所有内容,如果没有找到,则从MysqL后端请求.你可能不会从60000 servers开始想:)
在sql Server堆栈上,最佳缓存策略是基于Query Notifications的策略.您几乎可以将其与LINQ混合使用…