优化二手代码的心得

备用工具及下载地址

1.页面执行时间查询工具

JetBrains dotTrace Profiler v3.0

下载地址在这里：http://www.jetbrains.com/profiler/download/

2.数据库profile跟踪之后的数据包分析工具

下载地址在这里：http://www.cleardata.biz/cleartrace/download.aspx

3.Sql Server 2005 Profiler

随数据库一起安装

4.iis日志分析

采用启用odbc将日志记录到数据库中，查询的方式

5.windbg和umdhtools.exe

当遇到不知道是什么问题的问题的时候，分析问题的工具

umdhtools的下载和使用方式地址在这里：http://support.microsoft.com/kb/268343/zh-cn

其实当我到一个新的公司，我们不可能马上就接触的该公司的核心开发中，各主管一般都会分配给大家一些别人已经完成的代码，让我们来熟悉和学习，高一些的主管会让你带着家庭作业去学习代码，顺便为下一阶段的工作来准备，那么家庭作业就出来了：看完代码之后你能不能提一些你认为设计不合理或者可以优化性能的地方呢？OK，下面我们就来循序渐进的从未知代码着手吧。

拿到代码之后，一般我会逐个击破，首先使用dotTrace profiler分析页面，这里我们用个人空间本地的调试链接http://my2.csdn.net/index.html来给大家看一下profiler的截图（一般，我们应该去寻找流量最大的那个页面，把那个页面的问题解决了，也许优化的问题就解决一大半）：

OK，看到页面里面当我们需要显示这个页面就经过了哪写方法，并且，他列出了每个方法的执行时间，被调用的次数，这时候我们会大体对程序结构有一个了解，从数据库以上的逻辑层，我们知道当打开这个页面需要哪些方法以及方法是如何一步布走下去的，但是，我们现在只是对程序有一个初步的了解，虽然有执行时间显示，但是天知道这里哪些时间使我们可以入手优化的呢。放着吧，暂时知道流程对程序有一个大体的了解就好了。

这个时候我们可以打开sql server profiler，再次刷新一次该页面，OK，出来了，当打开这个页面所需要执行的存储过程，我们也知道了。知道运行了哪些存储过程，

也有了每一个sp所执行的时间，这时候我们使用sql server profiler所跟踪出的文件，使用clear trace帮我们分析出每一个sp的调用次数，执行时间，磁盘i/o。

这个时候我们知道，数据库中我们使用了哪些表，哪些存储过程，以及每一个存储过程的详细信息。

到了现在，我们已经对执行当前页面所用到的代码，sp，和表都有了一定的了解。

思考时间：

1. 当页面被打开，我们用到了哪些脚本？是如何和服务器端通信的？页面结构（html结构）设计的是否合理，脚本运行是否已经达到了，我们自己所能认知的最好状态？页面在客户端获取的时候是否已经启用压缩？包括css，脚本和html（往往在这里就可以找到一些可以优化的蛛丝马迹）
2. 当这个页面被打开，逻辑结构这样一步一步下去，哪里是不必要的？哪里是可以调优的？有些地方是否需要被调用那么多次？能不能减少？
3. 数据库sp，都被执行了这些，哪些是不需要的？有没有可能增加冗余字段，使每一次数据库操作更快？
4. 高级思考：页面方面，在整个逻辑结构，和层次结构设计的时候为什么这样设计？（这个时候要去问之前的程序员同志们和你的代码注释；当然如果像我之前接手的代码，啥都没有，那老兄，你就自求多福吧，哈）也许那么多次调用并不只是当前程序本身在使用，有没有公司里别的地方也在调用呢？如果是被调用，那么是否可以独立出来，专门供大家调用，让代码逻辑结构更清晰呢？
5. 数据库sp，每一个都在sql server 2005查询分析器里面执行一下，看看时间究竟消耗在哪里了，网上有很多文章，告诉我们如何优化sp降低i/o,提高执行效率，我就不多说了。
6. 数据库中有没有作业？有哪些数据是可以用定时的应用程序去跑起来的？没有必要实时计算并显示。
7. 有没有可能把某些东西独立成服务？并进行操作？
8. 也是最难的地方：这个程序的缓存是如何使用的？这个问题也是最难查，最复杂也往往最难规划的地方，需要不停的去尝试。有些地方能不能用Ifream？能不能用文件缓存？有没有使用第三方的缓存，比如memcache；现有的缓存有没有时间过长等等的问题。
9. 最高的高度：本程序的服务器部署结构什么样的？也就是服务器拓扑结构图，搞清楚了这个，才会真正知道一个客户端发起的请求，是如何到达终端服务器，并且如何执行的。有没有可能通过修改服务器拓扑结构，来提高程序的执行性能。

说了这许多一个程序在发布之前的准备工作就已经完毕了，那么是不是本次思考就结束了呢？回答是肯定的：不是。哈哈

再次思考：

1. 如果这个程序，让你去发布到服务器，你该如何去做呢？
2. 有哪些步骤需要了解，升级需要的工具有没有准备好？都是哪些？
3. 和公司哪些其他的东西有联系，发布的时候必须兼容的？
4. 数据库的数据是否涉及到迁移？
5. 发布的所有的数据库脚本和release版本的程序有没有准备好？
6. 有哪些服务需要升级？
7. 有哪些作业需要重新设置？
8. 有没有需要生成的文件缓存？
9. 最后一个，是和你的经济直接相关的，有没有让运维人员关闭报警系统，哈

考虑过了之上的所有的所有，是不是结束了呢？回答依然是肯定的：没有。

以上我们全部都考虑的是，我们发布的程序，在外部的服务器上不出问题的情况，真的不出问题吗？你是不是在做梦？

1. 如果出现问题，如何查找问题，那么我们的工具有没有准备好？
2. 所有涉及到的相关人员的联系方式你有没有？

最糟糕的，到了第二天早上，问题还没有解决，兄弟，别着急，冷静，坚持就是胜利。

如果到了第三天问题还是没有解决：兄弟，你是火星来的，还是回火星去吧（被老大打飞）

本文还差很多图，和资源链接和详细信息，慢慢补齐吧，休息，休息一会2