挑战赛｜云上开发案例征集——基于阿里云 ECS u2a 的轻量级 Web 性能监测与并发测试平台实践

一、项目背景与研究目标

为实践云服务器的应用开发与部署流程，了解云服务器在不同负载条件下的资源使用情况及Web服务性能，本项目基于阿里云ECS u2a云服务器（2 vCPU、4 GiB 内存，Ubuntu 24.04 LTS），开发一个轻量级Web性能监测与可视化实验平台ECScope。

平台采用Flask作为后端框架，通过psutil采集服务器CPU、内存、磁盘等运行指标，并结合HTTP性能测试工具，实现不同并发条件下的Web服务性能测试。测试结果包括每秒请求数（RPS）、响应时间、请求失败率等指标，通过网页进行可视化展示与对比分析。

本项目主要完成ECS云服务器环境配置、Web应用开发与部署、系统资源监测及HTTP并发性能测试，并通过实际实验分析轻量级云服务器在不同负载条件下的性能表现。

二、实验环境与技术选型

本项目使用阿里云 ECS u2a 实例作为实验环境，服务器配置如下：

ECScope采用轻量级Web架构，使用的主要技术如下：

考虑到服务器仅配置 2 vCPU 和 4 GiB 内存，平台采用较为轻量的技术方案，避免引入不必要的服务和依赖，降低实验平台自身的资源开销。

三、ECS 云服务器环境配置与部署准备

3.1 远程连接与环境配置

通过阿里云 Workbench 连接 ECS 实例，进入 Ubuntu 终端进行环境配置。

首先更新系统软件包索引，并安装 Nginx：

sudo apt update
sudo apt install -y nginx

安装完成后，启动 Nginx 并设置开机自启：

sudo systemctl enable --now nginx
sudo systemctl status nginx

通过以下命令测试本机 HTTP 服务：

curl -I http://127.0.0.1

返回 HTTP/1.1 200 OK，表明 Nginx 已正常启动并能够响应 HTTP 请求。

3.2 公网网络与安全组配置

ECS 实例初始仅配置了私有 IP 地址 172.28.28.228，无法直接通过公网访问服务器上的 Web 服务。

在阿里云 ECS 控制台中，通过修改公网带宽配置，为实例分配公网 IPv4 地址。随后在实例关联的安全组中添加 HTTP 入方向规则：

完成配置后，在本地浏览器中通过 http://115.29.16.137 访问 Nginx 默认页面，成功验证服务器的公网 HTTP 访问能力。

在 ECScope 正式部署阶段，进一步添加 TCP 443 端口入方向规则。Nginx 将 HTTP 请求重定向至 HTTPS，并通过反向代理将请求转发至本机 Flask 服务。测试使用自签名 TLS 证书，因此浏览器会提示证书不受信任，后续公开使用时需要更换可信证书。

3.3 部署过程中的问题排查

环境配置过程中主要遇到了以下问题：

通过以上操作，完成了 ECS 基础 Web 运行环境搭建及公网访问验证，为后续 ECScope 平台部署和性能测试提供了运行环境。

四、ECScope 平台设计与实现

ECScope 采用轻量级 Web 架构，前端使用原生 HTML、CSS 和 JavaScript，后端基于 Python Flask 实现。平台主要由系统资源监测、HTTP 性能测试、实验数据存储和结果可视化四个模块组成。

4.1 系统资源监测

平台通过 psutil 库获取服务器的 CPU 使用率、内存占用、磁盘使用率及 CPU 核数等信息。Flask 后端通过 /api/metrics 接口提供监测数据，前端定期请求该接口并更新页面，实现服务器运行状态的动态展示。

4.2 HTTP 性能测试

平台使用 ApacheBench（ab）执行 HTTP 并发测试，测试目标固定为 Nginx 提供的本机静态页面 http://127.0.0.1:8080/bench.html。

