改善系统性能瓶颈的一点小体会

    首先，必须要有一个全局的概念，我要改善的系统是一个查询系统，性能问题主要体现在列表展现速度太慢。系统主要可以分为三大部分：数据库、页面后台处理和页面前端展现。


    首当其冲，从数据库下手，根据我们的查询语句，对数据库中一些常用的大数据量数据表进行结构优化，一般情况下可以不用优化表结构，除非要大动干戈的时，然后根据查询条件，为数据表添加适当的聚集和非聚集索引，这一点非常重要！当然，效果也是非常明显的，数据库量越大，效果越佳，但一定要在需要的地方添加索引，不要太贪~然后，再根据常用并表的情况，设计视图，视图的好处很明显，松耦合是最大的亮点，而且，简化查询语句，而且不占用数据库存储空间，好处多多，建议根据情况适当添加。这里还有说一句，就是我们可能会用到一些数据库函数，千万不要忘记优化哦，例如可以通过一条语句来计算很多的数据结果，没有必要查询两次哦。争分夺秒，必须关注每个细节！


    然后，考虑到对页面后台逻辑的精简，经过测试，发现主要由两大部分成为时间杀手：数据库查询处理和XSLT转换，前者，我们已经有所优化，后面这个说来有些特殊，这也是经过多次测试发现的规律：因为我的测试环境，数据库服务器和IIS服务器分属两台不同机器，当数据库查询操作消耗时间比XSLT转换操作长时，数据库服务器的CPU负载率非常高，而这个时候，IIS服务器的CPU负载不高；相反，数据库服务器的负载下来了，但是IIS服务器的负载上去了。这里需要说明一点，XSLT转换操作其实是一件挺耗时的操作，而且当我们把查询处理改善了以后，转换带来的性能瓶颈就出现了，于是，将XSLT转化放到客户端进行处理，性能提升大概10倍左右，还是相当明显的。


    最后说下客户端的处理，由于我们的系统是B/S结构，所以，客户端的压力一般会很小，我们应该秉持着精简原则来编写一些动作脚本，尽量使用CSS代替脚本动作，而对一些大段脚本也建议通过js文件的方式引入。这里还要说一点，就是使用js进行xslt转换后并通过document.write()出的内容，可能会和我们直接通过后台Response.write()的内容有一些样式上的差异，需要我们细心处理。


    由此，也可以得出一个道理，在处理性能瓶颈的时候，必须首先理清现在的性能消耗发生在哪里？并进行排序，由高到低进行处理，只有当我们解决了高的瓶颈，才有可能发现一些隐藏的性能瓶颈，这样一直进行压缩，直到满足我们的预期效果为止。


    最后，还要注意对实验性测试进行计划设定，必须有目的地进行测试，这样才能得到我们想要的结果，当然，一个性能目标也是必不可少的，否则，我们很容易迷失在这个不断迭代的过程中，虽然有些枯燥，但提升就在我们每次的思考中。