今天凌晨 阿根廷对瑞士比赛已经过去，比分是1：0 阿根廷获胜；虽说我是伪球迷，但是也挺希望梅西进入决赛。昨晚也压了下90分之内 0：0 ，结果胜出；另一场压的是美国对比利时，也是压平，就这样二串一被我无意中压中了。想起昨晚睡觉之前手随便抖动了一下才中的奖励，才明白什么叫“有心栽花花不开，无心插柳柳成荫啊”！ 或者球场上就是如此吧，没有常胜将军，屌丝也同样能干掉高傲的 高富帅。。。。西班牙被出局了，葡糖牙也嗝屁了，C罗就这样没落的走了！ 哥斯达黎加队好像是我买彩票第一场中的球队，也是黑马中的战斗机。然后今天的话题也跑偏了......我了我竟然是程序员.....
对于.net 开发原来说在性能优化方面，有很多种方案；
第一： 使用日志系统
这种方案需要开发人员用大量的时间去在函数开始和结尾上写日志。。。。若没有.net mvc 中的那种拦截方式来跟踪日志系统，在平时的7层架构中是比较困难的...
第二： 在代码中不断的写System.Diagnostics.Debug.WriteLine();
这种方案个人感觉比日志系统好，released 版本也不会将Debug的信息加入进去。而且配合debugView工具就能一目了然的看清每个断点的执行时间，这样就是大概初步了解了。。。。。。在多线程里面好像还是比较实用的。 缺点就是我压根不想写任何debug信息啊，因为我根本不知道问题出在哪里。
第三、dotTrace Performance
以前和大家一起用过dotTrace 进行客户端的性能优化，大家对他的评论是不准确。。。。。当初自己的也有怀疑，因为他和debugView 之间查选出来的数据 是慢一些的，或许真会影响进程执行的效率。 但也只是或许吧。。。那也好是好久之前的事情了。
然而上周潘总让我帮SCM 他们处理一个客户（太湖雪）的一个问题：出入库单据 新增会报错 1、“sqlTranse 已经关闭”；2、‘0行没有 数据’ 等乱七八糟的提示错误。 本着负责的态度，让我远程看了下，发现的确会出现第一个问题。。。。但是。。。但是 在这过程中让我很蛋疼的是：“你妈，你们新增一张出入库单据，竟然花费70多秒，你造吗？？你们竟然没有提？，而且你们目前数据只有１－２万条。。” 当然本着对自己负责和对公司负责的一个i额态度，我压抑住了心中的怒火，和蔼并带着微笑，心中却夹杂着各种骂程序员的想法和客户说：“哥们，你们这速度用的起来吗?”, 于是乎那哥们方法见到了如来，眼中饱含泪水，而又无奈的说道：“说的好.....”.
就这样我决心要看下系统入库的代码，决定查找下问题出在哪里......但是若是程序员都知道，从何而起？ 有些问题只有在大数据量才发生，客户那边有我们这边又不会重现，不会重现就不能对症下药。
当然凭着业界良心，还是弄到了他们的数据，数据库备份了几次都是数据不完整，但是最后还是好了。 问题是重现了，但是怎么弄呢？ IIS端保存逻辑代码有几千行，要我如何是好。若是以前的我，也尝试着不断的大debug的方式，进行查询。。。。但是你懂的，后果会很严重。 在自己的电脑中无意中再次看到了 dotTrace ，试想着能否在IIS进程中进行监控呢。。。。抱着试试看着的态度，我安装了，然后进行监听， 你妈 感动的泪水都流出来了，啥都不用说了！一万个赞，问题直接定位，如下图结果： “工欲善其事必先利其器” 是很有道理的
dotTracePerormance 工具