今天又开了1个多小时的会议去讨论一个不是那么明确的问题。在会议上经过多次的提问，我发现了我们项目组存在的一个很严重的问题--言之无物！
开始的时候我们讨论为什么邮件延时的解决方案。发送一个邮件大约的耗时如下：
1、读取邮件数据（2～3ms 每1000条）
2、生成邮件（20-50ms每次调用，每一次发邮件都需要读取一次）
3、IO操作（包括网络）（网络不出错，20ms，网络出错1000ms）
4、更改数据状态（50ms每条）
5、写日志（60ms每条）
开始的时候，项目经理说，把4和5优化一下，优化成批量更新，这个没有问题，接着就把2也优化一下，改成每个模板只读一次。不是每次都读一次，好吧也没有问题。然后讨论着讨论着，就到了典型的研发开会，越来越复杂，有人说4和5直接先写到文件中去，等空闲再去写回数据库，有人说先生成所有的邮件，再去发送（因为邮件其实是有重复的）。后来我幽幽的问了一句，3失败率是多少？不知道。大哥，你怎么可以不知道，如果失败率是2%那么发送时间就会增加一倍，那如果更高了。后来有人说优化4（4分两步，一步是更新状态，另外一步是移到历史表），在第一步的时候将数据状态改为发送状态，然后再用另外一个线程移入历史表，或者在第一步的时候将数据移入一个过渡表，然后再移入历史表。这时候我又问了一句，是更新快还是移走快？有人说更新快，有人说移走快。我又说，可以叫DBA分析一下，oralce有这个功能，没人说话。。。再或来的讨论，发现，瓶颈根本不在我们的系统，而是另外一个系统，那个系统的邮件量是我们的10几倍。。。于是我们决定把那个系统隔离开来，留待以后做优化。
看完上面的经过，我不知道你们有什么感受，有什么想说的。我当时想到的就是为什么我们开会就是没有人会拿数据出来说话？为什么都是想当然的去优化，要知道数据才是最重要的呀。有人说，上面不是给数据了吗，但是请想一下，对于一个一天发几十万邮件甚至上百万邮件的系统来说上面5点的数据是没用的。因为这个时候我们需要的是一个可接受的，大范围的抽样。比如我问得，失败率是多少？
有时候分析问题，把数据拿出来了，你会发现这个世界廓然开朗。问题已经不是问题了。
ps：博客园的memcache缓存好像有问题，用wl写了之后打开后台看不到文章。。。
