性能测试亚马逊 vps新加坡不同实例在高并发下的表现评测

1. 测试目标与总体规划

目的：比较 AWS 新加坡（ap-southeast-1）不同实例类型在高并发下的吞吐、延迟与资源利用情况，得出性价比建议。小分段：a) 明确业务场景（静态网站/API/数据库）；b) 选定度量指标（QPS、平均/ p95/p99 延迟、错误率、CPU/内存/网络/磁盘）；c) 确定测试矩阵（例如 t3.small、m5.large、c5.large、r5.large）。

2. 环境准备 — 创建实例

步骤：a) 登录 AWS 控制台，Region 选择 ap-southeast-1（新加坡）；b) EC2 -> Launch Instance，按矩阵创建所需实例，至少准备一台“被测服务端”与一台或多台“压测客户端”；c) 选择 Amazon Linux 2 或 Ubuntu 20.04，配置安全组开放端口（SSH 22、HTTP/HTTPS、压测所需端口）；d) 生成或使用现有 key pair 并保存私钥。小分段：记录每个实例的实例ID、私有IP、公有IP与类型。

3. 基础软件安装

被测端：a) SSH 登录 sudo升级 apt/yum update；b) 安装 Nginx（sudo apt install -y nginx）或轻量 HTTP 服务；c) 准备测试页面或简单 API（静态 html 或 golang 简单 HTTP 处理），并开启 keepalive。压测端：a) 安装 wrk、wrk2、ab、vegeta、jq、sysstat（sar）等工具；b) 若使用分布式压测，可使用 ansible 或脚本批量部署。小分段：示例命令：sudo apt-get install -y build-essential libssl-dev; git clone https://github.com/wg/wrk && make。

4. 网络与权限配置

a) Security Group：允许压测客户端的 IP 到被测服务器 80/443；b) 禁用云提供商的负载均衡缓存或 CDN 干扰，直接测试实例；c) 若跨 AZ 测试需注意带宽限制与公有 IP —— 推荐在同一可用区内测试以减少网络抖动。小分段：在安全组中设置 ICMP 以便 ping 与排查网络。

5. 系统调优（被测端）

a) 增大文件描述符：sudo vim /etc/security/limits.conf，加上 * soft nofile 65536；b) 修改 sysctl 参数（/etc/sysctl.conf）：net.core.somaxconn=65535, net.ipv4.tcp_tw_reuse=1, net.ipv4.tcp_fin_timeout=15, net.ipv4.tcp_max_syn_backlog=40960；sudo sysctl -p；c) 调整 Nginx：worker_connections 65535, worker_processes auto, keepalive_timeout 15；d) 关闭 swap（sudo swapoff -a）并确认内存压力。小分段：每次改动后重启服务并记录 baseline。

6. 系统调优（压测端）

a) 将压测客户端也做相应 ulimit 与 sysctl 调整，确保压测工具不成为瓶颈；b) 若使用单机压测无法达到目标 QPS，增加更多压测实例并使用分布式聚合。小分段：使用 tsocks 或 ssh 隧道时注意带宽与延迟。

7. 设计测试用例与负载模型

a) 定义并发等级（例如 50、200、500、1000、2000 并发）或目标 QPS；b) 设置请求类型（长连接 vs 短连接，静态资源 vs API）；c) 包含冷启、预热、稳定期、陡升与降载阶段。小分段：每个测试至少运行 3~5 次取中位数并保留原始日志。

8. 运行压测：示例命令

使用 wrk（推荐）：wrk -t12 -c500 -d120s --latency http://server-ip:80/endpoint；说明：-t 线程数 -c 并发 -d 持续时间；使用 ab 示例：ab -n 100000 -c 500 http://server-ip/；若要固定 99 百分位延迟，可用 wrk2 或 vegeta 做稳定速率测试：wrk2 -t12 -c200 -d120s -R1000 http://... .小分段：记录每次命令、开始/结束时间与环境快照。

9. 监控与指标采集

实时监控：a) 在被测端运行 sar/mstat/iostat（sudo apt-get install sysstat）例：sar -u 1 > cpu.log；b) 使用 dstat：dstat -cdnmty --output stats.csv 1；c) 收集 Nginx stub_status 或应用端指标；d) 在压测端记录 wrk 输出的 latency distribution 与 errors。小分段：建议同时开启 CloudWatch 基础监控并导出实例级网络吞吐数据。

10. 数据整理与分析

步骤：a) 合并 wrk/ab 输出与 sar/dstat 数据，按时间线对齐；b) 计算 mps（每秒请求数）、95/99 延迟、错误率、CPU/网络/磁盘瓶颈点；c) 制作折线图（QPS vs 延迟、CPU 利用率 vs QPS），并标注阈值（如 80% CPU、网络接近带宽）。小分段：用 Excel 或 Grafana 导入 CSV 做可视化。

11. 对比评估与结论生成

对比维度：a) 峰值 QPS 与稳定 QPS；b) p95/p99 延迟；c) 成本估算（按实例按小时计费算出成本/千次请求）；d) 持久性与抖动（延迟方差）。小分段：給出推荐，例如 CPU 密集型优先 c5 系列，内存敏感选 r5，通用选 m5，入门成本敏感选 t3。

12. 常见问题与排查技巧

问题与排查：a) 高延迟但 CPU 低：检查网络带宽或 socket 队列（ss -s、netstat -s）；b) 错误率飙升：检查应用日志、连接数限制、数据库连接池耗尽；c) 单机压测达不到目标：压测端成为瓶颈，使用多台压测机。小分段：保留完整日志以便定位。

13. 附：脚本化建议与复现性

推荐：a) 用 Terraform/CloudFormation 自动化实例创建；b) 使用 Ansible 脚本化部署服务与监控 agent；c) 将测试用例写成脚本（bash 或 python），并把参数（并发、持续时间、URL）作为变量以便复现与回归。小分段：每次测试保留环境快照与 AMI 作为基准。

14. Q1：在新加坡区域测试时，如何确保网络性能稳定以便公平比较不同实例？

答：确保公平性的方法包括：a) 将被测实例与压测实例放在同一可用区以减少跨 AZ 延迟；b) 使用多次重复测试并取中位数；c) 关闭不相关服务、确保每次测试前系统处于一致状态（重启服务或实例）；d) 在测试前确认没有其他后台流量（用 iftop/iftop -i eth0 监控）；e) 对每个实例类型使用相同的应用镜像与配置。

15. Q2：单台压测客户端无法产生足够并发时该怎么办？

答：两种主流方案：a) 增加压测客户端数量，采用分布式压测，将所有客户端输出汇总（可以用脚本合并 wrk 输出或使用专门的分布式工具如 k6 Cloud/Locust）；b) 在压测客户端做系统层面优化（提高 ulimit、增加线程、调整网络参数），并确保压测客户端的带宽足够。小分段：务必校验客户端 CPU/网络是否成为瓶颈。

16. Q3：如何把测试结果转化为实例选择与成本决策的建议？

答：步骤：a) 计算每种实例在目标 QPS 下的平均延迟与错误率；b) 计算单位 QPS 的小时成本（实例小时价 / 实例可稳定承载 QPS）；c) 根据业务对延迟的容忍度和预算选择（低延迟优先选 c5/m5，高内存需求选 r5，预算受限可选 t3 但监控抖动）；d) 给出备用策略（例如在高峰期用 autoscaling 同时选择性价比更高的实例混合部署）。小分段：用表格列出实例、稳定 QPS、p95、小时价、成本/QPS 进行决策。