香港服务器15M与30M CN2带宽，网站并发容量如何测算？

网站的容量不是由“在线人数”单独决定的，而是由这些用户在高峰时段产生多少请求、每次需要传输多少数据，以及服务器处理请求需要多久共同决定。几十名用户同时下载大文件，可能比几百名用户间歇阅读文字页面更早占满带宽。因此，测算香港服务器15M与30M CN2带宽的并发容量，应把业务负载转换为出站流量、请求速率和应用处理压力，而不是直接套用“多少兆支持多少人”的固定比例。

在其他配置、线路交付条件和请求类型相同的情况下，30M的标称带宽是15M的两倍，带宽受限时可提供约两倍的传输预算；但如果瓶颈在CPU、数据库或应用连接池，网站并发能力不会随之翻倍。按下文示例的余量和传输效率计算，15M与30M可用于应用数据的预算分别约为1.18MB/s和2.36MB/s。若一次完整页面访问需要从源站传输500KB，约对应每秒2.36次和4.73次页面访问；这只是带宽维度的估算，不是具体服务器的实测承载保证。

一、建立负载画像：把在线人数转换为请求和数据量

区分在线会话、在途请求和传输连接

“网站并发”至少有三种口径，容量规划时不能混用。

例如，100名用户都在阅读页面，未必持续产生网络流量；10名用户各以1MB/s下载文件，则需要合计80Mbps的应用数据吞吐，已经明显超过15M和30M的范围。

对交互型网站，可以使用两组关系：

请求速率 ≈ 活跃用户数 × 每名用户每秒发起的请求数。

平均在途请求数 ≈ 每秒请求数 × 平均请求完成时间。

第二个关系适用于相对稳定的观察区间。例如，每秒50个请求、平均完成时间0.2秒，平均在途请求数约为10。若响应时间升到1秒，即便请求速率不变，在途请求也会增长到约50个。但这种平均值关系不能直接描述所有用户同时点击时的瞬时冲击，短时突发还需要单独验证。

统计实际从香港源站传出的字节

容量计算需要的是“传输数据量”，不是页面文件夹大小，也不是数据库容量。

对于网页，应统计一次访问中由香港服务器实际返回的HTML、脚本、样式、图片和接口响应。压缩会减少传输字节，浏览器缓存与CDN命中会减少源站请求，但首次访问、缓存失效和新增资源仍可能形成明显峰值。

对于接口，应按请求类型拆分。登录、搜索、商品详情和批量导出不仅响应大小不同，CPU与数据库消耗也不同。一个20KB的简单查询接口和一个20KB的复杂报表接口，带宽负载相近，计算负载却可能相差很大。

至少应整理以下信息：

• 高峰活跃用户数，以及每名用户的操作间隔。
• 每种请求的占比、平均响应字节和较大响应的分布。
• 页面资源是否经过压缩，哪些资源由CDN或浏览器缓存承担。
• 下载、上传、导出等长时间传输任务的数量及单连接目标速率。
• 常态高峰、活动高峰和未来增长预期。

这里的平均响应大小最好使用“总响应字节÷总请求数”得到，避免简单平均几个接口的大小而忽略请求占比。同时保留大文件和大响应的单独统计，否则平均值可能掩盖短时带宽冲击。

请求量和日流量都不能替代峰值

每天传输20GB数据，按十进制单位计算：

平均速率 = 20 × 8 × 1000 ÷ 86400 ≈ 1.85Mbps。

这个平均值看起来不高，但若20GB集中在1小时内传输：

所需平均速率 = 20 × 8 × 1000 ÷ 3600 ≈ 44.44Mbps。

因此，日流量适合判断长期用量，不能单独用于确定15M或30M是否足够。页面访问、定时导出和活动流量，都应放到实际发生的时间窗口内测算。

二、资源变量：把15M与30M换成可使用的容量预算

先统一带宽单位和余量口径

本文将15M、30M按15Mbps、30Mbps理解，并采用十进制单位：

• 1Mbps = 1,000,000bit/s。
• 1MB = 1,000,000Byte，1KB = 1,000Byte。
• 1Byte = 8bit，因此15Mbps的理论传输速率为1.875MB/s，30Mbps为3.75MB/s。

理论速率不宜全部用于业务规划。链路协议开销、重传、流量突发，以及同一出口上的其他任务，都会消耗可用空间。

为了展示计算过程，下面采用两个示例参数：

目标带宽利用率为70%；应用数据占链路传输字节的比例为90%。

前者用于留出容量余量，后者用于将链路预算换算为应用数据预算。90%不是所有业务固定适用的效率，实际应结合包大小、协议开销、重传和监控统计口径校准；70%也不是产品规定的上限。

应用数据预算 = 标称带宽 × 目标利用率 × 应用数据比例 ÷ 8。

