如何评价公司项目接口性能和拦截攻击的能力

为什么要做接口测试？我们做性能测试的目的是什么？我觉得应该从以下几点去考虑：

1、寻找软件系统可能存在的性能问题，定位性能瓶颈并解决问题。
2、判定软件系统的性能表现，预见系统负载压力承受力，在应用部署之前，评估系统性能。

一、性能测试需要关注的指标有哪些？这边其实可以大体分为两大块：系统指标、资源指标：

能测试监控关键指标说明：

1、资源指标

CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。

内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%。

磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能。

网络带宽：一般使用计数器Bytes Total/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。

2、系统指标：

并发用户数：某一物理时刻同时向系统提交请求的用户数。

在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。

平均响应时间：系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面，一般响应时间为3秒左右。

事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务

二、如何分析监控的关键指标？

1、资源指标分析

判断CPU是否是瓶颈的方法：
一般情况下CPU满负荷工作，有时候并不能判定为CPU出现瓶颈，比如Linux 总是试图要CPU尽可能的繁忙，使得任务的吞吐量最大化，即CPU尽可能最大化使用。因此，一般判断CPU为瓶颈，主要从两方面：一是CPU空闲持续为 0，二是运行队列大于CPU核数（经验值3-4倍），即可判定存在瓶颈，对于CPU高消耗主要由什么引起的，可能是应用程序不合理造成，也可能是硬件资源 不足，需要具体问题具体分析，比如问题SQL语句引起，则需要跟踪并优化引起CPU使用过高的SQL语句。

判断内存是否是瓶颈的方法：
一般至少有10%可用内存，内存使用率可接受上限为85%。当空闲内存变小时，系统开始频繁地调动磁盘页面文件，空闲内存过小可能是内存不足或内存泄漏引起，需要根据系统实际情况监控分析。

判断磁盘I/O是否是瓶颈的方法：
磁盘I/O对于数据库服务器、文件服务器、流媒体服务器系统来说，更容易成为瓶颈，一般从以下几个方面对磁盘I/O进行分析判断：

① 计算每磁盘I/O数
每磁盘I/O数可用来与磁盘的I/O能力进行对比，如果经过计算得到的每磁盘I/O数超过了磁盘标称的I/O能力，则说明确实存在磁盘的性能瓶颈
② 监控磁盘读写，如果磁盘长时间进行大数据量读写操作，且cpu等待超过20%，则说明磁盘I/O存在问题，考虑提高磁盘I/O读写性能。

**判断网络带宽是否是瓶颈的方法：**判断网络带宽是否是系统运行性能瓶颈的首要条件是网络带宽是否会影响系统交易执行性能。例如：减小网络带宽，并发用户数、响应时间与事务通过率等性能指标是否不能接受；或者增加网络带宽，并发用户数、响应时间与事务通过率等性能指标会得到明显提高。

在实际性能测试中，如果发现始终报连接超时，而实际手工访问可以正常访问，可以通过ping应用服务器IP或网关IP，如果出现网络严重延迟或丢包，则说明网络不稳定，需要检查网络。

通过对资源指标四个指标的分析，实际上各个方面都是互相依赖的，不能孤立的单从某个方面进行排查。当一个方面出现性能问题时，往往会引发其他方面的 性能问题，例如，大量的磁盘读写势必消耗CPU和IO资源，而内存的不足会导致频繁地进行内存页写入磁盘、磁盘写到内存的操作，造成磁盘IO瓶颈，同时， 大量的网络流量也会造成CPU过载，所以，在分析性能问题时，需要从各个方面进行考虑。

2、系统指标分析

**并发用户数：**系统能够支持的用户数是系统容量的重要标志，并发用户数用于度量系统在高并发量访问下，系统的并行处理能力，一般如果系统中存在死锁、资源争用，在并发访问下，由于请求处于队列等待中，系统响应就会随着时间变慢。

一般情况下，选用高吞吐量、高数据库I/O、高商业风险的业务功能进行并发用户访问测试。

判断系统能够承受的最大并发用户数，通常以满足以下条件为准：

1、业务功能操作平均响应时间在合理范围之内

2、事务成功率在合理范围之内

3、 系统运行无故障（无异常宕机）

4、系统资源指标使用在合理范围内

**平均响应时间：**对于客户端用户来说，最直观的体验就是访问该页面快或者慢，即响应时 间的长短。比如在持续并发性能测试过程中，客户感知访问应用很慢，监控到的平均响应时间也逐渐变长，这时就需要先借助于监控到的资源指标，首先排除资源方 面的限制因素，再从应用本身进行定位，如可以采用页面细分工具（如httpwatch、Loadrunner Anaysis中的页面组件细分）分析响应比较慢的页面。

**事务成功率、超时出错率：**事务成功率越高，则表明系统处理能力越大；而失败事务主要由于系统响应慢，导致访问业务功能超时，或者系统业务功能异常，不能正常访问等，需要根据事务错误提示信息，具体分析。

我们运用性能测试工具实战操作一下，看下公司项目的防攻击及性能怎么样，具体的代码如下页面：

我们请求之后看看结果图：

从图我们可以看出，并发刚开始时16:19之前都还算正常，运行比较平稳，16:19之后请求数和相应时长突然变大，我们用接口工具请求看看：

原来是我们系统的拦截工具把攻击拦截了，说明我们的拦截做得不错。至于性能怎么样我们还要具体分析。待续。。。。