从 4 个到 16 个在途请求：把吞吐、内存和退出放在同一张账上¶
后端约 5 ms 才回复一个请求，应用希望提高吞吐。最直接的改动是增加在途额度。但这个变化同时影响活跃请求、后端压力和停止收尾，先建立账本再判断是否值得。
本章依据受约束 SDK 的固定结构和 2026-10-02/03 历史基准。历史测量对应当时实现；本次公开源码经过后续修订，性能需要按新快照重新测量。命令与数据口径见额度案例，源码见版本入口。
先分清事实、假设和未知¶
| 输入 | 数值或条件 | 性质 |
|---|---|---|
| 请求 payload | 256 bytes，回显校验 | 历史实验配置 |
| 后端 | 普通响应约 5 ms，允许等待重叠 | 模拟器设计 |
| 候选额度 | 4 与 16；应用窗口等于额度 | 历史实验配置 |
| 样本 | 每配置五轮，每轮 10000 请求 | 历史实验记录 |
| 示例吞吐目标 | 2000 requests/s | 本文设计假设 |
| 示例时延目标 | 每轮成功样本 p99 小于 10 ms | 本文设计假设 |
| 示例 SDK 内存额度 | 512 KiB | 本文设计假设，不是已有产品指标 |
| OS、后端进程和内核开销 | 尚未纳入完整目标平台测量 | 未知，决定最终内存能否批准 |
这些假设用于展示评审过程，不能写成项目已经达到的产品需求。
固定结构账不能重复相加¶
历史 aarch64 Linux/musl 预算接口输出：
runtime_bytes 已经包含嵌入的 core。owner 栈是配置的 256 KiB，backend_stack_bytes=0 表示该接口没有统计独立子进程栈，不能理解为后端不占内存。当前尺寸以下载版本在目标环境中的 sdk_resource_budget() 为准。
已计固定结构与 owner 栈预算 = 131280 + 262144 = 393424 bytes
相对假设的 512 KiB 额度，剩余 = 524288 - 393424 = 130864 bytes
剩余约 127.8 KiB 还要覆盖 libc/pthread、guard、子进程、内核 socket、页表、日志和应用资源。SDK 接口输出不等于进程 RSS，更不等于整个平台 RAM。基准自身还有采样数组等测量开销，生产应用需要单独计算。
固定容量中，请求 payload 区为 16×256=4096 bytes，入口事件里的 payload 区为 64×1024=65536 bytes，数据 payload 区为 32×1024=32768 bytes。这些是包含在结构中的分解项，不再额外加到 runtime 总数里；元数据、输出缓冲和对齐也需要保留。
两个候选放在相同条件下比较¶
| 项目 | 候选 A：额度 4 | 候选 B：额度 16 |
|---|---|---|
| 活跃请求 payload 上限 | 1024 bytes | 4096 bytes |
| 本版实际固定结构分配 | 保留 16 槽及其他固定数组 | 保留相同数组 |
| 五轮历史吞吐 | 663.24～664.96 requests/s | 2640.73～2650.87 requests/s |
| 五轮历史 p99 范围 | 6.835～7.176 ms | 7.212～7.748 ms |
| 失败/拒绝/内容错误 | 均为零 | 均为零 |
| 相对示例吞吐目标 | 不满足 | 历史基准满足 |
| 相对示例 p99 目标 | 历史基准满足 | 历史基准满足 |
| 完整目标平台 RAM | 待测 | 待测 |
| 真实设备和慢 callback | 待测 | 待测 |
4 是较严格的在途约束，却没有在当前固定结构实现里省 RAM。16 使等待重叠，历史吞吐约提高四倍，同时历史 p99 略增。对于本文的模拟器吞吐目标，可以选择 16 继续验证；完整内存与真实设备约束仍要确认，不能据这张表批准实际芯片。
如果需要节省 RAM，必须改变结构容量、数据裁剪或所有权方案，再用 linker map、预算接口和运行峰值验证。只缩小配置中的 request_limit 不会缩小已经分配的数组。
停止预算也随义务数量计算¶
本版入口至多 64 项，accepted 请求至多 16 项。关闭 admission 后，owner 必须拒绝剩余 ticket，并终结 live 请求。停止案例
假设每次请求通知最多耗时 100 μs，单算 64+16 次请求通知约为 8 ms。这是规划算例，尚未测得最坏回调时间；状态通知、正在执行的回调、后端退出和 OS 调度仍需另计。回调能无限阻塞时，无法由有限队列推出有限停止。
stop_wait() 给等待者一个时间预算，超时保留对象继续收尾。业务层需要决定何时再次等待、如何诊断慢回调以及何时隔离故障。
队列排空公式先写到达前提¶
假设已有积压为 Q bytes，服务率恒为 μ bytes/s：
教学算例：积压 48 KiB，服务 64 KiB/s，新到达 32 KiB/s。关闭新到达以后约 0.75 s 排空；继续到达则约 1.5 s。实际设备的服务率、批处理和调度会变化，需要用相同测量边界校验。扩大缓存只吸收有限突发，长期消费者落后仍会填满任何有限队列。
把本次决定和下一次验证连起来¶
本教学流水线使用 16 作为吞吐候选；保留 4 作为对照。以下条件触发重新选择：数据完整性失败、真实 p99 超过 SLO、资源峰值越界、慢回调导致入口持续积压、恢复时长超预算，或者设备实际只串行执行。
下一次实验固定请求与版本，分别加入有界慢 callback 和设备服务变化，测输入等待、执行、IO 与交付时间，再调整额度。CPU 总利用率和单次吞吐不足以定位瓶颈。内存与性能机制
功耗与热采用同一业务负载，记录活动、空闲、睡眠与转换能量。宿主基准没有功耗仪器数据，也没有真实芯片成本；这两项保持未知并进入平台 PoC。
进一步推导容量¶
当平均吞吐已足够、短时突发仍填满队列时，继续看 负载包络与 admission，将到达、暂停和服务能力推成容量与时延边界。