如果使用网卡字节计数直接计算带宽利用率，就不应再对同一数据重复增加协议开销。若使用网站日志中的响应正文大小，则需要确认日志是否包含响应头、压缩后的字节，以及所有静态资源流量。

不同请求类型对应多少吞吐量

利用上表预算，可以得到一组同口径估算：

带宽允许的请求速率 = 应用数据预算 ÷ 单次请求的平均传输大小。

表中的页面访问量是“一次访问涉及的全部源站数据”，接口行则是“一个接口请求”。如果一个页面还触发10个接口请求，不能将页面访问次数直接当成总请求数。

持续下载一行只表示在示例预算下可安排的连接数量。若允许更多用户共享带宽，连接数可以增加，但每名用户的实际下载速率会下降。

将页面访问量换成活跃用户数

设每名活跃用户平均30秒访问一个新页面，每次从源站传输500KB，则：

活跃用户容量 ≈ 每秒页面访问量 × 平均访问间隔。

在上述预算下，15M对应约70名活跃用户，30M对应约141名活跃用户。这里按整数向下取整，且不包含额外下载、上传或后台任务。

如果用户平均10秒就刷新一个页面，同样的带宽预算只对应约23名和47名活跃用户；如果缓存使每次源站传输量降为100KB，则容量又会明显增加。因此，这些数字不能脱离“访问间隔、源站传输量、峰值分布”单独引用。

以100名活跃用户、30秒一次访问、500KB源站数据为例：

1. 页面访问速率：100 ÷ 30 ≈ 3.33次/秒。
2. 应用数据速率：3.33 × 0.5 ≈ 1.67MB/s。
3. 应用数据带宽：约1.67 × 8 ≈ 13.33Mbps。
4. 按90%应用数据比例折算，链路需求约为14.81Mbps。

该负载已接近15M的标称上限，并超过其示例规划预算；对30M而言，约占标称带宽的49.4%。如果其他资源有余量，30M更适合承接这一负载及后续增长。

CN2线路与带宽大小是不同变量

CN2线路主要涉及网络路径与传输质量，15M或30M则描述带宽规格。线路质量会影响时延、丢包、重传和连接吞吐，但不能仅凭“CN2”标签推导服务器能承载多少请求。

将上述预算用于具体香港服务器产品前，应分别确认：

采购或升级时还应确认带宽调整是否需要迁移或中断，以及价格差额、调整周期和可能存在的用量费用。不能只比较“15M”和“30M”两个数字，而忽略交付口径。

围绕香港网站的并发承载与容量规划，A5数据提供覆盖入门建站、Xeon Gold及AMD EPYC平台的香港物理服务器，并有CN2、国际线路及不同带宽档位的产品选择。大内存与SSD、NVMe存储配置，为动态页面处理、数据库缓存和接口服务提供资源基础；香港大带宽系列则提供多档CN2带宽资源，让网站增长阶段的网络预算与计算、存储需求有相应的产品承接。

三、瓶颈判断：带宽翻倍为什么不等于并发翻倍

用最先达到边界的资源确定容量

网站可用请求容量，可以理解为多个资源边界中的较低者：

可用请求速率 ≈ 带宽允许速率、CPU允许速率、数据库允许速率及其他组件允许速率中的较低值。

这些边界应在同一业务请求组合下评估。不能拿静态文件测试出的带宽吞吐，与复杂搜索接口测试出的CPU吞吐直接拼成结论。

举一个用于解释关系的计算案例：应用有4个CPU核心，每个请求平均消耗20毫秒CPU时间，计划将应用CPU使用量控制在总计算资源的60%。忽略其他消耗时：

CPU侧请求预算 = 4 × 60% ÷ 0.02 = 120次/秒。

这里的20毫秒指实际CPU执行时间，不是包含数据库等待的完整响应时间。如果应用还有后台任务或其他计算开销，预算需要继续下调。

对平均响应20KB的接口，前述带宽预算约为59次/秒和118次/秒。在CPU侧预算约120次/秒、数据库也能满足负载的条件下，15M更容易先受带宽限制，升级30M有较明显的作用。

若复杂接口的应用安全容量只有40次/秒，那么15M已能覆盖其响应流量；改为30M也不会自动让应用处理80次/秒。这时应优先处理慢查询、计算开销或工作进程排队。

根据指标组合识别瓶颈

判断时还要观察连接数、工作进程排队、连接池等待和错误率。响应变慢会让请求占用资源更久，使在途请求数量增加，进一步放大排队。

因此，不能仅以“还能打开页面”作为容量合格的标准。容量边界应同时满足响应时间、错误率和关键业务成功率要求。

压测必须区分带宽测试与业务测试

交付验收和业务容量验证是两件事。前者检查约定带宽及线路条件，后者检查真实请求组合能否达到服务目标。

