系统性能分析备忘录

系统性能分析分为两个方面：阻塞因素和系统开销。

主要的阻塞源有：

数据库锁。TRS系统采用SYBASE，当时为提供行级锁，页锁粒度大产生的阻塞严重。一般说，大粒度锁开销小阻塞大，小粒度的反之。

系统采用何种粒度，要依据业务情况综合考虑。在客票系统环境下以采用小粒度锁为好。

线程互斥。多线程环境有很多共享资源，使用共享资源必然有互斥。与多进程相比，开销较小阻塞较多。

大量进程或线程争夺CPU或内存或其他资源造成资源调度拥塞。

连接阻塞，大量客户端同时发生连接产生阻塞，建议长连接和半长连接，而不使用短连接。

系统开销分析：

现特为三层C/S模型进行系统开销分析。系统开销分为如下层次：

时间金字塔模型，把一个业务处理过程的时间开销分层归纳如下图：

Client层：不管有多少客户端，它们是完全并行的，对系统总吞吐量不会有影响，只要能在规定时间内完成操作即可。

TUXEDO应用服务器层，具有优良的可伸缩性。它适宜进行高性能的计算，完成主要的应用逻辑处理，它接受客户端请求，经过复杂的数据访问和逻辑处理将最终结果返回客户端，相对于二层C/S模型，大大减少了与客户端的交互次数和数据传输量。它可以由多台主机构成，每台主机可以有多个CPU(core)，在OLTP环境下，所有这些CPU都可以充分并行操作。TUXEDO采用服务器池技术，对于大量客户端连接，系统只配备数量有限的服务器进程。客户端只有请求服务时才占有服务器进程。当服务请求太多而没有足够的服务器进程时，请求被排队。这就意味着，整个系统里只有有限的进程在活动，避免了成千上万的进程争夺资源造成系统拥塞。既要保证系统能够充分利用处理机资源，又要避免调度拥塞，配置多少服务进程好呢？我的经验是：每核5个进程。测试结果表明，超过10，系统性能就明显下降了。按照这个建议配置，不要担心计算开销，因为最多只有5个任务争夺一个CPU，实际这个争夺并不激烈，因为即使这5个，还有的在等待访问数据库和网络，真正的竞争率大概就是1.几。

TUXEDO的服务排队调度效率极高，不管是当年的压力测试还是后来自己做的测试都表明这个系统极好的线性扩展性。

数据库引擎层（RAC）：这层承担数据存取，要求提供高性能、功能丰富、安全可靠、数据一致的数据访问服务。这层具有有限的伸缩性。可以有多台主机构成RAC，每台主机可以有多CPU。主机应有强大的IO能力。主机不能太多，否则不能提供线性性能扩展。因此通常选用高性能高可用性的高端服务器。这层和存储层是系统最昂贵的核心设施，它关系到整个系统吞吐量，用多大造价完成多少吞吐量是表征设计和应用水平的标尺。善用数据库引擎是设计关键，充分发挥引擎优势，减轻引擎负担是提高系统吞吐量的手段（前边讲的保持游标的技术就是基于此）。

存储层：不多说了，提供容错的，高性能的，易扩充，易维护的数据存储手段。关系到系统吞吐量。

计算和存储（查表）的关系：我们都知道一些复杂的运算，可以通过建立一些中间结果表达方法，减少计算量，加快运算速度。就是空间换时间的概念。当然，中间表如果在内存，这个空间肯定能够换回时间。如果中间表放在数据库，就得评估一下它减少了多少计算量，为此增加数据库开销是否值得。为此数据库增加的表，索引，行数，列数造成何种开销，因为这种开销基本都由引擎承担，是很昂贵的。如果几个简单的加减乘除数学运算，在C语言里只是几条指令的时间（若干毫微秒），在TUXEDO层，使用廉价的高速CPU，完全并行的处理，执行时间最短，系统开销最小。非要放在数据库里，不仅需要IO，而且引擎要处理这些语句、表、索引、行、列，所需的指令和IO量还有数据库互斥等等，即使最优化的处理，所需的开销高达数十微秒，而且是昂贵的引擎开销，直接影响了吞吐量。