用户可以在网页中选择 1、5、10、20 四种并发数，并设置是否启用 HTTP Keep-Alive。后端根据测试参数执行 ApacheBench，解析测试结果，获取每秒请求数（RPS）、平均响应时间、P95 响应时间及请求失败情况等指标。

为控制测试负载，平台将单次请求数量限制在 2000 次以内，同一时间仅允许执行一个测试任务，并通过管理员令牌限制实验接口的访问权限。

4.3 数据存储与可视化

平台采用 SQLite 保存实验参数、性能指标、执行状态及 ApacheBench 原始输出，便于查询历史记录和复核测试结果。

前端通过表格展示实验记录，并使用 Canvas 绘制 RPS 对比图表，从而直观比较不同并发数及 Keep-Alive 配置下的性能表现。

4.4 平台部署与运行验证

ECScope 部署至阿里云 ECS 后，通过 Nginx 反向代理提供 Web 访问，后端服务由 Gunicorn 和 systemd 管理。

实际运行中，平台能够获取服务器 CPU、内存、磁盘等系统指标，并通过网页触发受限 HTTP 性能测试。测试完成后，结果自动保存至 SQLite，并在历史记录表格和 RPS 图表中展示。

从 GitHub 下载 ECScope 项目代码归档，解压至 ECS 的 /opt/ecscope-lite 目录，并执行 Ubuntu 安装脚本，完成 Python 虚拟环境、依赖、Nginx 和 systemd 服务配置。

cd /opt/ecscope-lite
sudo bash deploy/install-ubuntu.sh

平台后端采用 Gunicorn 运行，通过 systemd 实现服务管理，并由 Nginx 提供 HTTPS 反向代理。使用以下命令检查部署状态：

sudo systemctl status ecscope --no-pager
sudo nginx -t
curl -I http://127.0.0.1:8080/bench.html
curl -k -I https://127.0.0.1

检查结果显示，ECScope 服务正常运行，Nginx 配置验证通过，性能测试页面及 HTTPS 反向代理均返回 HTTP 200。

平台内置实验单次最多执行 2,000 次请求，主要用于功能验证和交互展示。第六章进一步使用终端执行更长时间的重复实验，以获取用于性能分析的数据。

五、性能实验设计

本项目使用 ApacheBench（ab）对阿里云 ECS u2a 实例上的 Nginx Web 服务进行性能测试。测试目标为本机静态页面 http://127.0.0.1:8080/bench.html，主要分析不同并发数及 HTTP Keep-Alive 配置对服务性能的影响。

5.1 实验参数与评价指标

实验包含 ECScope 平台内置测试和终端补充测试两部分。平台内置测试每次最多发送 2,000 个请求，用于验证性能测试、结果存储与可视化功能；终端补充测试每次发送 100,000 个请求，每组重复 3 次，用于获得相对稳定的性能统计结果。

正式性能实验的主要参数如下：

主要评价指标如下：

• RPS（Requests Per Second）：每秒完成的请求数量，用于衡量 Web 服务吞吐量。
• 平均响应时间：采用 ApacheBench 输出的第一条 Time per request (mean)，单位为 ms。
• P95 响应时间：95% 的已完成请求耗时不超过的数值，用于观察请求延迟分布。
• 失败请求数：ApacheBench 记录的 Failed requests，用于判断测试过程中是否出现请求失败。
• 系统资源占用：通过 ECScope 的 psutil 接口读取 CPU、内存及磁盘使用情况，作为服务器运行状态的辅助参考。

5.2 不同并发数下的性能测试

第一组实验分析并发请求数量对 Web 服务吞吐量和响应时间的影响。

保持请求总数为 100,000，关闭 Keep-Alive，分别设置并发数为 1、5、10、20。

以并发数为 10 为例，ApacheBench 测试命令如下：

ab -n 100000 -c 10 http://127.0.0.1:8080/bench.html

