问题描述
对于如何提高应用程序的性能（无论是互联网应用还是企业级应用）我的观点一直是考虑一个核心：IO处理。因为我认为目前的CPU的处理能力已经是非常高了，正常编写的在内存中处理的代码没有太严重的问题都不会对CPU造成很大的影响，性能往往是被IO所限制。由于我和我的团队沟通时间比较长，所以我们之间的一个简单的IO说明往往覆盖了很多的含义，这些IO包括了磁盘IO、网络IO、内存IO以及各种设备的IO处理。我们的团队经验是尽可能的在各种IO处理中寻找出可以提升的效率。以下，我将从后向前说明我们团队在提升IO处理的经验和认识1数据库数据库是最明显的消耗磁盘IO的组件，提高数据的性能有多种，SQL语句写的好，也是减少了表的扫描（明显是IO动作），设计合理的索引又是提高了IO处理能力，将不在变化的历史数据独立的存储也减少了复杂IO的处理，为表设计冗余的字段也是为了减少IO读写提高性能，将数据表分布在不同的磁盘上也是提升IO效率。还有其他的各种方式，比如查询缓存、连接池神马的，原则同样如此。总之，减少数据库和磁盘之间过度的活动，能尽可能的提升数据库效率。2数据缓存内存IO的处理效能自然要远高于磁盘IO，数据的缓存就是减少磁盘操作，或至少减少性能更低的数据库操作。对于页面的结果数据缓存我们的通常简单方案是准备两个缓存区：一个内存，一个文件内存的缓存区，我们直接用HttpRuntime.Cache，在这个缓存区中我们放置特征码和数据（数据往往是页面需要的数据，一般我们放置JSON格式），过期策略上我们自然选择NoAbsoluteExpiration。当数据需要从内存缓存区中被撤掉时，我们会将这个过期数据再次处理，我们在Cache中有一个集合，这个集合放置了被撤掉的缓存数据的特征码，而对应的数据写入磁盘上的一个文件中。用户请求数据时，先检查特征码是否在正常的缓存中，如果不在，则检查是否在过期区，如果是过期区，则去读取磁盘文件（至少减少了数据库开销），都没有，那去查数据库吧。3网络传输后台数据最终要传递给浏览器，减少网络传输的字节也是提高吞吐的重点，简单的说，就是对网络IO处理优化。减少webform中的ViewState信息，或者干脆不用webform，改用MVC，或者直接httpcontext自己来控制所有状态信息。我们采用ashx并且为不同的服务开辟不同的ashx通道提高性能。由于ashx不必做一系列动作、不用经过一连串的事件处理、一大堆的控件状态管理（加载并解析ViewState，还原、更新控件的值、保存ViewState等），直接返回操作结果，也就不用耗费更多的服务器资源，返回的格式也非常好灵活，所有用ashx在基于文档型的网站中我们运用的很好。另外一点ashx对开发成员的工作隔离也是非常好。除了编程影响传输，页面需要的图片和css文件，js文件合理的处理减少HTTP请求也能提高网络IO效率：比如将图片合并，js、css压缩等简单的方式虽然改变不多，但并发的时候降低服务器的压力总是好的。4页面渲染和体验优化页面的html结构，有时候为了加快渲染，不必完全符合W3C的规范，减少div嵌套，使用固定宽度，主要javaScript的细节可以提高很好的体验。我在chrome中的测试结果可以发现，很多情况下网络的速度远远高于渲染的速度，所以能提高页面的处理，对个体用户的体验是很有效的。5数据提交在可靠的情况下，多考虑异步模式或多线程。对数据库的提交，web服务的访问都可以使用异步模型，当然是在可靠的情况下。页面的ajax自然也是异步的一种方式，另外js文件的加载也可以异步的方式。文章由http://www.seojishu.org整理，转载请注明
解决方案
解决方案二：
标题和内容完全不符，你说所谓的“IO优化”，就说好了，标题干嘛叫什么asp.net性能讨论。就好比我写一篇《论中国全面进入小康社会》，这么写：要想中国进入小康社会，必须提高家庭的收入，为了提高收入，我觉得要勤劳，怎么样算勤劳？要做到以下几点：1、2、3……。
解决方案三：
好吧，虽然不知道你想说明什么，但是觉得你很牛B
解决方案四：
想法不错，期待进一步有实质性解决方案的文章
解决方案五：
解决方案六：
不用想了只要能通过横向扩展提高性能的都不是问题所以瓶颈肯定是在数据库事务这一块
解决方案七：
这个似乎懂点优化的基本都知道要这么做
解决方案八：
我觉得楼主还局限在一个服务器一个网站的小网站的模式如果你要做成google那种支持几百上千万用户同时登陆的,只有一个服务器你再优化也没用
解决方案：
所以我只看了你12345的标题,根本没看内容看到你根本没有讨论什么分布式交互,负载均衡,我就知道这东西根本没什么用
解决方案：
对于一个局域网应用的小网站,登陆用户不超过100人的,做不做优化性能上也没什么大差别
解决方案：
对各部分的优化，没有绝对。有时候容易拿出一些非常传统的小东西来进行反复“优化”，甚至不惜引入各种冗余，容易过火地搞得让设计和维护反而陷入一团乱麻。反过来也有许多该优化的地方，因为没有更新到更上档次的模式，而总是优化得差一些。我举一个不太好最终决定的简单例子。比如说网站里有很多资源文件，有脚本文件、图片文件、甚至html文件本身。我们通常会在优化时，首先测试服务器上对这样的文件是否完善地支持404状态检测，避免重复下载文件。但是有的人就说了“许多大网站其实都不是这样的”，而是几乎全都使用“完全客户端缓存”方式。比如说一个图片的路径可能是src="http://www.abc.com/site1/poiu.png?version=82312"输出这个图片时告诉浏览器端“永不过期”，于是浏览器也就不需要经常到服务器上去判断这个图片有没有新版本了（这就减少了一次访问）。然后当这个图片修改了的时候，将路径修改为src="http://www.abc.com/site1/poiu.png?version=82313"有人认为这就一定比404检测要好。实际上对优化方法知道得多一两个，也不一定就能很极端地去抛弃什么东西。比如说如果我们的网站一个大V的头像改掉了，你还需要将以前所有使用过这个头像的html页面全都重新生成一遍、并重新把新页面分发出去吗？这就是一个问题。因此优化，要考虑什么是“刚好合适”，考虑到我们有没有那么多闲人总能在关键时机想起来那些已经弄得很冗余的事情，根据我们的自动化水平来决定哪种优化方法“刚好合适”，而不是绝对化。
解决方案：
列出优化方法进行分享，原则上一定是好的。我们还要讨论工程方法，理论与应用条件相配合。特别是我们要很“奸”地会在合适的时机放弃一些小伎俩，自己研发更高大上一点东西。