测试带宽时，应选择有足够接收能力的测试端，并结合不同时间段、目标地区和必要的多连接测试，避免把单连接或测试端限制误判为服务器出口限制。

测试业务时，应保留实际的登录状态、缓存行为、请求比例和响应大小，逐步增加负载，同时记录请求速率、完成请求数、响应时间、错误率及服务器资源。如果测试只反复请求一个已缓存的小文件，结果不能代表动态网站容量。

四、容量余量：将增长、活动和数据规模纳入选择

以高峰为基准，而不是以日均为基准

有稳定流量的网站，可以从业务高峰时段的短窗口带宽统计入手，例如观察1分钟或5分钟窗口的利用率，再结合P95、P99和短时最大值判断。窗口越长，越容易把瞬时尖峰平均掉。

增长预测可以使用：

未来峰值需求 = 基准峰值 ×（1 + 周期增长率）的周期次数方 × 新增活动系数。

其中，活动系数只用于基准峰值尚未覆盖的新增活动，不应把已经包含在基准中的促销峰值再次放大。

例如，当前高峰链路需求为8Mbps，预计月增长20%，三个月后还需要应对一次额外增加30%流量的活动：

未来峰值 ≈ 8 × 1.2³ × 1.3 ≈ 17.97Mbps。

该值超过15M的标称容量；在30M方案下，约占带宽的59.9%，低于前文示例的70%规划线。若应用和数据库资源也满足要求，30M更适合作为该规划周期的带宽规格。

流量增长并不总与用户增长成正比。页面图片变大、接口新增字段、下载文件增加，都可能让“每名用户的数据量”上升。预测时应同时跟踪用户数量和单位访问数据量。

数据规模还会改变计算与存储瓶颈

数据库从较小规模增长到更大规模后，即使请求数不变，也可能因索引、缓存命中和查询扫描范围变化而增加处理时间。文件库增大，也可能带来更重的备份、同步和存储需求。

如果备份、批量导出或文件分发使用同一出口，应将它们加入带宽预算。不能把全部带宽分配给前台请求后，再将后台任务视为“额外可用”。

对于图片或下载占比较高的网站，可以评估CDN或独立文件分发资源。这样做减少的是香港源站承担的流量，但应同时计算回源、缓存失效、存储和分发成本。高缓存命中率下的低源站负载，也不代表首次访问或集中回源时仍然足够。

15M与30M分别适合什么条件

成本比较应围绕“能否满足同一业务目标”展开。15M价格较低并不意味着在频繁逼近出口上限时更划算；30M也不应在缺乏带宽需求时被当成解决所有性能问题的升级选项。

五、扩容触发点：将估算变成可执行的监控规则

建立一组互相验证的指标

带宽监控至少应覆盖入站和出站速率、短时峰值、重传及丢包情况。网站监控应覆盖请求速率、响应字节、P95/P99响应时间、超时率和错误率。资源监控还应包括CPU、内存、磁盘时延、数据库等待及连接池状态。

上传型业务需要特别确认入站能力和交付限制，不能直接套用本文以出站流量为主的预算。若产品限制的是双向合计，也必须按对应口径重新计算。

建立基线时，应覆盖普通业务日、自然高峰和已知活动。仅观察低流量时段，无法确定扩容阈值。

用规划线、体验线和提前量确定触发条件

以下可作为初始规则，再根据业务容忍度调整：

• 规划预警：多个正常高峰日的P95出站利用率达到约60%～70%，开始评估增长预测和升级周期。
• 短时风险预警：带宽多次接近标称上限，同时响应时间、重传或超时上升，排查是否存在出口竞争。
• 扩容触发：预计在升级交付周期加安全提前量内，峰值需求将超过规划预算。
• 非带宽触发：CPU、数据库或应用队列先达到边界，优先扩展或优化对应资源，而非仅增加出口。

采用70%规划线时，15M与30M对应的链路预算分别为10.5Mbps和21Mbps。若当前正常峰值为8Mbps、每月增长20%，两个月后约为11.52Mbps，已经超过15M的规划线，应在到达该时点前完成验证与升级安排。这里是容量管理示例，不是所有网站必须采用的统一阈值。

扩容后，应在相同请求组合、相同缓存状态和相近网络条件下重新验证：请求完成量是否提高，P95响应时间是否改善，错误率是否受控，以及CPU或数据库是否成为新的瓶颈。只有确认增加的带宽被有效利用，容量推演才算完成验证。

对香港服务器15M与30M CN2带宽的选择，最终应落到一张可持续更新的容量表：记录峰值请求速率、平均源站响应大小、预计增长、带宽利用率和应用资源边界；再以业务响应目标校准安全余量，以交付周期确定升级提前量。这样得到的并发容量有明确条件，也能随着业务变化及时修正。