比方说里程票价计算，这还是比较复杂的运算，可以测一下到底是数据库查出来快还是计算快。当然，如果是经由计算这样高度复杂。运算就可以考虑中间结果存数据库。这个问题我跟王天云教授也有争议，王教授认为存数据库太慢而主张计算，而当时他就是对的。（这个问题如今我倒觉得可以考虑数据库方案）

如此复杂的计算尚且比数据库快，那些简单的计算，如票价表，如运行图的计算，数据库能比计算快？当然如果在计算中还需要检索其他数据，不如存表了。

在ORACLE中表中每增加一个字段都有附加的开销，每一行的每一个字段在存取中都是要寻找的，这个开销可不是几条、几十条指令可以解决的。而且现在一般的数据库服务器采用高档小型机或大型机，主频不很高，执行指令的速度不是长项，多半不如微机。

所以到底是计算快还是存储快，不能靠想象。一是要理论分析，二是要实际测试。有时三层C/S模型跟两层还是有很大区别的。

一个简单的压力测试：

环境：数据库：ORACLE 10G。数据库服务器：4core，1.6GHz主频。8G内存。

TUXEDO服务器：4core，2G主频。20个服务进程。

TUXEDO客户端：同上。

三者在三台服务器，一个局域网。

测试样例：发到站查询（包括4大难题的处理）+席位申请（加锁、占票）。这是一个典型的对系统吞吐量要求最敏感的作业。

按照上车日期、站车次、上车站、下车站、席别、数量、（用途）进行席位申请。

启动1000个进程，每个进程申请5张票，共得到750张票。

测试结果：

一个进程完成任务耗时130ms。1000个任务退后台并行执行，共耗时4.5秒。

最长响应时间为0.7秒，没有重票。

结果分析：

如果系统在一个cpu的单机系统，1000个用户的完成时间理想状态应为130秒。现系统以20个进程，充分并发的线性伸缩率，理想时间为130/20=6.5秒。如果能够充分利用数据库服务器、TUXEDO服务器、网络，按照理想的任务负载比例，理论最少的时间是6.5秒/3 ~= 2.2秒。但达到理想比例几乎是不可能的。但系统能够做到理想分担的50%的效率，也是非常令人满意的了。

虽然这个简易的并发测试并非完全并发，但其结果仍然非常有意义。原因如下：

1.样例已经是十分接近实际业务逻辑，1000个进程已经代表了一个路局的全部终端。最长响应时间为0.7秒，以超过用户需求的指标要求（<3秒）。即这个小系统已经能够满足一个局的业务吞吐量的需求。实际发生的窗口争夺票额也不是完全同时的，仅仅是密集的。这个状态能够代表实际。

2..TUXEDO服务器只有20个服务进程，系统只有20个并发，再多再同时的请求也只能排队等待，同时性的提高（更加同时）对结果不会有根本改变，可能时间会更短，性能更高：

不完全同时的并行：

     |--------------      |

     | ---------------     | 

     |   --------------   |

     |    -----------------|

 |

完全同时的并行：

 |-----------------|

 |-----------------|

 |-----------------|

 |-----------------|

 |

t2只能比t1短。

这只是一个简单的普通微机模拟结果，如果我们的数据库服务器使用高性能主机，高性能磁盘存储系统，高性能的数据库引擎架构，系统吞吐量还有极大的提升空间。

结论: ORACLE+TUXEDO的体制，其性能、吞吐量是完全能够满足未来用户需求的。

在考虑计算量时，即使成千上万的客户端同时访问，都是可以按线性伸缩+并发性的思路，去预测未来的负载状况和吞吐量的。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/8804348/viewspace-622054/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/8804348/viewspace-622054/