Let's Go!

学习loadrunner性能测试建议路线图

上一篇 / 下一篇 2009-05-20 21:27:18 / 个人分类：LoadRunner

沙龙交流前自己准备的容量规划方面的问题列表，呵呵，也期待业界这方面的专家指点。

1 瓶颈资源到达75%以后，容量预测偏差难以衡量，预测准确率陡降。
现有容量规划软件包容这种情况？或者如何做能提升这个区域的预测准确度

2 SAP 的容量规划工具可容忍偏差范围多大？
3 SAP 内部有自己的监控软件么？包括应用级别的监控。

现在的软件更多针对应用服务器、web server和os层面的监控，但对应用本身的监控是缺乏的

假如没有这些细粒度的监控数据，SAP 如何更好为用户行为建模？

4 SAP 容量规划软件建模算法是什么？是否为排队网络？

可以调整客户到达分布与服务时间分布等参数？

5 BELL实验室网络测试发现，用长相关或自相似随机模型比排队网络模型更符合web 网站客户到达分布? SAP 容量规划软件针对更合适的模型做调整么？

6 SAP 容量规划软件内部有what-if 假设分析么？直接支持针对内存或者硬盘的what-if分析？

7 SAP 针对跨机型的容量规划如何做?

尤其是sun公司不参加TPCC评估后的机型。

8 如何做容量规划效果的反馈

9 做容量规划的团队组员有几个，都是怎么样的专业背景（数学？计算机?)

10 开源容量建模工具要求手工采集非常多数据，必然引入较大的误差？对于这种状况，有何建议

经过和SAP 工程师交流。负责容量规划的工程师和负责测试的不属于同一个部门，容量规划工程师面对咨询公司，提供硬件建议。

  国内的SAP工程师更多是规划软件的应用者。SAP 软件相对成熟，且部署的机型相对单一。目前容量规划结果满足需求。

  SAP有商业逻辑的监控。SAP容量规划软件采集生产系统数据建模，在web页面上输入参数，降低建模门槛。目前SAP容量规划软件建模依赖经验值，而非各种复杂的数学模型。当下没有必要研究开源建模工具。

  SAP软件用内部开发的语言开发的。有很好的扩展性。

  由于上述背景，我自己碰到的一些问题就没有很深入交流。

  目前阿里巴巴需要自己建立模型，并需要长期校准模型，另外由于需求、应用的多变，容量规划的门槛依然需要具备较高的数学建模与计算机性能分析方面的背景。

容量规划沙龙4原则以及个人理解

个人觉得今天容量规划沙龙最核心内容即4原则

1)经过良好调优的系统才容量规划
2)可扩展性好的系统才做容量规划
3)人人有容量规划意识。执行T-shirt sizing是一个巨大进步
4) 最关键的事情是测量

其他的还有
5) 用真实的产品数据做容量规划
6) 特别区分对待的容量规划场景
7) 追求响应时间与成本间平衡

欢迎其他朋友补充。

以上的点说得都很实在。
根据自己的实践做一个发散说明

1)容量规划有一个难点：在系统扩容和调优之间取得平衡。
就是停止调优的标准是什么？

目前我是根据经验值判断特定的硬件、配置参数支撑一定的访问模式、数据量、并发数、吞吐率且满足响应时间等SLA指标。另外，检查系统不存在core dump或者大量连接超时，日志无异常等。
有较大的主观性。

2) 系统扩展性良好。

根据了解，SAP 没有结合性能测试做系统的可扩展性判断。呵呵，也许SAP架构很多年稳定了，没有必要做这个事情。

我们实践中，会设置多个场景执行性能测试或者了解系统架构判断。
如是否采用多线程技术？集群是否采用session技术？

建模采用的数学模型一般有很多的假设，就是公式成立有很多前提条件。性能测试需要判断结果是否违背了假设。同样预测时，也需要判断是否背离假设

3) 人人容量规划意识

从阿里巴巴的角度看，应该是从架构设计权衡系统扩展性、开发加入代码性能探针、性能测试判断是否该停止调优、运维部门长期跟踪反馈性能监控数据以及采购规划、数据仓库平台采集PV、运营部门预测下一年业务增长速度等多个环节。

据目前看，要走的路还很长。
对阿里巴巴而言，在网站购买的大量便宜的PC server背景下，容量规划的收益与成本不是足够一目了然，以及资源紧缺是最头大的问题。

与前同事聊天，目前广东电信研究院的容量规划的驱动力不足是当下最头痛的事情。

