00_性能测试计划

*移动云产品线-BAAS服务V1.0性能测试计划(2014/06/11-2014/06/17) *
一概述
移动云BAAS服务主要通过cloud+config+code实现云的能力,解放app开发者的服务端工作量,本次对外暴露http服务。1.0版本提供包括Comment、FEED、Media等7个模块对外接口约40个。目前接口功能趋于稳定,具备性能测试的条件。本次性能测试包含压力测试与疲劳测试,测算高并发大数据量下接口的响应时间和吞吐量,得出在不同配置(第一阶段只评估2核4G、8核32G两种)服务器部署下的资源利用率和接口的处理能力。对写接口、查询接口进行长时间调用监控,评估接口的承载能力。

二测试策略 
1.使用Jmeter工具直接给接口发送http请求压测。
2.因无明确性能要求,所以采用逐步加压的方式评估系统基线数据。(从50并发开始加压,当load小于1.5-2倍时的TPS)
3.为避免sql cache更真实的模拟用户,测试数据采用业务场景相关联数据。(comment、feed表数据量百万级,media等表数据量相对少)
4.测试响应时间覆盖到容器、接口处理、数据存入ots、rds、oss当中的全链路时间。
5.本次测试采用单个接口测试+混合场景形式。

三测试场景

四测试准备
1 硬件部署与参数

2 软件配置和关键参数
容器tomcat7 连接数150

3 资源安排

4 测试数据准备
采用存储过程的方式灌入测试数据。
插入用户数据的存储过程:
begin
set @i=1;
select max(id)+1 into @nextid from user; 
repeat
insert into baas.user(id,username,password,status,email,mobile,gmt_created,gmt_modified,is_admin)
values(@nextid,concat(‘user‘,@nextid),‘$apr1$LrnFGBBs$Z1/2aXAJjY1MLhpcoF.u2/‘,1,
‘[email protected]‘,‘13720140609‘,CURRENT_TIMESTAMP,CURRENT_TIMESTAMP,0);
set @[email protected]+1;
set @[email protected]+1;
until @i>size end repeat;
end
插入部分业务数据的存储过程:
begin
declare done1 int default 0;
declare done2 int default 0;
declare i int default 1;
declare userid,feedid int;
declare feeduser varchar(32);
declare user_num,feed_num,nextid,num int;
declare users cursor for select id from baas.user;
declare feeds cursor for select id,user_id from baas.feed;
declare continue handler for sqlstate ‘02000‘ set done1 = 1;

select max(id)+1 into nextid from baas.comment;

open users;
loop1:repeat
fetch users into userid;
if not done1 then
begin
declare continue handler for sqlstate ‘02000‘ set done2 = 1;
set done2=0;
open feeds; 
loop2:repeat 
fetch feeds into feedid,feeduser;
if not done2 then
insert into baas.comment(id,user_id,target_type,target_id,target_ower_id,reference_id,content,status,gmt_created,gmt_modified)
values(nextid,userid,1,feedid,feeduser,null,concat(‘content‘,nextid),0,CURRENT_TIMESTAMP,CURRENT_TIMESTAMP); 
set i=i+1;
set nextid=nextid+1; 
if i>size then 
leave loop1;
end if; 
end if; 
until done2 end repeat loop2;
close feeds;
end;
end if; 
until done1 end repeat loop1;
close users;
end
五测试实现
见测试场景
六监控指标
1) 监控服务器端的响应时间和TPS,读场景50并发20次循环响应时间< 200ms, 写场景响应时间 < 400ms 
2) 监控不同场景下,服务器的load, io, cpu 情况

00_性能测试计划

时间: 2024-11-01 11:50:47

00_性能测试计划的相关文章

性能测试计划

电子政务平台 性能测试计划 版本:[V1.0]  2015-12-11 目录 一 文档介绍 2 1.1 说明 2 1.2 参考文档 3 1.3 特殊说明 3 二 测试概述 3 2.1项目简述 3 2.2环境结构 3 2.3环境详情 3 2.4 需求内容 3 2.5人力时间 3 三 需求分析 4 3.1项目是使用场景 4 3.2登录 4 3.3提交订单 4 四 测试策略 4 五 条件 4 六 风险 5 6.1 风险因素 5 6.2 风险控制 5 2 计划审核记录 5 一 文档介绍 1.1 说明 本

性能测试计划模板

1. 简介 1.1. 编写目的 简述编写此计划的目的 编写本文档的目的是用于指导sinamail4.0系统的性能测试. 主要从测试环境.测试工具.测试策略.测试具体执行方法.任务与进度表等事先计划和设计. 1.2. 项目背景 简述本项目的背景 针对迎接2008奥运,对用户新开发的带有2008域名的免费邮箱. 1.3. 名词解释 针对本文所出现的专业名词或专属名词进行解释 专有名词 注释 业务 用户执行的某一操作 URL 测试地址连接 CASE  ID 测试用例的ID号 TPS 每秒事务数 CPU

