网站服务器如何做访问压力测试？

网站服务器的压力测试我觉得主要有一些几点。

1协议这边基本上以http或者https为主了，如果使用其他协议需要分析其打解包的方法。

2要产生一定的压力，压力源这边一定要有保证。一般都是用机器人来模拟压力，关于机器人的逻辑可以根据具体业务来开发。

3需要观察在一定压力下，服务器的各项性能指标（cpu，内存，IO，网络流量）进行观察，比如内存是否有泄漏，cpu利用率过高的情况。

4压力测试应该是一个持续性的过程，在这个过程中需要统计服务器的性能数据，包括tps，以及机器的负载情况等。据此可以分析服务器的瓶颈在何处，后续可以针对优化。

5目前大部分的服务器都部署在Linux系统上，测试同学还需要掌握相关的Linux命令以便可以更好的测试。

如果你觉得前面的太麻烦，可以来WeTest服务器压力测试高并发，实时性能报表，专家级性能优化建议，目前我们正在做网站压测这一块，你要做的仅仅是填下被测的URL即可，压力源、数据统计这些琐碎的工作交给我们就行了。

使用rt thread系统里的EC200驱动包+web client做一个物联网项目，之前开发的时候一直都是用的EC600S模块，看起来挺好的，没什么大问题，后来量产的时候不小心买了EC600N焊上去了，之前也听厂家的技术支持说应该是完全一样的，可是就掉进了这个坑里。

故障现象：

模块的net_status和net_mode灯的状态不太对，模块开机后的最终状态有时候net_mode常亮，net_status灭掉，或者net_status一直在慢闪，net_mode一直熄灭。甚至有时候我的应用可以先从服务器拿一包数据，然后又挂掉再也连不上了。

分析：

上述这两种状态都不在文档描述中，打at client去看，你发什么它都是直接回显，比如发AT+CPIN它就直接回，而不是回OK或者错误,所以初步判断是模块进入了一个错误的状态。那么能让模块进入错误状态无非就是以下几种情况：

睡眠或者开机、重启的姿势不对

或者在模块初始化之前我的应用代码把它搞死了。但是之前用EC600S开发都是好的，而且一般应用代码不太能把模块搞到错误状态，这种可能性比较低。

排查：

针对第二种情况，排查很简单，先把应用软件去掉看看。故障依旧，所以继续排查1

在EC200的驱动包里要配置开机引脚，状态引脚，睡眠引脚。无论是开发什么东西，一般睡眠这种状态是最容易出问题的，包括x86开发，usb设备开发，屡见不鲜，所以首先把睡眠去掉了（-1），但是故障依旧。

刚开始我始终没有怀疑状态引脚，因为它是个输入，只是判断一下模块有没有开机，感觉不会有什么问题，所以绕来绕去一直没有去动它。直到看到了有个哥们遇到了类似的问题：

RT-Thread-at_device 没有使用power pin 导致的网络异常 bugRT-Thread问答社区 - RT-Thread

这个问题其实我之前用EC600S的时候好像也遇到了，但是我并不用ping，应用也没有问题，所以也没去管他。不过这倒提醒了可以去试试，于是把开机状态也改成-1，居然就好了。

电源引脚我没去动它，模块是需要有一个开机时序的，我看它的初始化代码里也有去动电源引脚重新开机之类的。

希望其他掉在坑里的小伙伴可以看到我这篇帖子，少走点弯路。

打开CSDN，阅读体验更佳

Quectel_EC600S系列_TCP(IP)_应用指导_V12rar

EC600S-CN 模块内置 TCP/IP 协议栈， Host 可以 直接通过 AT 命令访问网络； 这大大降低模块对 PPP 和外部 TCP/IP 协议栈的依赖性，从而降低终端设计 的成本。

EC600N（二）--核心板初次点亮

系列文章目录 EC600N（一）–基本信息介绍 EC600N（二）–核心板初次点亮 目录系列文章目录前言一、使用前说明1供电方式2 模块开机状态二、AT指令测试1测试准备2AT指令测试 前言 本次实验使用移远EC600N双排核心板，主要使用AT指令测试模块，测试模块的USB口和33V串口。 一、使用前说明 1供电方式 EC600N模块需要用排针的VIN进行供电，供电如下图所示： USB口供电可能达不到模块的开机要求(由于串联了二极管，有压降)，一般采用针脚对模块供电。这个设计有点鸡肋。 2

继续访问

移远4G模组EC600N进行TCP/IP连接和服务器测试

