构建高性能的ASP.NET应用（四）-性能的优化的目标

到现在为止已经说了很多与调优相关的思想，讲了很多的很多人认为“没有实质性作用东西”。

为了说明我为什么要苦口婆心的要说这么多，我这里举一个我们自己的例子。如果我们现在要大家去写一个功能软件，大家认为首先应该去做什么？

估计很多的人大致的知道了功能之后，就立刻跳下去趴在电脑前面急急忙忙的开始写代码。如果是这样，估计很难提高，写程序，做软件，代码只是最终的形式，其实最核心的就是写代码的思路，设计的思路，为什么要这么做。而代码只是思路在电脑上面的表达的具体的形式而已。没有任何思想的代码，杂乱无章的思路，最后会把自己完全陷入困境。这也是很多的技术人员很难提升的原因。

其实性能调优，不是搞几台服务器，搞什么负载均衡，改几个多线程就实现的。这些都是指最后分析出来的结果。为什么要搞负载均衡，是否非得要上N多台服务，都是要清楚里面的原因的。

性能优化，不是什么不得了的东西，其实它就是一门实实在在的科学，就和我们平时看到的数学，物理一样。只是我们一直认为它很神秘，其实这在国外，已经是个正式的学科了。

既然是一门科学，肯定就有自己的方法和思想的。这些看起来很虚，通过我们在国内做了这么多的性能优化的方案来看，很多的理论和方法一点都不虚。

不知不觉，有啰嗦了一大堆。抱歉。

言归正传，我们来看看两个个方面的问题：目标设定，迭代进行。

目标设定

很多的人都有误区，一提到性能优化，就是要去把程序，网站搞快。这也是我们常常以为的“优化”。

其实，我们可以进一步的想想：为什么要去优化？很多人肯定会回答：慢啊，卡啊！

进一步的提问:为什么会慢？这个时候，很多人就会开始支支吾吾，东扯西拉。在我们为很多的公司搞企业内训的时候，每当提到这些问题，很少有人可以说的很明白的。

其实，简单的说，就是：我们现有的资源不够，无法满足站点，程序正常运转的需要(资源不够，原因有很多，一，可能是因为我们没有很好的利用资源，例如我们的代码写的不好，导致浪费了很多的内存和CPU等；二，可能就是我们的代码写的不错，程序各个方面都不错，但是确实因为现在的业务量和用户量超过了我们当初的估计，例如站点火爆了)。例如，我们的站点的访问量很大，每个用户都要需要一定的资源去完成他们要做的事情，但是我们提供的资源不够，

例如服务器的内存不够，导致了不能处理这么的用户的数据，有可能是数据库的问题，无法及时的处理这么多的数据请求等等。

所以，性能优化的一个最重要的目的就是：用尽可能少的资源去做尽可能多的事情，依靠技术和人的能力，从最小的成本获取最大的效益。这才是“优“的真谛。而所谓最后的”快“，只是一个表现而已。

反过来想，如果站点确实很快，但是付出的代价是：买了几百万的硬件设备，买了N多辅助软件，请了一大批的人，从公司，老板，投资人的角度来看，这个付出与回报的比率是多少？

所以，性能优化，不仅仅只是技术层面的问题。再说了，优化，本来就是永无止境的过程，我之前也说过“没有最优，只有更优“。例如，你认为站点的响应速度是1秒很快，但是我们依然可以不断的优化，把响应的速度搞到毫秒级别。问题是：我们花这么大的成本把时间从1秒减小到毫秒，值不值得？

我们技术人员总是喜欢“追求完美”，认识什么都有要搞的最好。这让我想起我们之前创业时候的一个误区，总是因为把产品的功能搞的很完善，总以为功能强大用户会买账，最后都是自己买账，一套都卖不出去。

这里，很多人可能就迷惑了：那么性能优化的目标到底是什么？

很简单：为了获取最大的效益，在业务允许的范围内，在资源使用优化的情况下，尽可能的快。前者是从商业考虑，后者是从用户角度考虑。

其实站点最后资源使用的时候优化，很多的时候，都是由于我们技术人员本身引起的，说的更加通俗，就是我们的代码引起的。我们曾经遇到的有个案例，让我们感到很“无力“：软件是否买的第三方的，数据库是MSSQL。软件的源代码是没有的，但是我们可以动数据库。后来我们把数据库做了很大的优化，通过压力测试和性能测试，都是很好的，但是就是程序在访问数据库的时候很慢，后来我们通过反编译他们的代码，发现代码中对数据的获取和处理的方式让人无语。这真是硬伤，因为程序我们动不了，最后我们采用了很多变相的方式来初步的缓解（这不谈了）。

好了，我刚刚说到了“快“，其实“快”是个很抽象的概念，什么是“快“，不好说。有人说“越快越好”，这等于没有说。

其实，从用户体验的角度来说，我们可以把“快“分为三个段：1秒，5秒，10秒。

• 如果用户浏览站点或者程序的时候，响应时间在1秒以内，那么，用户会感觉非常的爽，流畅
  
• 如果在1到5秒，用户的流畅的感觉会随着时间的变长，慢慢的变差，但是用户依然可以接受
  
• 如果响应实现在5秒到10秒，用户就开始有点不爽了，有想走的念头。
  
• 如果是10秒以后，用户估计以后再也不来了，除非是有不得不来的理由。
  
  

所以，正如很多人说的“快“也是我们的目标，但是最终的目标是什么我们上面说过了。

这里要注意，不是所有的程序都要按照上面的标准来，最忌讳生硬的套上面的标准。不同的站点，标准不同；甚至是同一个站点，不同的功能模块的响应时间也是有不同的要求的。例如，在电子商务站点中，其余的功能可能慢点，但是支付那一块一定要快，因为此时是收钱的时候，此时不快，更待何时！

那么，这又让我们很多的朋友迷惑了：你到底想说什么？

很简单，性能优化的时候要设定一个目标。例如，你本来就是一个企业的内部站点，用户就是公司内部人员，你没有必要非得把站点优化到毫秒，以为站点慢一点，大家都可以接受。及时你的站点是个互联网的大量用户的站点，你还是要清楚你的目标。

也就是说，你不能随随便便的就拍着脑袋说：站点的响应时间要在1秒以内。

这是要人命的。因为很多的站点由于种种原因，它的极限已经无法达到1秒以内，你还要优化到1秒以内，你是在给自己挖坑。就好比一个病人，在健康的时候，跑步的速度是5米每秒，它的腿骨折了，你是他的医生，然后他的家人就说：我出了 钱的，你要给我治好他，我希望他康复之后，跑步的速度是10米每秒。朋友们，用脚趾头想想，也知道这是不可能的。

所以，性能优化的目标，一定要根据你的业务而定。也就是说，在站点开发的时候，你们的客户群体是谁，他们的一般的期望是什么？

可能这一点在国内很少触及，在我们参与的一些国外的项目中，在我们开始需求分析的时候，会有一个性能的分析，在这里，我们会给出某些功能的一些性能指标，如下：

同理，在性能优化的时候，不管通过什么方式，你要找到这么一个准则，否则，你就陷入了没完没了的沼泽。