EQueue性能测试计划

1.发送消息吞吐量的测试: 1)单台producer单个进程的发送消息tps2)单台producer多个进程的发送消息tps3)单台broker的接收消息tps,由于单台producer可能压不满,所以需要可能两台producer来发消息 2.消费消息吞吐量的测试:1)单台consumer消费消息的tps2)两台consumer消费消息的tps 3.同时发送和接收消息的吞吐量.消费延迟的测试:1)单台producer发送消息,单台consumer消费消息2)两台producer发送消息,两台co

认清性能问题

本文翻译自 Thinking Clearly About Performance 这是我三年前读到的一篇关于性能问题的好文,读完后还觉不过瘾,怕理解的不够遂又翻译了一遍,这也是当年我的第一次翻译. 这几年来每次碰到性能问题,我都会想起这篇文章,它并不像很多其他关于性能问题的文章,告诉你利用什么工具怎么去解决性能问题,这类文章更多属于「术」的层面,而术的层面在不同的技术栈会有很不同的选择.而本文则高屋建瓴的帮助读者建立起对性能的正确认识,从而能够获得更全面的视角去看待和思考性能问题.这是「道」的层

性能本质论

摘要 对于开发者.技术管理者.架构师.系统分析师和项目经理来说,创建具备高性能特征的复杂软件都是一件极其困难的事.然而,通过了解一些基本原理,性能问题的解决和预防可以更简单可靠.本文讲述了这些基本原理,涵盖了一系列的目标.术语.工具和决策,综合利用好它们来最大可能的创建一个长期有效的高性能应用.本文的一些例子来自于 Oracle 的经验,但本文的范围并不局限于 Oracle 的产品. 目录 公理化方法 什么是性能? 响应时间 VS. 吞吐量 百分比指标 问题诊断 序列图 性能剖析 阿姆达尔定律

(转)认清性能问题

原文:https://queue.acm.org/detail.cfm?id=1854041,以下是国内翻译的版本.   摘要 对于开发者.技术管理者.架构师.系统分析师和项目经理来说,创建具备高性能特征的复杂软件都是一件极其困难的事.然而,通过了解一些基本原理,性能问题的解决和预防可以更简单可靠.本文讲述了这些基本原理,涵盖了一系列的目标.术语.工具和决策,综合利用好它们来最大可能的创建一个长期有效的高性能应用.本文的一些例子来自于 Oracle 的经验,但本文的范围并不局限于Oracle 的

性能测试从零开始实施指南——测试计划篇

最近有些同学找我咨询关于性能测试计划相关的问题,原因是他们公司要做性能测试,Leader要求写一份性能测试计划,苦于之前没做过相关工作,无从下手. 这篇博客,结合我个人的一些经验和总结,聊聊如何制定一份较为全面的性能测试计划... 一.测试背景 首先要阐述本次性能测试的背景,即被测系统类型,面向哪些用户,具备什么特点,为什么要进行性能测试,预期的一些指标等等. 比如:为了保证“双十一”大促期间,系统能稳定运行且保障业务的高可用,进行性能测试. 核心:评估系统性能.分析性能变化趋势.定位系统瓶颈风

LoadRunner 性能测试总结,LoadRunner 性能测试实例

简介  Loadrunner是一种预测系统行为和性能的负载测试工具,它可以轻松创建虚拟用户.创建真实的负载.定位性能问题.重复测试保证系统的高性能. LR与JM对比 组成  Vuser Generator      C语言脚本开发的   Controller        指挥官的作用,控制执行场景   Analysis        收集测试数据,进行结果分析的 什么时候可以开始执行性能测试?   功能测试通过;一般需要进行性能测试的系统,都是用户量比较大.业务使用比较频繁.比较重要的功能模块

性能测试分析与性能调优诊断--史上最全的服务器性能分析监控调优篇

一个系统或者网站在功能开发完成后一般最终都需要部署到服务器上运行,那么服务器的性能监控和分析就显得非常重要了,选用什么配置的服务器.如何对服务器进行调优.如何从服务器监控中发现程序的性能问题. 如何判断服务器的瓶颈在哪里等 就成为了服务器性能监控和分析时重点需要去解决的问题了. 1     服务器的性能监控和分析 1.1      Linux服务器的性能指标监控和分析 1.1.1       通过vmstat深挖服务器的性能问题 1.1.2       如何通过mpstat 分析服务器的性能指标