最近公司产品需要增加一个4G模块进行数据传输，想到之前做的移远的4G模块，于是买了一个核心板回来调试。 协议选择TCP/IP，因此使用的是TCP/IP部分的AT指令手册。工具方面，使用串口调试助手，关于测试服务器，一开始用的安信可的透传云，但是服务器连接一段时间不发送消息就会自动断开，所以还是使用了网络调试助手。因为网络调试助手使用的是本地网络，如果需要和4G通信，还需要使用花生壳做内网穿透。 接下来先把服务器部分做好。 如果没有花生壳软件，建议先去官网下载一个 长这样色的。安装后打开界面如下 这个界

继续访问

STM32F405+4G模块OTA固件升级调试记录

STM32F405+4G模块OTA固件升级调试个人记录

继续访问

Cat1模块使用总结（EC600N）

由于Cat4模块（EC20）功耗大，考虑到NB网络覆盖问题（设备在野外工作场景），因此项目上用选择了Cat1（EC600N）模块，现在把调试过程总结下，希望能够帮助到大家。EC20使用总结请看：单片机和4G模块通信总结（EC20）。 一、电源 手册说供电电压≥34V，峰值电流3A。 二、通信口 UART和IO口都是18V，需要做电平准换。 三、开机顺序 我是上电1s后复位，复位低电平600ms，然后100ms后开机，开机等待10s后进行操作。 四、AT指令 采用消息地体原理，具体请看

继续访问

日志组件

日志组件 1 日志是什么 日志是软件应用必备的组件，是程序debug，或是数据收集管理的重要依据，方便我们监测生产环境的变量值变化以及代码运行轨迹。本课程主要用来学习实际开发中常用的日志组件。 主要是为了方便我们监测生产环境的变量值变化以及代码运行轨迹等。 这些记录会被输出到我们指定的位置形成文件,帮助我们分析错误以及用户请求轨迹。 2 常用日志组件 21 Log4j与log4j2x ​ Log4j有8种不同的log级别，按照等级从低到高依次为：ALL>TRACE>DEBUG&gt

继续访问

ESP32+移远EC600N模组通过MQTT连接阿里云并通过HTTP进行OTA升级

ESP32+移远EC600N模组通过MQTT连接阿里云并通过HTTP进行OTA升级。以下是我这段时间进行的工作，分享下自己的研究成果，也让后面的小伙伴少踩一些坑。同时通过文章记录下操作步骤，免得自己过段时间忘记。以下是ESP32和EC600N模组之间通过串口进行数据交互的详细调试信息输出内容。

继续访问

热门推荐 EC600N（一）--基本信息介绍

EC600N使用说明 EC600N（一）–基本信息介绍 目录EC600N使用说明前言一、模块组的基本介绍1模组的基本选型信息2 EC600N核心板基本信息二、EC600N功能介绍1基本功能介绍2引脚功能三补充 前言 EC600N是一款移远推出的4G模块。移远和中传移动是主要的4G模块和NB-lot模块的供应商。由于移远的模块使用相对比较广泛，所以用它试试。 相关资源链接： 官网，这个网站找资料比较费劲。 quetcelpython下载中心，移远的多数模块支持python的二次开发。 quetcel

继续访问

移远QuecPython（基于EC600s）开发物联网应用(七) QuecPython通讯相关模块

一 sim --SIM卡模块 import sim 1 获取sim卡的imsi simgetImsi() 参数 无 返回值 成功返回string类型的imsi，失败返回整型-1。 2 获取sim卡的iccid simgetIccid() 参数 无 返回值 成功返回string类型的iccid，失败返回整型-1。 3 获取sim卡的电话号 simgetPhoneNumber()

继续访问

C语言一个好用的循环队列与使用示例（以EC200/600为例的AT框架）

目录1前言2结论3循环队列31写队列到队列头32从尾部读读队列33获取当前队列内数据数量34清空队列35两个重要结构体4效果与示例41三个读队列线程42 AT框架写队列与EC200初始化43 AT框架读队列44 EC200维持TCP长连接5下载51 循环队列52 AT框架+EC200的TCP长连接（与EC600通用） 1前言 上一篇：https://blogcsdnnet/ylc0919/article/details/111050124 自从之前说要发二代框架，不知不

继续访问

阿里云在线温湿度-小熊派qpython（综合展示）

