标签：
对以下文章内容我要说明下，在财大气粗的互联网公司或为财大气粗的客户服务的不缺钱的主，请立即绕行，以下内容不适合您。
以下内容为客户计算资源紧缺，预算紧缺，无法通过增大带宽，增多服务器，购买各种高级服务的程序员们进行讨论。
谢谢
对于如何提高应用程序的性能（无论是互联网应用还是企业级应用）我的观点一直是考虑一个核心：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 对集合的代码处理
无论是页面的javaScript，还是后台的java，C#，在目前的业务中对集合/数组的操作肯定是最频繁的，考虑用一些细节上的优化，也可以提高性能
类似很多技巧都是减少对集合Length/Count的反复确认对高频的集合操作是有益的。当然集合中不能动态的加减数据。数组优先、泛型其次，arrayList最后考虑，这些选取的原因都是减少IO开销。
还有很多代码的细节都是可以提高效率，比如对string的认知什么的。
（林永坚MVP 提示我没有表达清楚以上意思，我的想法是：集合我的测试是，如果反复的判断count会比较慢，不如for的时候吧count先求出来，还有就是尽可能的用数组，因为数组初始化的时候已经赋值完毕了，且又是强类型，不知道我表达的对不）
4 网络传输
后台数据最终要传递给浏览器，减少网络传输的字节也是提高吞吐的重点，简单的说，就是对网络IO处理优化。减少webform中的ViewState信息，或者干脆不用webform，改用MVC，或者直接httpcontext自己来控制所有状态信息。我们采用ashx并且为不同的服务开辟不同的ashx通道提高性能。由于ashx不必做一系列动作、不用经过一连串的事件处理、一大堆的控件状态管理（加载并解析ViewState，还原、更新控件的值、保存ViewState等），直接返回操作结果，也就不用耗费更多的服务器资源，返回的格式也非常好灵活，所有用ashx在基于文档型的网站中我们运用的很好。
另外一点ashx对开发成员的工作隔离也是非常好。
除了编程影响传输，页面需要的图片和css文件，js文件合理的处理减少HTTP请求也能提高网络IO效率：比如将图片合并，js、css压缩等简单的方式虽然改变不多，但并发的时候降低服务器的压力总是好的。
5 页面渲染和体验
优化页面的html结构，有时候为了加快渲染，不必完全符合W3C的规范，减少div嵌套，使用固定宽度，主要javaScript的细节可以提高很好的体验。我在chrome中的测试结果可以发现，很多情况下网络的速度远远高于渲染的速度，所以能提高页面的处理，对个体用户的体验是很有效的。
4 数据提交
在可靠的情况下，多考虑异步模式或多线程。对数据库的提交，web服务的访问都可以使用异步模型，当然是在可靠的情况下。
页面的ajax自然也是异步的一种方式，另外js文件的加载也可以异步的方式。
5 锁
太累了，先不写了
标签：
原文地址：http://www.cnblogs.com/zhangxiaolei521/p/5527821.html
