服务器集群负载/性能/压力测试
最近半年都在搞这个，有高手分享下这方面的经验么？整个流程可以被这样描述：用户 -> 客户端 -> 登录服务器 -> 用户 -> 在线服务应用 -> 数据库/Memory CacheD -> 在线服务应用 -> 客户端 ->用户
在线服务应用里提供了200个左右的API，每个API的调用可能会查询数据库1-5次。
架构0：无负载均衡无拓展
1台验证/登录 (Manager)
1台在线服务应用 (Application)
1台数据库 (DB)
1台Memory CacheD
之后在此基础上针对在线服务应用和数据库进行拓展并实现负载均衡:
Application:
软件拓展：从1个进程拓展至16个进程（服务器支持超线程可以当成16个core来用）
硬件拓展：从1台拓展至3台
负载平衡：在Manager实现Application的地址+端口轮询
DB：
数据库集群：在2台物理服务器上部署虚拟机分别安装LVS，SQL Node和Data Node
负载平衡：前置DNS轮询2个LVS
=====================
要求如下：
给出模拟X万人在线对服务器造成的负载的测试策略
给出负载/性能/带宽的测试策略
[ 本帖最后由 Aimbot 于 2010-7-2 11:21 编辑 ] 你要问什么？:o 我不是写在帖子里了么？
x万人同时在线对服务器造成的负载模拟
测试报告里要包含哪些方面的数据和分析 你写的是给出报告 我的天呐。。。
原来公司搞这个 不过没多久就走了
现在在开发公司不涉及这个，你都搞半年了还对我这么凶，我怕被喷:( 没有做过 求教... 我看到过的报告大概包含这些，可能不专业哈
各时间段各服务器的内存、CPU使用率
人数多少的时候服务器正常、达到饱和、崩掉
服务器在何阶段时客户端表现为卡机、延迟，程度有多大
包括地图的压力（比如客户端很卡是因为大量人物在出生点，随着级别升高，分流后慢慢好转）
不同时段带宽的使用率，数据包是否正常
[ 本帖最后由 星空物语 于 2010-7-2 21:58 编辑 ] 这么怎么感觉是在运营之前做一次 然后运营后继续做并且每过一段时间就要提交的东西呢？否则也不会测一年的吧？ 楼上看的是游戏运营方面的报告吧？对我没什么帮助不过还是谢谢分享。 你是搞哪方面的？ 啊？测试啊。。。。不过不是运营公司搞测试的:$ 很好很强大，刀片服务器矩阵组... 擦，哪有那么多预算用ibm的服务器做测试啊。服务器品牌是dell的，双Xeon，32G内存惨兮兮的过日子，2台i7拿来做测试分析的机器只好可怜巴巴的用部门预算买。
当然比开发环境要强很多，据传有个standalone的开发环境配的是p4.。。
坛子里的高手呢？ 云层老师现身说法下？ 如果是游戏的话即使开发也是要以运营为最终目的的吧 原帖由 Indisorder 于 2010-7-4 03:51 发表 http://bbs.51testing.com/images/common/back.gif
这么怎么感觉是在运营之前做一次 然后运营后继续做并且每过一段时间就要提交的东西呢？否则也不会测一年的吧？
原帖由 星空物语 于 2010-7-5 22:37 发表 http://bbs.51testing.com/images/common/back.gif
如果是游戏的话即使开发也是要以运营为最终目的的吧
看看我帖子的问题吧，跟运营没关系的。运营用的东西1天就能搞定：每x分钟查一次数据库看看有多少人在线，带宽这种不至于复杂到要搞半年还没搞定吧。 个人觉得了解策略,首先要了解该系统的预期是多少,按照行业经验算出万人在线时大概相当于多少的并发量,在这个并发的情况下,查看交易的响应时间是否满足你的预期,查看交易的成功率是否正常,会不会出现大压力情况下大面积出错的情况.
1.从你的意思来看,应该是调用api来发起对应的交易,接口的话一般处理速度会比较快,建议响应时间应该低于1秒.
2.这里面交易很多,有200多个api,可以找交易最复杂的(比如调用5次数据库的或者查询库数据相当大的)以及最常用的场景交易.
3.可以考虑系统使用的极限来判断负载均衡,首先在单台的情况下,测试系统的硬件情况,CPU IO 内存等,一般是CPU最先达到瓶颈,记录下这时候并发的大概值.线程增加到2(可以理解为服务数从1个变成2个么),用同样的并发查看软件方面会不会自身会消耗较多资源;再增加硬件方面,同样压力,看负载是否能均衡分配到2台,以此递增.
4.带宽方面建议不多,可以查看交换机和压力机的情况,判断瓶颈在何处,比如交换机由百兆换千兆时,性能有没有明显提高.还有单台压力机大并发情况自己的网卡也会造成瓶颈,建议注意.
具体情况不是很了解!!就写这么多!! [*]原帖由 lwj345 于 2010-7-12 17:49 发表 http://bbs.51testing.com/images/common/back.gif
个人觉得了解策略,首先要了解该系统的预期是多少,按照行业经验算出万人在线时大概相当于多少的并发量,在这个并发的情况下,查看交易的响应时间是否满足你的预期,查看交易的成功率是否正常,会不会出现大压力情况下大面 ...
x人同时在线的并发量我们通过对一些真实数据的统计学算法已经估算出来了。现在想要尝试解决的是测试精度和系统性能模型.
现在的难题主要有2个：
1. 并发量的精度控制：用X次/秒还是X次/10秒或是X次/每分钟抑或是X次/百毫秒或者更精确？
2. 系统性能模型：什么情况下可以被认为是过载了？
=========================
某个单元测试用例和结果的描述
=========================
A. 附件中的第一图是某个单元测试的流程模型。http://www.testwo.com/attachment/201007/14/6769_127910405013LR.jpg
[*]abcdefg指的是某一个API在理想测试精度（x次每时间段内可以是10次/秒或者10次/每100毫秒）。[*]在测试的第一阶段（准备阶段）我调用了很多API因为每个API之间的依存关系（就像如果你要创建人物你必须先登录你的帐号），以此来满足正式测试阶段我所需要的xx次API X的调用条件。[*]在测试的第二阶段（执行阶段），给定数量的API X在理想的时间间隔内被调用。[*]最后的收尾阶段将会调用一些API打扫一下测试环境。
B. 附件中的第二张图是在100毫秒精度下的测试结果。
http://www.testwo.com/attachment/201007/14/6769_1279104050sQ2q.jpg
[*]横轴是时间轴，单位是100毫秒。[*]柱状图是每100毫秒的并发请求数量。[*]线图是响应时间。
C. 附件中的第三张图是对图二的统计学分析
http://www.testwo.com/attachment/201007/14/6769_1279104052jfmL.jpg
[*]横轴是每100毫秒服务器端正在处理的请求数量（注意：是服务器集群正在处理的请求数量而不是发起的请求数）[*]纵轴是对应的响应时间
========================================================================
回到我们想要讨论的问题：
1. 并发量的精度控制：用X次/秒还是X次/10秒或是X次/每分钟抑或是X次/百毫秒或者更精确？
2. 系统性能模型：什么情况下可以被认为是过载了？
========================================================================
1. 并发量的精度控制：
A. 显而易见的，我们的数据库集群的处理速度是微秒级的（1秒等于1百万微秒）。
B. 连接池技术的应用提升了数据库性能的弹性同时也使得测试更加富有挑战性。试想一下，假设并发请求数（假设100）控制的精度为1s，可能会造成在0-100毫秒里并发了80个，还有20个是分布在最后900毫秒内完成的，结果造成在某时刻数据库的连接数变大，导致平均响应时间过长，结果在一个10秒持续并发的情况下引发了雪崩效应。。。
-> 追加的问题3：同学们在测试的时候使用的时间精度是多少？
2. 系统性能模型：
A. 对系统过载的判断：我们是不是可以理解在给定的并发数前提下，如果响应时间逞线性的增长就可以被判断成系统过载？并以此尝试找到一个响应时间几乎不变的最大并发数作为系统过载的边界值？
B. 还是系统过载的判断：假设每秒并发数为100，持续并发20秒。如果前5秒内的500个请求在第6至10秒返回。是否可以据此认为系统未过载，并以此找到一个最大并发数作为系统过载的边界值？
->追加的问题4： 同学们你们倾向于第一种说法还是第二种说法还是有其他的方法？
[ 本帖最后由 Aimbot 于 2010-7-15 12:31 编辑 ] 来几个高手讨论下啊！！！！！！！:@ :@ :@ 抛砖引玉--
1. 以1s为单位，原因如下：
1-1. 显然，测试工具的开发难度随着测试要求精度的提升呈指数级增长。
1-2. 测试数据的精度要求越高，其它非人为控制的因素对测试流程的影响也相应会被成倍放大，例如：在传输过程中发生的网络延迟等等。
1-3. 测试作为一门实验科学，更需要在可接受的误差范围内给出可接受精度的数据结果。
因此相较于无限度地提高测试精度并希望以此为依据来获得一个十分准确的结果，在准确度，易开发度和误差容忍度之间找到一个平衡点，然后尽可能多获取各种不同参数下的测试数据，通过统计学来逼近真实的结果会是一个更为可行的方法。
2. 我的意见是，综合考虑，判断系统过载的标准可以参考：
2-1. 业务平均响应时间过长
2-2. 业务处理失败率过高
2-3. 95%的响应时间分布高于可接受值
2-4. 负载数目的上升引起的系统性能下降速度过快
2-5. 系统事务处理队列的持续堆积（同你的2-A）
等等…… 先说明我没有专门研究过，我只是说说我的想法你看看对不对哦，如果说的不对别喷我哦:)
1：目前能测的是在多少精度时候服务器承受不住，但我们不可能知道具体真实的精度，所以第一个问题不可能有人知道，也没有更加准确的值。我们只能那服务器最大承受的数值去报告，如果压测时达不到标准只能换更好的设备。
2：我觉得开始执行的API对下一个执行的APi不能造成不合理的影响才算过载，如果超时但是完成的话不算过载。
[ 本帖最后由 cncnily 于 2010-7-15 09:42 编辑 ] 原帖由 planescape 于 2010-7-14 23:27 发表 http://bbs.51testing.com/images/common/back.gif
抛砖引玉--
1. 以1s为单位，原因如下：
1-1. 显然，测试工具的开发难度随着测试要求精度的提升呈指数级增长。
1-2. 测试数据的精度要求越高，其它非人为控制的因素对测试流程的影响也相应会被成倍放大，例如：在传 ...
1-0. 如果并发数小且持续并发时间短的话,精度的差异就体现不出来。假设1s的并发为100，持续5秒和1秒并发1000，持续10秒由测试精度造成的差异就非常明显了。
1-1. 同意，丫是tnnd很难。
1-2. 局域网千兆交换机standalone的延迟是在微秒级的。但是我同意你的观点，是因为如果在一台物理机上启动x个虚拟客户的话，这台物理机cpu做进程调度就会影响测试精度。
追加问题5： 同学们一般都在一台物理机（请描述配置）上开多少个虚拟用户？一次测试总用会有多少虚拟用户参与并发？持续时间是多少？
2-all. 首先响应时间长，速度慢一般都是由于在线服务应用到数据库的连接池上线过大造成的。你可以做个实验，建立1000个到数据库的长连接，然后你调个select试试就知道了。其次，失败率可能最终归咎于在线服务应用自己写的不够坚挺造成的，特别是多线程。。。
追加问题6： 同学们测试的数据库应用（请描述大致的目的，比方说一个大型购物网站或是大型MMO游戏）连接池的上线一般都是多大？
页:
[1]
2