需要用到的东西： 小熊派的ec100y开发板； i2c的温湿度传感器（我这里用的sht31，其他的也可以，自行修改代码）； 阿里云账号； 接线：用到33v，GND，i2c的SCL和SDA 阿里云显示展示： app展示： 代码： # 包引用部分 import log from aLiYun import aLiYun import ujson import utime from machine import I2C import pm # 用户变量区域 # 上传间隔(单

继续访问

EC600N-AT 软件包笔记

INIT_DEVICE_EXPORT(ec200x_device_class_register); 开辟struct at_device_class结构体 进入at_device_class_register 怎么跳转到的static int ec200x_init(struct at_device device) at_device_class_registe执行完后到 INIT_APP_EXPORT(ec200x_device_register); static int ec200x_device_r

继续访问

open方案、openCPU-EC600、L610设计应用总结

OPEN CPU模组设计应用总结 咸鱼NO FASHION 根据实际项目需求选择最优的设计方案，是一名合格硬件工程师的基本功。 背景与优缺点说明： 对于物联网项目，大多数公司或者产品需更为便宜方案，因此在物联网项目中open CPU方案迎来黄金发展期。物联网项目本身就需要无线通信模组，通信模组开放一定IO口和通信接口，优点可以解决目前广大用户主控MCU短缺的痛点，降低开发成本；缺点IO口和通信接口使用相对于主控MCU不够灵活，接口相对较少。 软件方面： 支持open C和open Python（

继续访问

Quectel EC800N-CN 小尺寸物联网首选LTE Cat 1模块[移远通信]

EC800N-CN是移远通信专为M2M和IoT领域而设计的LTE Cat 1无线通信模块，支持最大下行速率10 Mbps和最大上行速率5 Mbps，超小封装，超高性价比。 EC800N-CN采用镭雕工艺，镭雕工艺具有外观更好看、金属质感强、散热更好、信息不容易被抹除、更能适应自动化需求等优点。 EC800N-CN内置丰富的网络协议，集成多个工业标准接口，并支持多种驱动和软件功能（如Windows7/8/81/10、Linux、Android等操作系统下的USB虚拟串口驱动）；极大地拓展了其在M

继续访问

EC600S串口通信