4) 第四个观点：测量是最关键的。

这个论点放到阿里巴巴。我个人有不同的看法。
测量是很重要。个人认为借助测量到的数据，如何构造一个合理的容量模型、如何校准模型符合实际情况更关键，否则预测的结果偏差过大导致没有太多的参考价值。

另外，目前的商业工具或者开源工具都存一些不足，如何对工具做二次开发完善，也是一件很有挑战性的工作。

容量规划工具

1 开源
  java model tool
  pdq

2 借用定律

A
  little's  law
         N = X * R

N = Number of requests in the system
X = Throughput
R = Response Time

B  Utilization law

U = X * S

U = Utilization
X = Throughput
S = Service Time

c Stretch Factor

Stretch Factor=1/ (1-U) =response time/service time

where U is the utilization of the server.
The analytic formula for estimating stretch factor assumes the following:
There are an infinite number of customers
The arrival times are exponentially distributed
The service times are exponentially distributed

3 商业工具
teamquest，国外SUN 公司、国内广东电信研究院用
bmc performance assurance，上海电信研究院用
原来Mercury工具也和一厂商有容量规划工具的合作的现在没有了

其他的请各位朋友补充

阿里巴巴容量规划设计初步说明

针对今天容量规划沙龙由于时间关系没有回答的问题--阿里巴巴的容量规划设计方案，做一个简单的说明。
呵呵，我去年10月份这个问题写了很长的技术方案书。大致思路如下

容量规划方案贯穿软件开发整个流程。
针对已经上线运行的系统

1) 性能需求：从数据仓库平台或者web 日志分析工具awstats分析access_log日志得到用户访问模型；
从监控中心(cacti 和nigos ) 获取服务器资源消耗数据，如cpu,io,内存，网络等细节，得到系统资源消耗模型。
如果要求更细致的颗粒，可以在应用层加以监控，如jmx获取JVM 的性能；oracle db 通过statspack获取性能

2) 性能测试与监控

  建立性能测试场景（用户、数据量、硬件、软件系统等)，执行性能测试；获取当前系统的承受负荷以及获取临界值。
  经过确认，系统经过良好调优、且无伸缩性问题后。可以按照容量规划理论来看，寻求伸缩因子。其=1/(1-利用率%)。

  比如找到瓶颈资源临界点，如50%资源消耗，75%资源消耗。一旦伸缩因子>2后，容量预测的估计偏差难以估计，因为已经不是线性关系

3) 建模以及预测

采用开源工具java model tool或者 pdq （2工具可以从sourceforge.net下载) ，建立客户到达时间分布与服务时间分布等众多容量规划参数，模型可以选择排队网络。流程：建模->MVA求解- 与性能测试结果对比校准模型,迭代逼近误差容忍范围。

  what-if 预测可以从增加并发数、合并/拆分应用、变更硬件等角度考虑

  呵呵，当然也可以尝试找teamquest临时 license。

针对新开发系统：

1）性能需求：可以定义得更加苛刻一些。
参考同类系统，初步用TPCC 等参数比较。

实际上，这样可能误差较大。
另外，需要架构师评估系统是否有代码保证最大连接数限制

2)  性能测试与监控

   场景细分更加细致，获取新系统承受负荷以及获取临界值。

3)  建模与预测

   模型校准的工作量比较大。
   需要长期与生产系统实际的用户行为、系统资源消耗、响应时间、吞吐率等SLA指标比较，修正容量规划模型。
这个过程可能很漫长。

让我们更多关注性能测试高端领域

51testing.com和阿里巴巴6.14将专题介绍《容量规划》。在国外，有很多企业已经应用得成熟，比如sun 公司，大家可以看到SUN有蓝皮书介绍

但国内，这块只有一些大公司投入兵力作这方面的实践。据我所知广东电信研究院、上海电信研究院在作，SAP也在做。  阿里巴巴运维部和质量保证部也在这方面做了一些探索。

纵观论坛，目前性能测试很热门，但另外一些高端话题相对比较冷落，呵呵。原因很多。

一些比较高级的话题，请参见http://www.51testing.com/?13997/ ... e_itemid_75169.html
其他一些资料请参考
  Cmg.org
http://www.hpl.hp.com/techreports/2004/
http://www.iturls.com/softwareresource/SW_709.asp
http://www.bmc.com/offers/performance/whitepapers/
http://www.sun.com/blueprints

  有兴趣的同学请 capacity planning 作为关键字google

期待更多这些领域的高手分享他们的实践经验