其中，-n 表示请求总数，-c 表示并发请求数。

为减少单次测试的偶然性，使用 Shell 循环自动执行全部测试，每种并发配置重复 3 次：

mkdir -p /root/ecscope-results/extended

for c in 1 5 10 20; do
  for r in 1 2 3; do
    ab -n 100000 -c "$c" \
      http://127.0.0.1:8080/bench.html \
      > "/root/ecscope-results/extended/c${c}-run${r}.txt"
  done
done

测试结果分别保存为文本文件，后续计算各并发配置下的平均 RPS、标准差及平均响应时间，并比较不同负载下的性能变化。

5.3 HTTP Keep-Alive 性能对比

第二组实验分析 HTTP Keep-Alive 连接复用机制对 Web 服务性能的影响。

固定并发数为 10、请求总数为 100,000，分别测试关闭和开启 Keep-Alive 的情况。

关闭 Keep-Alive：

ab -n 100000 -c 10 http://127.0.0.1:8080/bench.html

开启 Keep-Alive：

ab -k -n 100000 -c 10 http://127.0.0.1:8080/bench.html

其中，-k 参数表示启用 HTTP Keep-Alive，允许多个请求复用已有连接。

开启 Keep-Alive 的重复实验命令如下：

for r in 1 2 3; do
  ab -k -n 100000 -c 10 \
    http://127.0.0.1:8080/bench.html \
    > "/root/ecscope-results/extended/c10-ka-run${r}.txt"
done

对两种配置分别进行 3 次测试，比较其平均 RPS、请求延迟及失败请求情况，分析连接复用对 HTTP 服务性能的影响。

5.4 实验数据记录与方法说明

ApacheBench 测试结果通过输出重定向保存为文本文件，保留原始性能数据。使用以下命令提取主要指标：

