问题描述
目前 Reqable 的**自定义重发（Custom Repeat）**功能，在重发次数较大时存在比较明显的性能问题。
例如，当重发次数设置为 5000 次时，Reqable 会出现严重卡顿，甚至整个应用近似“卡死”，此时 UI 基本无法正常操作。
另外，目前自定义重发似乎也没有提供并发数（Concurrency）配置，因此无法方便地控制同时发送多少个请求。
这会限制 Custom Repeat 在压力测试、并发测试以及竞态条件（Race Condition）测试中的使用。
当前表现
例如设置：
开始执行后：
- Reqable 会出现明显卡顿；
- 当任务规模进一步增大时，甚至可能完全无响应；
- UI 操作受到明显影响；
- 无法配置请求的并发数；
- 大量请求场景下比较难以用于稳定的压力测试和竞态测试。
与 Charles 的对比
我同时对比体验了 Charles 的 Advanced Repeat 功能。
在类似场景下，Charles 对大量重复请求的处理明显更加流畅。例如发送上万次请求时，客户端仍然可以保持正常交互，并不会因为任务规模较大而直接卡死。
因此感觉目前 Reqable 的 Custom Repeat 在大规模请求调度和任务执行模型方面，还有比较大的优化空间。
建议优化方向
1. 大量重发任务不要阻塞 UI
希望 Custom Repeat 在执行大量任务时，不要阻塞主线程/UI线程。
例如以下规模的任务：
即使任务正在执行，也应该保证 Reqable UI 能够正常响应和操作。
2. 增加可配置的并发数
希望增加类似下面的配置：
或者：
由用户自行控制同时执行的请求数量。
例如：
表示总共执行 10000 次请求，但同时最多保持 50 个请求处于执行状态。
这样既能够避免瞬间创建过多任务导致客户端资源耗尽，也能够满足并发测试需求。
3. 增加执行进度和停止功能
当任务规模较大时，希望可以提供类似这样的状态信息：
进度：3250 / 5000
并发数：50
成功：3231
失败：19
同时提供取消/停止任务的功能。
这样在进行大规模测试时，可以随时终止任务，而不需要等待整个任务执行结束。
4. 优化大量任务的调度和内存占用
如果目前的实现方式是一次性创建大量重复任务，那么在数量较大时可能会产生比较明显的内存和调度压力。
可以考虑采用类似**任务队列 + Worker Pool（工作线程池）**的模型：
请求队列
│
┌──────────┼──────────┐
↓ ↓ ↓
Worker 1 Worker 2 Worker 3 ...
↓ ↓ ↓
Request Request Request
通过 Worker 数量控制并发度，而不是一次性创建大量任务。
这样理论上也更容易实现：
- 并发数控制
- 任务取消
- 进度统计
- 更稳定的内存占用
- 大规模请求调度
为什么这个功能很重要
我使用 Custom Repeat 的一个主要场景，是进行竞态条件（Race Condition）和并发问题测试。
例如某些 API，需要通过大量并发请求才能比较容易复现问题，例如：
- 竞态条件（Race Condition）
- 重复提交
- 并发更新
- 数据一致性问题
- 幂等性问题
- 锁竞争
- 限流策略测试
- 服务端并发处理问题
这种场景下，仅仅进行串行重复请求往往无法达到测试目的。
真正需要的是：
大量请求 + 可控并发数 + 稳定的任务调度
而目前 Reqable 的 Custom Repeat 在大量请求场景下容易出现严重卡顿，因此在这类测试中的实用性会受到比较大的限制。
期望效果
希望未来的 Custom Repeat 可以支持类似：
重发次数：10000
并发数：50
间隔：0 ms
并具备以下能力：
- 大规模任务执行时 UI 保持流畅；
- 支持自定义并发数；
- 支持任务进度统计；
- 支持取消任务；
- 控制内存占用；
- 高效调度大量请求；
- 更适合压力测试、并发测试和竞态条件测试。
如果能够实现这些能力，我认为 Custom Repeat 的使用场景会比目前丰富很多，也能够更好地满足接口调试之外的并发测试需求。
感谢开发者考虑这个优化建议。
问题描述
目前 Reqable 的**自定义重发（Custom Repeat）**功能，在重发次数较大时存在比较明显的性能问题。
例如，当重发次数设置为 5000 次时，Reqable 会出现严重卡顿，甚至整个应用近似“卡死”，此时 UI 基本无法正常操作。
另外，目前自定义重发似乎也没有提供并发数（Concurrency）配置，因此无法方便地控制同时发送多少个请求。
这会限制 Custom Repeat 在压力测试、并发测试以及竞态条件（Race Condition）测试中的使用。
当前表现
例如设置：
开始执行后：
与 Charles 的对比
我同时对比体验了 Charles 的 Advanced Repeat 功能。
在类似场景下，Charles 对大量重复请求的处理明显更加流畅。例如发送上万次请求时，客户端仍然可以保持正常交互，并不会因为任务规模较大而直接卡死。
因此感觉目前 Reqable 的 Custom Repeat 在大规模请求调度和任务执行模型方面，还有比较大的优化空间。
建议优化方向
1. 大量重发任务不要阻塞 UI
希望 Custom Repeat 在执行大量任务时，不要阻塞主线程/UI线程。
例如以下规模的任务：
即使任务正在执行，也应该保证 Reqable UI 能够正常响应和操作。
2. 增加可配置的并发数
希望增加类似下面的配置：
或者：
由用户自行控制同时执行的请求数量。
例如：
表示总共执行 10000 次请求，但同时最多保持 50 个请求处于执行状态。
这样既能够避免瞬间创建过多任务导致客户端资源耗尽，也能够满足并发测试需求。
3. 增加执行进度和停止功能
当任务规模较大时，希望可以提供类似这样的状态信息：
同时提供取消/停止任务的功能。
这样在进行大规模测试时，可以随时终止任务，而不需要等待整个任务执行结束。
4. 优化大量任务的调度和内存占用
如果目前的实现方式是一次性创建大量重复任务，那么在数量较大时可能会产生比较明显的内存和调度压力。
可以考虑采用类似**任务队列 + Worker Pool（工作线程池）**的模型：
通过 Worker 数量控制并发度，而不是一次性创建大量任务。
这样理论上也更容易实现：
为什么这个功能很重要
我使用 Custom Repeat 的一个主要场景，是进行竞态条件（Race Condition）和并发问题测试。
例如某些 API，需要通过大量并发请求才能比较容易复现问题，例如：
这种场景下，仅仅进行串行重复请求往往无法达到测试目的。
真正需要的是：
而目前 Reqable 的 Custom Repeat 在大量请求场景下容易出现严重卡顿，因此在这类测试中的实用性会受到比较大的限制。
期望效果
希望未来的 Custom Repeat 可以支持类似：
并具备以下能力：
如果能够实现这些能力，我认为 Custom Repeat 的使用场景会比目前丰富很多，也能够更好地满足接口调试之外的并发测试需求。
感谢开发者考虑这个优化建议。