彩票走势图

手机浏览器美图笑话功能协议如下：

笑话协议：

pread.ie.sogou.com/infolist?count=20&lastindex=&b=%E7%AC%91%E8%AF%9D&mode=up&t=1445931068206&h=00000000-4379-c005-d445-0540728befc5&r=0000&v=4.1.0&hv=GT-I9500&pv=ANDROID4.2.2

美图协议：

pread.ie.sogou.com/infolist?count=20&lastindex=&b=%E7%BE%8E%E5%A5%B3&mode=up&t=1445932269394&h=00000000-4379-c005-d445-0540728befc5&r=0000&v=4.1.0&hv=GT-I9500&pv=ANDROID4.2.2

测试过程中的难点和解决方案、思路归纳如下：

第一个难点：

由于是两个请求，如何测试两个请求同时存在情况下，服务端承受压力情况？即如何考虑两个请求的压力配比？

这个测试场景涉及到两个请求，为了模拟实际的使用环境，我们必须考虑到两个请求的配比情况，一般设计配比有两种情况：

一种情况是已经上线过这个功能，就像我这个版本，很久之前有过相关功能，只是这次做一个接口重构，所以有历史数据可以参照。

我这边主要是与产品要了笑话、美图的UV数据，分别利用笑话美图一段时间的UV和PV最大值，算出相应的比例，从而用这个数据设置为相应的打点比例。

另一种情况是从未上线过该内容，此时就需要依赖于一个小型灰度，灰度前要设置相应的请求pingback数据，从而能通过灰度数据计算出相应的比例。

第二个难点：

两个请求一起打压，如何设计脚本和添加到loadrunner中？

首先要在Run logic中设置好Init、Run、End，以美图笑话为例具体设置截图如下：

我们从图中看出，笑话是美图的259倍。

脚本展示如下：

美图脚本：

meitu() 
{ 
int itera_num，rand_num，i; 
char StrTable[]="abcdefghijklmnopqrstuvwxyz1234567890____"; 
char i_data[36]=""; 
//itera_num=rand()%16; 
itera_num=36; 
for(i=0;i<=itera_num;i++) 
{ 
rand_num=rand()%39; 
strncat(i_data，StrTable+rand_num，1); 
} 
lr_save_string(i_data，"i_data_value"); 
web_reg_find("Text=index"， 
LAST ); 
lr_start_transaction("meitu"); 
web_url("xiaohuameitu"， 
"URL=http：
//10.134.73.228/infolist?count=20&lastindex=&b=%E7%BE%8E%E5%A5%B3&mode=up&t=1468726249
158&h={i_data_value}&r=0000&v=4.1.0&hv=GT-I9500&pv=ANDROID4.2.2"， 
"Resource=0"， 
"RecContentType=text/html"， 
"Referer="， 
"Snapshot=t15.inf"， 
"Mode=HTTP"， 
LAST); 
lr_end_transaction("meitu"， LR_AUTO); 
 
 
 
41 
                                       
return 0; 
}

脚本中需要注意的是：

1. i_data_value为一个随机数，从而保证模拟到不同手机请求的结果，也能防止
   服务端的缓存机制。
2. h={i_data_value}，其中大括号的意思为参数化，一定要进行参数化，否则
   loadrunner不认为这是一个变量。

参数化的方法：//pclwef.cn/article/2016/2/4/23498.html

第三个难点：

承受最大打点数通过loadrunner检测出来，如何估算出能够承载的用户数？

通过请教loadrunner专家小曹和我的leader立人，我了解到，估算这个承载用户数 有多种方法，罗列如下（以案例的形式）：

1. 如何建设一个能承受500万PV/每天的网站吗？
   计算模型：
   每台服务器每秒处理请求的数量=（（80%*总PV量）/（24小时*60分*60秒 *40%））/服务器数量
   其中关键的参数是80%、40%。表示一天中有80%的请求发生在40%的时间内。24 小时的40%是9.6小时，有80%的请求发生一天的9.6个小时当中（很适合互联网的应 用）。
   （（80%*500万）/（24小时*60分*60秒*40%））/1 = 115.7个请求/秒
2. 做过线上灰度，有一个请求数与用户日活的比例，可以直接计算得出。
   本次笑话我算出最大承受打点数为200QPS，主要是利用第一种算法计算
   （200QPS*（24*40%）*3600）/80% = 864w
   鉴于线上的2台机器做负载均衡，整体可以承受至少400QPS并保持性能稳定。
   根据以上经验公式计算评估，400QPS可以支撑线上至少每天1600W用户的访问 量。由于该服务端同时还要支撑PC端的150w用户，故在笑话美图这边实际支持 1400w用户的访问。

第四个难点：

测试中涉及到的是两个服务器，一个中转服务器，一个提供数据的服务器，如何同
时进行两个服务端的压力测试？

两台服务端直接进行压力测试，根据响应结果，观察是哪台服务端成为瓶颈，当 然，有些时候是带宽成为瓶颈。

第五个难点：

Loadrunner只有打点端服务器的数据监控，如何监控被测服务端的参数情况？

需要在被测服务端上安装nmon_analyser_34a这个软件。

这里有一个特别重要的命令：

./nmon_x86_rhel52 -f -c 1（执行次数） -s 1（时间间隔）的意思是形成分析表格，其 中第一个1是表示执行次数，第二个1是表示记录数据间隔，如果是1，就是代表时间间隔为1s。

具体第一个1的数据是由总共执行的时间决定的，其中总共的时间是由loadrunner设置决定的，如果loadrunner总设定时间为10分钟，那么如果命令中时间间隔设置为1s，那么执行次数应该就是600次。

将结果形成表格后，再通过命令将该表格导出即可。

第六个难点：

最后打点过程中的一些参数和选项配置的细节问题。

1. 压力测试log存放位置：Temporary directory，截图如下：
   
2. 设置打点参数的细节：
   
3. 线程托管一般选择5-150Vusers，选择是线程还是什么的位置如下：
   
4. 其他设置项：
   
   
   以上要注意这些设置项:
   Goal Type选择的是
   
   
   Transaction选择的是
   
   
   我这次测试中选择的是xiaohua这个时间的事务数。

第一个总结：

压力测试中到底是在关注什么？

1. CPU占用：比较稳定，不要超过70% 这个是平均到每一个核的 。
2. 内存占用：只要有空余内存即可，一般不会成为瓶颈，具体可以参考Linux内存管理知识 。
3. 平均响应时间：3、5、8原则。
4. 带宽限制：如果带宽成为限制，就要与产品沟通，在这种带宽下给出极限值， 要采取限流措施。
5. 测试出最高的打压值，之后，需要降低打压值，一直到服务端的CPU占用、内 存占用、平均响应时间均为正常值情况。这时的指标值才是真正想要的值。

第二个总结：

如何写出一个压力测试的测试报告？应该公示哪些内容？

一个基本的压力测试报告包含以下几个部分：

1. 测试结论总结：主要包含能够承受的访问量，在这个访问量下内存占用情况。
2. 具体测试结果：
   • CPU占用情况
   • 每秒事务数
   • Free内存
   • 平均事务响应时间

以上就是我整个压力测试过程的一些总结，希望对一些同学有所帮助。

原文转载自：