项目使用的是 azure java sdk ， 需要能够满足 500 并发下， 小语种 stt 的性能稳定性。
现在是使用 go 写的脚本做压测，使用一个 4s 中的音频去模拟实时语音流去测试。。文件流传输后，就关闭 wss 链接
目前测试是， 三台服务器，15 个 stt 的 key ，额度肯定是够的， 然后在 100 并发情况下不管是一台还是三台服务器性能都比较稳定。
但是达到 200,300 甚至 500 的时候，性能就骤降， 从平均 1s 左右的的首字返回，变成了中文 3s+，小语种 5s+的情况。1 台服务和三台服务均是这样的情况。不知道有没有大佬知道解决方案
另外， 服务器都是 8 核 32G ， 因为之前测试的时候，16g 内存，100 个并发的 stt （链接的创建以及销毁都会涉及到 azure sdk 的资源创建以及关闭），就会让服务崩溃重启，到 32g 才稳定下来，不知道这种有没有解决方案，16g 内存，100 个并发就崩溃也是够够的
希望有大佬能够帮忙解答下。。。可以付费咨询，谢谢
第 1 条附言 · 7 小时 18 分钟前
本质上，我的项目就是售卖 azure 实时 stt 的。。。客户通过 wss 链接我的服务，然后服务端通过 azure 的 sppech sdk 调用 stt ， 最后返回识别的文本。
上面的问题，就是在压测的时候碰到的。 高并发下，体验效果直接骤降
上面的问题，就是在压测的时候碰到的。 高并发下，体验效果直接骤降
 |
1
Seanfuck 7 小时 39 分钟前
这是啥场景，这种不都是客户端直连 azure 服务吗？
|
 |
3
pengyOne OP @Seanfuck 客户端 wss 链接我的 java 服务， 实时传输音频流，我的服务通过 azure 的 java sppech sdk ，去调用 azure 的实时语音转文本服务
|
 |
4
gfreezy 7 小时 2 分钟前
细节太多，具体的 stt 格式、buffer 大小，连接怎么开启关闭有各种可能。先判断是 java 的问题还是 azure sdk 的问题。多开几个进程试试。
azure sdk 底层都是 c++ 的实现，有参数可以控制打印日志，可以看看日志输出。 |
 |
5
ryd994 6 小时 56 分钟前 via Android
如果不调用 azure API ，仅仅接收然后返回固定文字，还会卡吗？
这个问题的目的是排除 azure API 以外的性能瓶颈 |
|
6
ryd994 6 小时 46 分钟前 via Android
500×244/4=30500
这是假设你每 4 秒钟打开 500 个连接然后关闭，乘以 time wait 时间 240 秒得到的并发端口占用数量。 关闭 TCP 连接后，连接会进入 timewait 状态，继续占用本地随机端口。而 Linux 默认的随机端口范围就是大约 30000 个，和上面的数字接近。 建议你在服务端和测试客户端上都启用 tcp_tw_reuse 。同时增加随口端口范围 net.ipv4.ip_local_port_range 如果确认是测试客户端的随机端口耗尽，那你用多个客户端同时测试也可以避免此问题，那么问题在生产环境中不存在。 当然，最好是能连接复用，但是对于 ws 来说似乎不行。 |
 |
7
hi20151215x 6 小时 0 分钟前 via Android
@ryd994 为什么要 x244?
|
|
8
ryd994 25 分钟前 via Android
@hi20151215x 每个连接在连接表里的寿命是 4 （ 4 秒音频）+ 240 timewait
|
Select Language