性能测试求助

需求如下：
平台的普通业务数据增、删、改、查接口需要支持前端业务界面的快速响应，会直接影响前端业务的流畅度和用户体验，因此需要具有较高的性能指标需求。另外个别类型的业务数据查询例如历史数据、复杂关联关系查询等场景下，数据接口响应时间响应加长，但需要控制在用户界面交互可接收范围内。另外，平台整体用户基础按照1000并发用户为基础计算QPS，并需要保持一定的峰值处理容量和长期的系统横向扩展能力。以下性能指标已考虑一般局域网的网络延时（小于10ms），未包括超范围的网络延时及抖动情况：
数据服务接口增、删、改操作： 90%数据操作接口响应时间<1s,10%数据接口响应时间<2s 。
查询类操作，查询基础数据总量十万以内简单查询操作<2s，复杂查询<5s, 100万以内查询操作<5s，复杂查询<10s。
较复杂操作如批量导入、数据汇总等操作响应时间<10s。
并发数据查询性能：不低于3000 QPS。

问题：之前没有接触性能测试，最近赶上项目性能测试需求，不知道该如何下手
1.针对以上场景，怎么设置性能测试？
2.QPS怎么计算
3.尤其是并发类的测试
4.使用jmeter性能测试，怎么分析数据？以下为测试的其中一个接口的数据

结合我这数据，[quote=“1252361554, post:1, topic:14495, full:true”]
需求如下：
平台的普通业务数据增、删、改、查接口需要支持前端业务界面的快速响应，会直接影响前端业务的流畅度和用户体验，因此需要具有较高的性能指标需求。另外个别类型的业务数据查询例如历史数据、复杂关联关系查询等场景下，数据接口响应时间响应加长，但需要控制在用户界面交互可接收范围内。另外，平台整体用户基础按照1000并发用户为基础计算QPS，并需要保持一定的峰值处理容量和长期的系统横向扩展能力。以下性能指标已考虑一般局域网的网络延时（小于10ms），未包括超范围的网络延时及抖动情况：
数据服务接口增、删、改操作： 90%数据操作接口响应时间<1s,10%数据接口响应时间<2s 。
查询类操作，查询基础数据总量十万以内简单查询操作<2s，复杂查询<5s, 100万以内查询操作<5s，复杂查询<10s。
较复杂操作如批量导入、数据汇总等操作响应时间<10s。
并发数据查询性能：不低于3000 QPS。

问题：之前没有接触性能测试，最近赶上项目性能测试需求，不知道该如何下手
1.针对以上场景，怎么设置性能测试？
2.QPS怎么计算
3.尤其是并发类的测试
4.使用jmeter性能测试，怎么分析数据？以下为测试的其中一个接口的数据

[/quote]

结合我这数据，qps怎么计算？？？？？

主要是：qps如何计算？？
针对单独接口，出如下报告如何？

1. 测试概述

1.1 测试目标

本次测试的目的在于探查建设监管业务系统-【查询企业库接口】在不同并发用户场景下的系统表现。

1.2 指标和术语

描述本次测试中涉及到的性能指标术语

2. 环境、工具

2.1 测试环境
服务器：

客户机：

2.2 测试工具

3. 测试方案

3.1 测试类型

本次性能测试将主要采用以下几种测试类型：

l 基准测试：

在小并发条件下（10个并发），探测系统各性能指标表现，作为后续比对基础。

l 压力测试：

由于无法准确预估用户访问量，因此考虑使用压力测试方法。压力测试旨在通过不断 增加系统并发处理事务数，增加系统负载，直到系统到达性能瓶颈。以此推算出系统 可承载用户和事务请求数。

l 稳定性测试：

将系统置于较长时间高负载场景下，探测系统是否出现稳定性缺陷。

3.2 业务模型

通过对于项目架构和业务场景分析，设计以下业务模型进行模拟和测试：

场景1：阶梯式并发场景-由20个并发用户逐步增加，直至60个并发用户

场景2：阶梯式并发场景-由20个并发用户逐步增加，直至53个并发用户

场景3：阶梯式并发场景-由20个并发用户逐步增加，直至56个并发用户

场景4：阶梯式并发场景-由20个并发用户逐步增加，直至57个并发用户

场景5：简单业务场景-并发数为10

场景6：简单业务场景-并发数为56

3.4 压力梯度

对于3.2所述场景，分别进行梯度加压，从20并发开始，每次递增10并发数，直至到设定并发用户数。

4. 测试结果

4.1 场景二：场景阶梯式加压，直至 60 并发用户

4.1.1 聚合报告如下：

4.1.2 活跃线程数如下：

4.1.3 TPS如下：

4.1.4 响应时间如下：

4.2 场景二：场景阶梯式加压，直至 53 并发用户

4.2.1 聚合报告如下：

4.2.2 活跃线程数如下：

4.2.3 TPS如下：

4.2.4 响应时间如下：

4.3 场景三：场景阶梯式加压，直至 56 并发用户

4.3.1 聚合报告如下：

4.3.2 活跃线程数如下：

4.3.3 TPS如下：

4.3.4 响应时间如下：

4.4 场景四：场景阶梯式加压，直至 57 并发用户

4.3.1 聚合报告如下：

4.3.2 活跃线程数如下：

4.3.3 TPS如下：

4.4.4 响应时间如下：

4.5 场景五：单接口， 10 个并发，循环执行 10 次

4.3.1 聚合报告如下：

4.6 场景六：单接口， 56 个并发，循环执行 4 分 02 秒

4.6.1 聚合报告如下：

4.6.2 活跃线程数如下：

4.6.3 TPS如下：

4.6.4 响应时间如下：

5. 分析和建议

5.1 测试结论分析
经过多次测试和数据报表分析，可以得出如下结论：

1. 场景1：线程启动到1分31秒，大概53个并发用户数时，程序开始出现报错：{“code”:“E05010500”,“message”:“You have reached maximum pool size for given partition”,“data”:""}
2. 场景2：设置最大并发53个用户，程序正常运行，无报错。响应时间随并发用户数增加而增长。
3. 场景3：设置最大并发56个用户，程序正常运行，无报错。响应时间随并发用户数增加而增长。
4. 场景4：设置最大并发57个用户，并发用户数达到57时，程序开始报错： {“code”:“E05010500”,“message”:“You have reached maximum pool size for given partition”,“data”:""}

当总体并发用户数为56-57时，系统具有最优性能表现；当事务并发数超过56时，事务失败率整体上升，系统到达性能拐点。

6. 结合可研要求：无法满足：“平台整体用户基础按照1000并发用户为基础计算QPS，并发数据查询性能：不低于3000 QPS”