EC600S有两个串口通信口，TX0/RX0;TX2/RX2,分别对应程序中的UART0 - DEBUG PORT和UART2 – MAIN PORT。运行本例程， 需要通过串口线连接开发板的 MAIN 口和PC，在PC上通过串口工具打开 MAIN 口，并向该端口发送数据，即可看到 PC 发送过来的消息。 （可通过串口转usb口，把TX2/RX2分别与转usb口的RX/TX连接到电脑上即可） """ 运行本例程，需要通过串口线连接开发板的 MAIN 口和PC，在PC上通过串口工具 打开 MAIN 口，并向

继续访问

移远EC20/600系列TCP发送可变长度数据的结束标志！

移远EC20/600系列TCP发送可变长度数据的结束标志！

继续访问

移远ec200/600的使用

移远ec200、ec600的使用： linux2622 pppd-244 ec600s 参考的是ec200s的拨号相关文档： 1:/driver/usb/serial/optionc更改了4个位置，并没 有严格按照ec200s的指导文档来（2630以上、30以上内核还会涉及wwan、qcserial相关文件，看相关文档） 2：内核config USB_SERIAL=y USB_USBNET=y USB_NET_CDCETHER=y （还没搞清楚

继续访问

EC600U

ec600u，tcp client 断线重连

继续访问

最新发布 STM32+USART+DMA+EC600N调试

在stm32Cube中，打开DMA发送中断和接收中断，打开usart全局中断。主要调试功能：（1）使用DMA发送固定长度数据给串口，（2）使用DMA接收不定长度帧数据。（1）利用DMA传输，发送固定大小数据 换成 包装代码如下： （2）利用DMA传输，接收大小可变的数据利用串口空闲中断，识别一帧的数据，参考链接： 注意：空闲中断结束后，记得重新开启DMA接收。指令解析 AT执行逻辑 每个AT指令执行成功，则继续下一条，如果本条AT指令执行失败，则重复执行，最多执行10次，如果10全部失败，则本轮结束

继续访问

一、远程连接到Windows服务器，使用windows系统自带工具进行收集性能数据

1、Windows服务器中自带的性能监控工具叫做Performance Monitor,在开始-运行中输入‘Perfmonmsc’，然后回车即可运行。通过界面，控制面板\所有控制面板项\管理工具\性能监视器也能打开

打开后，页面展示

2、添加计数器

性能>数据收集器集>用户定义[右击]>新增‘数据收集器集’>手动创建高级>下一步

勾选创建数据日志>性能计数器>下一步

点击“添加”→选择计数器

点击选中的可用计数器>添加>确定

确定>下一步

选择目录后，点击完成

查看新增的计数器，输出地方为日志输出地址

3、选择日志数据源格式

选择用户定义下的数据收集器集>右键属性>性能计数器，日志格式选择“逗号分隔”（即csv格式）

4、开始启动数据采集，选择用户定义下的数据收集器集>右键属性>开始

此时，输出有地址了

5、用EXCEL将数据转换为折线图，并分析性能情况

二、分析性能情况

（1）内存泄露判断

●虚拟内存字节数（VirtualBytes）应该远大于工作集字节数（Workingset），如果两者变化规律相反，比如说工作集增长较快，虚拟内存增长较少，则可能说明出现了内存泄露的情况。

●对于Workingset、Private Bytes、Available bytes这些计数器，如果在测试期间内数值持续增长，而且测试停止后位置在高水平，则也说明存在内存泄露。

●Windows资源监控中，如果Process\PrivateBytes计数器和Process\WorkingSet计数器的值在长时间内持续升高，同时Memory\Available

bytes计数器的值持续降低，则很可能存在内存泄漏。

（2）CPU使用情况

●一般平均不要超过70%，最大不要超过90%（好：70% 、坏：85%、 很差：90%）

（3）tps（每秒处理事务的数量，在SOAPUI中进行统计）

●一般在10-100，不同应用程序具体值不同

三、关于计数器的选择

perfmon的计数器主要分四种：处理器性能计数器、内存性能计数器、磁盘性能计数器以及网络性能计数器。

以下为监控服务器常用的计数器：

常用的性能对象与指标

性能对象

计数器

提供的信息

Processor

% Idle Time

% Idle Time 是处理器在采样期间空闲的时间的百分比

Processor

% Processor Time

% Processor Time 指处理器用来执行非闲置线程时间的百分比。计算方法是，测量范例间隔内非闲置线程活动的时间，用范例间隔减去该值。这个计数器是处理器活动的主要说明器，显示在范例间隔时所观察的繁忙时间平均百分比。

Processor

% User Time

% User Time 指处理器处于用户模式的时间百分比。用户模式是为应用程序、环境分系统和整数分系统设计的有限处理模式。

Memory

Available Bytes

Available Bytes显示出当前空闲的物理内存总量。当这个数值变小时，Windows开始频繁地调用磁盘页面文件。如果这个数值很小，例如小于5 MB，系统会将大部分时间消耗在操作页面文件上。

Memory

% Committed Bytes in Use

% Committed Bytes In Use 是 Memory: Committed Bytes 与Memory: Commit Limit之间的比值。(Committed memory指如果需要写入磁盘时已在分页文件中保留空间的处于使用中的物理内存。Commit Limit是由分页文件的大小而决定的。如果扩大了分页文件，该比例就会减小)。这个计数器只显示当前百分比；而不是一个平均值。

Memory

Page Faults/sec

Page Faults/sec是指处理器处理错误页的综合速率。用错误页数/秒来计算。当处理器请求一个不在其工作集(在物理内存中的空间)内的代码或数据时出现的页错误。这个计数器包括硬错误(那些需要磁盘访问的)和软错误(在物理内存的其它地方找到的错误页)。许多处理器可以在有大量软错误的情况下继续操作。但是，硬错误可以导致明显的拖延。这个计数器显示用上两个实例中观察到的值之间的差除以实例间隔的持续时间所得的值。

Network Interface

Bytes Total/sec

Bytes Total/sec是发送和接收字节的速率，包括帧字符在内。

Network Interface

Packets/sec

Packets/sec为发送和接收数据包的速率。

Physical Disk

% Busy Time

% Busy Time指磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。

Physical Disk

Avg Disk Queue Length

Avg Disk Queue Length 指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。

Physical Disk

Current Disk Queue Length

Current Disk Queue Length指在收集操作数据时在磁盘上未完成的请求的数目。它包括在快照内存时正在为其提供服务中的请求。这是一个即时长度而非一定间隔时间的平均值。多主轴磁盘设备可以一次有多个请求操作，但是其它同时发生的请求为等候服务。这个计数器可能会反映一个暂时的高或低的列队长度，但是如果在磁盘驱动器存在持续负载，可能值会总是很高。请求等待时间与这个列队的长度减去磁盘上的主轴成正比。这个差值应小于2才能保持良好的性能。

Logical

Disk

% Free Space

% Free Space 是所选定的逻辑磁盘驱动器上总的可用空闲空间的百分比。

Logical

Disk

Free Megabytes

可用的 MB 显示磁盘驱动器上尚未分配的空间。

 以下为监控进程常用的计数器：

Process对象的主要指标

性能对象

计数器

提供的信息

Process

% Privileged Time

% Privileged Time 是在特权模式下处理线程执行代码所花时间的百分比。当调用 Windows 系统服务时，此服务经常在特权模式运行，以便获取对系统专有数据的访问。在用户模式执行的线程无法访问这些数据。对系统的调用可以是直接的(explicit)或间接的(implicit)，例如页面错误或间隔。

Process

% Processor Time

% Processor Time 是所有进程线程使用处理器执行指令所花的时间百分比。指令是计算机执行的基础单位。线程是执行指令的对象，进程是程序运行时创建的对象。此计数包括处理某些硬件间隔和陷阱条件所执行的代码。

Process

% User Time

% User Time 指处理线程用于执行使用用户模式的代码的时间的百分比。应用程序、环境分系统和集合分系统是以用户模式执行的。Windows 的可执行程序、内核和设备驱动程序不会被以用户模式执行的代码损坏。

Process

Creating Process ID value

Creating Process ID value 指创建该进程的父进程号。

Process

Elapsed Time

该进程运行的总时间(用秒计算)。

Process

Handle Count

由这个处理现在打开的句柄总数。这个数字等于这个处理中每个线程当前打开的句柄的总数。

Process

ID Process

ID Process 指这个处理的特别的识别符。ID Process 号可重复使用，所以这些 ID Process 号只能在一个处理的寿命期内识别那个处理。

Process

IO Data Bytes/sec

处理从 I/O 操作读取/写入字节的速度。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。

Process

IO Data Operations/sec

本处理进行读取/写入 I/O 操作的速率。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。

Process

IO Other Bytes/sec

处理给不包括数据的 I/O 操作(如控制操作)字节的速率。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。

Process

IO Other Operations/sec

本处理进行非读取/写入 I/O 操作的速率。例如，控制性能。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。

Process

IO Read Bytes/sec

处理从 I/O 操作读取字节的速度。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。

Process

IO Read Operations/sec

本处理进行读取 I/O 操作的速率。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。

Process

IO Write Bytes/sec

处理从 I/O 操作写入字节的速度。这个计数器为所有由本处理产生的包括文件、网络和设备。

Process

IO Write Operations/sec

本处理进行写入 I/O 操作的速率。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。

Process

Page Faults/sec

Page Faults/sec 指在这个进程中执行线程造成的页面错误出现的速度。当线程引用了不在主内存工作集中的虚拟内存页即会出现 Page Fault。如果它在备用表中(即已经在主内存中)或另一个共享页的处理正在使用它，就会引起无法从磁盘中获取页。

Process

Page File Bytes

Page File Bytes 指这个处理在 Paging file 中使用的最大字节数。Paging File 用于存储不包含在其他文件中的由处理使用的内存页。Paging File 由所有处理共享，并且 Paging File 空间不足会防止其他处理分配内存。

Process

Page File Bytes Peak

Page File Bytes Peak 指这个处理在 Paging files 中使用的最大数量的字节。

Process

Pool Nonpaged Bytes

Pool Nonpaged Bytes 指在非分页池中的字节数，非分页池是指系统内存(操作系统使用的物理内存)中可供对象(指那些在不处于使用时不可以写入磁盘上而且只要分派过就必须保留在物理内存中的对象)使用的一个区域。这个计数器仅显示上一次观察的值；而不是一个平均值。

Process

Pool Paged Bytes

Pool Paged Bytes 指在分页池中的字节数，分页池是系统内存(操作系统使用的物理内存)中可供对象(在不处于使用时可以写入磁盘的)使用的一个区域。这个计数器仅显示上一次观察的值；而不是一个平均值。

Process

Priority Base

这次处理的当前基本优先权。在一个处理中的线程可以根据处理的基本优先权提高或降低自己的基本优先权。

Process

Private Bytes

Private Bytes 指这个处理不能与其他处理共享的、已分配的当前字节数。

Process

Thread Count

在这次处理中正在活动的线程数目。指令是在一台处理器中基本的执行单位，线程是指执行指令的对象。每个运行处理至少有一个线程。

Process

Virtual Bytes

Virtual Bytes 指处理使用的虚拟地址空间的以字节数显示的当前大小。使用虚拟地址空间不一定是指对磁盘或主内存页的相应的使用。虚拟空间是有限的，可能会限制处理加载数据库的能力。

Process

Virtual Bytes Peak

Virtual Bytes Peak 指在任何时间内该处理使用的虚拟地址空间字节的最大数。

Process

Working Set

Working Set 指这个处理的 Working Set 中的当前字节数。Working Set 是在处理中被线程最近触到的那个内存页集。如果计算机上的可用内存处于阈值以上，即使页不在使用中，也会留在一个处理的 Working Set中。当可用内存降到阈值以下，将从 Working Set 中删除页。如果需要页时，它会在离开主内存前软故障返回到 Working Set 中。

Process

Working Set Peak

Working Set Peak 指在任何时间这个在处理的 Working Set 的最大字节数。

本文由Donny译自 3scalecom 的 《How to load test & tune performance on your API》

这几年API的作用不断演化，以前API还只是用来做内部系统之间的集成点，但现在API已成为一个公司的核心系统，一个构建于Web和移动端应用之上的核心系统。

当API仅只用来处理后台的任务（例如生成报告），那么性能差点也不是问题。但是如今API慢慢地发展成为连接服务与终端用户的核心纽带。这种关键性的角色变化表明了一个重要的观点：那就是API的性能真的很重要。

如果API数据源响应快，前端的应用程序的设计好点或差点影响不大，要是响应慢如蜗牛，前端的设计再出色也是然并卵。现在我们的客户端应用展示的数据源可能都是来自多个API响应内容的聚合，性能对这种微服务构架来说真的非常重要。

可以毫不夸张的说出色的性能就是你API提供的最好功能。我们知道向目标改进的唯一正确的方法就是找到问题的关键点，或者叫关键路径，并不断迭代测量和调整你的架构系统，直到系统达到预定的目标。对于API来说，测量和提高性能的过程就是负载与压力测试的过程。

本文将重点介绍如何对你的API进行负载压力测试。我们会以一个简单的、未测过的例子开始，然后再添加一个访问控制层，要确保一切都经过严格测试，做好处理真实流量的准备工作。OK，开始吧！

首先我们要明确要测试什么，可以是对你所有的API接口，或者是对单个API接口，或是对需要排除故障或改进的API接口的常规测试。

本文的其部分，我们将使用一个示例API。这是一个棋牌类游戏的Nodejs API。它有三个API接口：

/question – 返回一个随机黑牌

/answer – 返回一个随机白牌

/pick – 返回一对随机的问题与答案

你测试用的负荷情况越和真实环境的越类似，你的负载测试就越有用。如果你不知道实际流量有多少或者你不知道负载在所有接口上是否都一致，那么就算你知道你的API可以保持400 请求/秒的吞吐量也没啥鸟用。

所以，你应该先从收集你API的使用数据开始。你可以直接从你的API服务日志或者从其他你在用的应用性能工具（例如New Relic）中获取数据。在对你的API进行第一次测试之前，你应该对以下问题做到心中有数：

（1）每秒请求数的平均吞吐量（Average throughput in requests per second）

（2）峰值吞吐量（您在某段时间内获得的最大流量是多少？）（Peak throughput）

（3）API各接口的吞吐量分布情况（有没有一些接口的流量远超其他接口？）

（4）用户的吞吐量分布情况（少数用户产生大多数的流量，或者是更均匀分布？）

另外还需要考虑的一个关键点是，在测试期间将要模拟的流量会是怎样的，主要考虑点是：

（1）重复负载生成（Repetitive load generation）

（2）模拟流量模式

（3）真实流量

通常我们最好以最简单的方法开始测试，然后逐步演化到更为接近真实环境的测试。我们可以先用重复负载生成来做为API接口的第一个测试，这样不仅可以验证我们的测试环境是否稳定，更重要的是可以让我们找到API能承受的最大吞吐量，这样我们就可以知道API可以达到的性能上限是多少。

找到你的API性能上限值后，你就可以开始考虑如何将你的生成的测试流量塑造得更接近真实环境。使用真实流量来测试是最理想的，但实际操作不太可行。要模拟真实流量比较难，也太花时间。所以我们有一个折中点的方法：先研究你的流量分析数据，并做一个简单的概率模拟。比如你有100个API接口（提示：原文endpoint在这里我译为接口，翻译成端点也可以，不过译成接口感觉更容易理解），你检查了上个月的使用情况，发现80%的流量来自20个接口，其中3个接口占用了50%的流量。那么你就可以创建一个遵循这种概率的请求列表，并提供给你的负载测试工具。这样做就相对快多了，并且它相对比较接近你真实负载，可以显示出你实际环境中可能遇到的问题。

最后，如果你拿到你要测试的API的真实访问日志，你就可以用它们来做最接近客观现实的测试。我们待会儿要讨论的大部分负载测试工具，都是接收一个请求列表作为输入文件。你可以用你的访问日志，稍微做一个格式调整就可以匹配每个测试工具所需的格式。搞定这个你就可以在测试环境中轻松重现你的生产流量。

好了，你清楚了你要测试什么鬼了，准备工作的最后一步就是配置好你的测试环境。你需要一个专用的测试环境。如果你不怕被你老板骂的话，或者比较任性，你也可以直接在你的生产环境中进行性能测试，不过出问题别说哥事先没跟你说清楚哈。

如果您已经设好一个预生产或沙箱环境，并且你的API也在上面运行了，那么你就万事俱备了。因为本文要用示例API，我们会在AWS的服务实例上设置我们的环境。

在我们的例子中，我们使用一个简单的API，不需要从磁盘读取或在内存中保存大型数据集。我们选择Linux C4large 实例就够了。

注意：我们对比过其他相似处理资源数但内存更大的AWS实例，但实际测试中内存大部分没使用，所以我们选了C4large

接下来，我们将一个配好的负载测试实例（服务器）运行起来，这只是一个运行模拟测试程序的服务器，它会通过从多个并发连接重复发送请求到我们的API服务器。你需要模拟的负载越高，机器的性能就要求越高。再次，这也是一个CPU密集型工作负载。这里我们选择具有4个虚拟核，16个 ECU的优化处理器的 c4xlarge AWS服务器

我们选择在相同的可用区内部署所有实例（API服务器与测试服务器在同一个区/机房），这样可以将外部因素对我们测试结果的影响降到最小。

我们有一个沙箱环境来运行我们的API，同时也有另一台服务器准备开始负载测试。如果这是你第一次做性能测试，你一定会想知道什么是最好的方法。在本节中，我们将会分享我们如何选择工具，同时也会介绍一下目前市面上一些公认比较好的工具。

JMeter

在人们意识当中，首当翘楚的估计是 Apache JMeter ，这是一个开源的Java程序，他关键的特性就是提供一个强大而完善的创建测试计划的GUI。测试计划由测试组件组成，测试组件定义了测试的每一个部分，例如：

（1）用来注入负载测试的线程

（2）参数化测试中使用的HTTP请求

（3）可添加侦听器，象widget测试组件那样，可以以不同的方式显示测主式结果

优点：

（1）它是功能性负载测试的最好工具。你可以设定条件来为复杂的用户流建模，还可以创建断言来验证行为。

（2）轻松模拟复杂的http请求，比如请求前的登录验证或文件上传

（3）可扩展性强，有很多社区插件可以修改或扩展内置的行为

（4）开源并且免费

缺点：

（1）GUI学习曲线陡峭，一大堆的选项，在你运行第一个测试之前你得了解大量的概念。

（2）测试高负载时，操作步骤很麻烦。你需要先使用GUI工具来生成XML测试计划，然后在非GUI模式下导入测试计划运行测试，因为GUI会消耗掉本用于生成负载的大量资源。你还需要注意所有的侦听器（收集数据与展示测量的组件）哪些要被禁用或启用，因为它们也很耗资源。测试结束后后，你需要将原始结果数据导入GUI以才能查看结果。

（3）如果你的目标是测试一段时间内的持续吞吐量（例如在60秒内每秒请求1000次），那么很难找到正确的并发线程数量和计时器来求出一个比较稳定的数值。

JMeter只是我们在开始测试时用的工具，我们很快开始寻找其他替代方案。原因是，如果你的目标是在Web应用上压力测试复杂的用户流，那么JMeter可能是最好的工具，但如果你只是需要在一些HTTP API接口上进行性能测试，那用它就是杀鸡用牛刀了。

Wrk

Wrk 是一款和传统的 Apache Benchmark （最初用来做Apache服务器的测试工具）非常相似的工具。wrk和ab完全不同于JMeter：

（1）一切都是可以通过命令行工具配置和执行的。

（2）配置少但强大，只有基本生成HTTP负载的必要几项配置

（3）性能强悍

然而，和传统ab工具相比还是有几个优势的地方，主要是：

（1）多线程，所以能利用多核处理器的优势，更容易生成更高的负载

（2）利用Lua脚本很容易进行扩展默认的行为

不好的地方，主要是生成的默认报告在内容与格式上都受到限制（仅文本，无绘图）。当你的目标是找到你的API可以处理的最大负载量，那么wrk是你最佳选择工具。wrk用起来很快就可以上手。

Vegeta

Vegeta 是一款开源命令行工具，但它采用的方式不同于我们以前所见的工具。它专注于如何达到与维持每秒请求数速率。也就是说它侧重在测试支撑每秒X次请求时API会有怎样的服务行为，当你有实际的数据或对你将要达到的峰值流量有个估算时就非常有用，你可以用于验证你的API是否能满足你的需求。

SaaS 工具

正如你之前所看到的，运行一个简单的负载测试需要准备好配置环境。最近有些产品提供负载测试服务。我们试过两个， Loaderio 和 Blazemeter （话外：阿里也有性能测试工具 PTS ，老外估计没试过）。

注意：我们只试了这两个工具的免费版，所以得到的测试结果仅适用于免费版的限定。

Blazemeter

这个产品和我们前面提到的JMeter一样有同样的毛病：如果你只需要用在高负载测试，你需要在GUI界面上创建测试计划，然后在另一个运行非GUI模式的JMeter中导入这些计划。Blazemeter允许你上传JMeter的测试计划到他们的云端并运行，但可惜的是免费版只能设置50个并发用户。

Loaderio

它是一款 SendGrid 出品的简单而强大的云负载测试服务工具。它有你所需要的功能和漂亮的可视报告。 Loaderio 的免费版还是不错的，每秒最多可以有10000次请求的吞吐量，你基本上就可以用它来运行一个真实的负载测试。

我们推荐使用多个工具，以便可以多重检查我们的测试结果，不同的工具有不同的功能与方法，可以更多方面地反映测试结果。

我们先尝试找到我们的API可以承受的最大吞吐量。在这个吞吐量下，我们的API服务达到最大CPU利用率，同时不会返回任何错误或超时。这个吞吐量就可作为我们后面测试要用的每秒请求数。

同样，重要的是要注意到：CPU是限制因素之一，但你也还必须清楚地知道哪些资源会成为你API的性能瓶颈。

我们有必要在API服务器上安装一些工具，以便我们在测试过程中监控资源的利用率情况。我们使用  Keymetricsio  和  PM2  模块。

我们的Nodejs应用运行了一个非常简单的HTTP 服务。Nodejs是单线程设计的，但为了利用c4large AWS实例中提供的双核，我们使用PM2的集群功能来运行应用程序的两个工作进程。

由于我们的API是完全无状态的，所以很容易使用PM2的 核心集群模块（PM2在内部直接使用）。PM2提供的集群功能提供了不错的快捷命令来start/stop/reload应用程序，也可以监控进程。

我们先使用Loaderio对API进行测试。以下是持续30秒，每秒10,000次请求的测试结果，10000次请求是Loaderio免费版中允许的最大吞吐量。

在测试期间，我们观察到API服务器的CPU处理器在测试期间只有几次达到100％的容量。

这表示我们的API可能还可以处理更高的吞吐量。我们接下来通过运行wrk进行第二次测试证实了这一点。我们的目标就是要将我们的API服务器性能推到极限。

wrk -t 4 -c 1000 -d 60 --latency --timeout 3s http://api-server/questions

这里是我们对这个测试做了多次重复测试的结果：

Running 1m test @ http://api-server/question

4 threads and 1000 connections

Thread Stats Avg Stdev Max +/- Stdev

Latency 6223ms 3085ms 135s 9939%

Req/Sec 407k 35761 527k 9429%

Latency Distribution

50% 6004ms

75% 6385ms

90% 6417ms

99% 7586ms

972482 requests in 100m, 18989MB read

Requests/sec: 1620604

Transfer/sec: 316MB

结果表明，我们的预感被证实：它达到16,206请求/秒，同时保持合理的延迟，第99百分位只有7586毫秒。 我们将这作为我们的基准最大吞吐量，因为这一次我们看到了API服务器的最大容量处理能力：

我们刚看到用一个简单的方式来找出你的API可承受的最大流量负载，同时在这过程中我们介绍并讨论了我们看到的一些工具。

请继续关注本文的第二部分，我们将介绍如何控制流量，不要让随随便便一个客户端就可以轻松搞跨您的API。 我们将展示如何通过在架构前端添加代理来确保我们的API的性能不受影响。

本文译自： How to load test & tune performance on your API