二、架构的性能问题解决讨论

    性能问题——嗯，一个非常神圣而高深的问题的。从我刚刚开始工作的时候，至今依然是。然而我相信，一定存在一个基本的思路和方法，我以为解决性能问题的工作还是在于分解,通过分解来确定问题域。

    先介绍三个公式性能问题的公式:

    总处理单量 = 总处理时间/ 单笔请求处理时间 * 总并发数

    这个公式另一个写法为:

    总处理时间 = 单笔请求处理时间 * 总处理单量 / 总并发数

    不同的写法代表不同个关注点，适合不同类型的业务类型, 一般说前一种写法代表在线请求的，后一种写法代表后台batch。

    也有客户给明确要求系统要支持xxx并发，这个就需要了解客户的这个并发数是如何计算得来，需要通过分析客户的业务，而通常是根据总处理单量来确定客户实际的并发数。

    但无论如如何，四个变量中，总处理单量和总处理时间是先被确定的，换句话说需要关注是单笔请求处理时间和并发数，也就是降低单笔请求处理时间或者增加并发数。

    对于单笔请求处理时间，其公式为：

    单笔请求处理时间 ＝ 数据计算时间 ＋ 数据读写时间＋其它技术导致时间消耗

    很显然降低单笔请求处理时间就需要降低三个因素消耗的时间。

    1.降低单笔请求处理时间第一原则是, 只计算一次.缓存计算结果

    2.降低数据读取时间,分三种

    2.1. Global的,系统启动时加载

    2.2. Long Time, 可采用LRU方式cache

    2.2. Per operation. 第一次访问加载,operation结束后丢弃.

    3.降低数据写入时间

    例如文件写入通过buffer一次flush；对于SQL采用batch提交（hibernate的做法）。

    4 .改进计算时间，针对不同技术结构采用不同手段。

    4.1.让计算支持并发,提高性能,例如采用MapReduce的方式

    4.2.改进算法.例如数据库中的SQL改进.

    4.3.减少不必要计算时间.

    5.减少其它技术原因导致的消耗

    如JVM的GC导致性能消耗等

    对于总并发数，其公式为：总并发数 ＝ 单机服务器并发能力 * 总并发服务器数

    那么如何确定那些因素需要调整呢，在于两个方面的分解：

    1. 业务层面

    业务层面只是指通过业务行为分析, 把性能问题分解为不同的部分,每个部分面临性能压力现状和目标,最终确定需要优化的问题域.

    业务层面分解包括4个内容: 功能, 内容,时间和区域.最重要的是前三个.

    以ebay为例, ebay对于前端功能划分划分为70多个功能,不同的服务器处理不同的功能.

    内容是指内容热点,比如对于search来说,就按体育,数码,音乐等划分,不同内容有不同热点数据,以及不同搜索关键匹配.

    时间, 时间是一个非常重要的因素,在一些特点是时间段呢,性能的要求会非常高.比如下半夜的访问点击量和白天的就有不同.对于一些batch来说, 月末或者年末处理的单量就有明显的提高,比如分红险的记息,平时每天只有7000单,而年末会有12w单.

    地点划分,不太常见,不过也有助于分配计算资源.

    业务层面的分析不仅是确定问题所在,还是确定优化的策略.比如有一个batch计算,执行时间比较长,而通过业务分析,发现该计算只针对特定的业务, 系统全部有效单量是12w单,而符合计算要求的只有3000单,只要加上一个前置判断就可以免除无谓的计算,运行时间减少数个小时(大约0.2秒一单).

    2. 技术层面

    系统建立时技术结构,通常一个系统结构如下:接入网络,Web服务器,应用服务器,以及数据库服务器.

    在这样结构下，要小心的分析和验证系统性能的瓶颈，需要优化Web服务器，或者提高数据库并发能力等等。这部分网上的资料非常多。