每一个应用程序到了一定阶段由于这个或者那个原因总是需要进行优化的。其中最主要的原因应该是：数据量的增加。但是我们应该怎么样去优化一个程序了，我们优化的方法又是否正确了。这让我想起了一个故事。
一个操作系统的编写人员把系统中的一个基本函数（调用率为50%）的效率优化了一倍。但是系统性能却没有得到应有的提升。原因在于他优化的函数式nop指令，也就是在系统空闲的时候调用的函数。
这让我想起了前一段时间我们系统所做的优化。由于系统发送邮件的数量越来越多，所有邮件堆积的数量和延时也越来越大。这个时候我们使用了基本的优化方法，多线程去发送邮件（多个线程同时连接邮件服务器）。在测试线上的得到的性能提升是非常的大的，但是到了生产线，去经常有连接超时，导致了一些奇怪的问题。最后我们经过和研究和咨询发现，原来邮件服务器在生产线上一个ip只允许同时5个连接，多了就拒绝。于是我们的努力也就白费了。
其实从上面的两个例子我们可以看到优化程序其实并没有我们想象的那么简单，为什么了？因为很多时候我们面对的并不是技术上的问题，而是业务上的一些变更，而这些变更又往往是我们所不熟悉的。那么我们应该怎么样优化程序了，我觉得以下几点可以参考。
一、优化之前先弄清楚性能的损耗情况，和可以优化的情况。一般情况下，我们遇到的都是比较乐观的情况，也就是性能损耗最大的地方就是可以优化的地方。但是，且慢，这个“地方”是一个可大可小的词。为什么了？因为如果宏观一点来看你会说我们在进行什么操作的时候会导致性能降低，但是如果微观一点来看你会说插入数据的时候会产生大量的block，数据库IO过大，导致操作时间过长。这个时候你该怎么样去优化了？
二、选择适度的优化粒度。接着上面的问题，我们可以看到，如果从微观来看，我们选择的优化方法可能是对数据库进行必要的改进，比如，多点commit。但是如果从宏观的角度来看，我们选择的就可能使批量提交。这两种方式各有各的适用地方。我再举一个例子。
我们的项目有一个地方需要向用户推送客户提供的html文件（包括图片，css，js等）但是由于业务原因，我们必须屏蔽掉所有文件的外链和处理所有文件的相对路径引用。这个功能很慢，慢的要死。当时有人提出的方法是改进正则表达式，以提高匹配速度。我提出的是缓存处理结果，所有html文件之处理一次，处理后的数据放到磁盘上，以后再读的时候就不需要再进行处理了。如果你是经理你会选择哪一个方案了？
三、选择适当的优化方法。其实优化的方法有很多种，但是不同的方法得到的效果往往是相差很大的。所以在确定适当的方法之前我建议大家还是先做一个简单的demo，来验证这个方法的有效性。比如图片大小的压缩，很多人是直接使用缩放的形式来实现的，但是缩放会导致一个很严重的问题，就是图片在放大的时候会变得很不清晰。其实有另外两种方法来实现大小的压缩，一个是直接改变图片的质量，另外一个是对图片进行hsl处理。后面两个其实连demo都不用自己写，网上有现成的。
四、跳出技术的角度来思考。其实这个是我们很多人的通病（包括我自己）。我们很多时候会钻牛角尖，会为一个问题的一个方向浪费很长很长的时间。比如我们在优化邮件投递的时候就有这样的一个情况，一个存储过程奇慢，30秒才查询出结果（1000条记录）。于是我们就去想各种各样的方法去优化，加索引，强制走索引（这个我其实是不赞成的，因为生产库由于环境和dba的维护问题，你不一定可以肯定你的索引名称一定有对应的索引），多处理器处理等等。但是效果都不好。这个时候你会怎么想？我后来提出的方案是，一次取10000条数据，就算是取数据时间增加为1分钟（这其实不大可能的，因为其实关系型数据库取数据的条数对速度影响不大），那么这个取数据的速度也比我们本身投递邮件的速度要快了。（是不是很简单？）
五、优化的前景。其实这个是很多人都会忽略的。最简单的就是系统统计的优化，因为系统统计一般是管理人员用的最多，他们跟我们的关系也是最近的，所以我们一般也会直接选择优化查询的性能。但是，不知道你们有没有想到这样子的一个问题。这些查询他们一个月可能才用一次，充其量，一个星期两次。但是比起优化前台页面，比起优化用户体验来说优化统计的性价比是极其低的。因为很多情况下它不会给你增加一分一毫的收益，但是前台则不同。所以我们现在的产品后台很烂，以致于运营经常说这不是给人用的，但是我们的经理也只是笑而不语。