grep -H -E 'Requests per second:|Time per request:|Failed requests:|Non-2xx responses:|95%' \
  /root/ecscope-results/extended/*.txt

其中，RPS 和平均响应时间由 ApacheBench 直接统计，P95 取自请求耗时百分位分布。实验结果按并发配置进行汇总，并使用 Python Matplotlib 绘制吞吐量和延迟对比图。

需要说明的是，ApacheBench 与 Nginx 均运行在同一台 ECS 实例上，测试请求通过 127.0.0.1 回环地址发送，不经过公网链路。因此，实验结果主要反映当前环境下的本机 HTTP 请求处理性能，不能直接代表公网用户的访问体验。同时，压测工具本身也会占用服务器资源，可能对测试结果产生影响。

实验通过固定测试页面、请求数量及其他测试条件，并对每组配置进行重复测量，降低偶然因素对结果的影响。

六、实验结果与分析

在阿里云 ECS u2a（2 vCPU、4 GiB）实例上，使用 ApacheBench 对 Nginx 提供的本机静态页面进行性能测试。主要分析不同并发数及 HTTP Keep-Alive 配置对服务吞吐量和响应延迟的影响。

为降低短时间测试的偶然性，除 ECScope 平台内置的单次 2000 请求测试外，还通过终端进行了补充实验。补充实验每次发送 100,000 个请求，每组重复 3 次，以下主要采用重复实验的统计结果进行分析。

在 ECScope 平台内置的性能测试中，分别设置并发数为 1、5、10、20，每次执行 2,000 次 HTTP 请求。平台记录的 RPS 分别约为 13,530、18,179、17,924 和 18,056，失败率均为 0%。

测试结果通过平台的历史记录表格和 RPS 图表进行展示，验证了性能测试、数据解析、SQLite 存储与可视化模块在 ECS 环境下的正常运行。

由于单次 2,000 请求的测试时间较短，后续使用 ApacheBench 进行了每组 100,000 次请求、重复 3 次的补充实验，并以补充实验的统计结果作为主要性能分析依据。

6.1 不同并发数下的性能表现

实验分别设置并发数为 1、5、10、20，保持请求总数为 100,000，关闭 HTTP Keep-Alive。每组重复测试 3 次，统计平均 RPS、RPS 标准差、平均响应时间和 P95 响应时间。

表 1 不同并发数下的性能测试结果

注：平均 RPS、平均延迟均为三次实验的算术平均值，RPS 标准差采用样本标准差；失败请求数为每次实验记录值，三次测试均为 0。

从吞吐量结果来看，并发数由 1 增加至 5 时，平均 RPS 从 13,503.54 提升至 18,171.57，提升约 34.57%。当并发数进一步增加至 10 和 20 时，平均 RPS 分别为 18,151.92 和 18,306.08，变化幅度较小，基本维持在每秒 1.8 万次请求左右。

从响应时间来看，平均请求延迟随并发数增加而上升，从并发数为 1 时的 0.074 ms 增加至并发数为 20 时的 1.093 ms。各组实验均未出现 ApacheBench 报告的失败请求。

三次重复测试的 RPS 标准差均较小，说明在相同配置下测试结果较为稳定。整体来看，在本次实验条件下，适当提高并发数可以增加服务吞吐量，但当并发数达到一定水平后，继续增加并发数并未带来明显的吞吐量提升，同时平均响应延迟继续增加。

6.2 HTTP Keep-Alive 性能对比

为分析 HTTP 连接复用对性能的影响，在并发数为 10、单次请求数为 100,000 的条件下，分别开启和关闭 HTTP Keep-Alive，每种配置重复测试 3 次。

表 2 HTTP Keep-Alive 性能对比结果

实验结果显示，关闭 Keep-Alive 时，平均 RPS 为 18,151.92；开启后提升至 60,913.95，约为关闭时的 3.36 倍，吞吐量提升约 235.58%。

同时，平均请求延迟由 0.551 ms 降低至 0.164 ms，降幅约为 70.18%。两种配置下均未出现失败请求。

Keep-Alive 允许多个 HTTP 请求复用已有的 TCP 连接，减少重复建立和关闭连接带来的开销。本次实验中，开启 Keep-Alive 后吞吐量明显提升，说明连接复用能够有效降低此类高频、小数据量 HTTP 请求的处理开销。

需要注意的是，开启 Keep-Alive 后三次测试的 RPS 存在一定波动，其标准差高于关闭时的结果。此外，ApacheBench 输出的 P95 使用整数毫秒表示，表中的 0 ms 不代表实际请求延迟为零，而是受到统计输出精度的限制。

6.3 实验结果讨论

综合两组实验结果，可以得到以下观察：

1. 并发数与吞吐量并非线性关系。 在本次测试中，较低并发数下增加并发能够提升 RPS，但并发数从 5 增加到 20 后，吞吐量基本稳定，而平均响应延迟持续增加。
2. Keep-Alive 对短连接密集型请求具有明显影响。 对于本次静态页面测试，开启连接复用后，服务器吞吐量显著提高，平均请求延迟降低。
3. 重复实验结果具有一定稳定性。 相同配置下三次测试的吞吐量总体接近，但不同配置仍存在一定程度的性能波动。

七、总结

本项目基于阿里云 ECS u2a（2 vCPU、4 GiB）实例，完成了 ECScope Lite Web 性能实验平台的开发与部署，实现了服务器资源监测、HTTP 并发测试、实验记录存储及结果可视化等功能。

实验结果表明，在本机 Nginx 静态页面测试中，随着并发数增加，服务吞吐量先上升后趋于稳定；开启 HTTP Keep-Alive 后，平均 RPS 由 18,151.92 提升至 60,913.95，约为原来的 3.36 倍。

本次实验主要针对本机静态页面，尚未涉及公网访问延迟及复杂动态应用的性能测试。后续可进一步引入独立压测客户端和更完整的系统资源采样，以分析不同应用负载下的服务器性能表现。