项目使用的是 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 条附言 22 小时 52 分钟前
本质上，我的项目就是售卖 azure 实时 stt 的。。。客户通过 wss 链接我的服务，然后服务端通过 azure 的 sppech sdk 调用 stt ， 最后返回识别的文本。
上面的问题，就是在压测的时候碰到的。 高并发下，体验效果直接骤降
上面的问题，就是在压测的时候碰到的。 高并发下，体验效果直接骤降
 | 1 Seanfuck 23 小时 12 分钟前 这是啥场景，这种不都是客户端直连 azure 服务吗？ |
 | 3 pengyOne OP @Seanfuck 客户端 wss 链接我的 java 服务， 实时传输音频流，我的服务通过 azure 的 java sppech sdk ，去调用 azure 的实时语音转文本服务 |
 | 4 gfreezy 22 小时 36 分钟前 细节太多，具体的 stt 格式、buffer 大小，连接怎么开启关闭有各种可能。先判断是 java 的问题还是 azure sdk 的问题。多开几个进程试试。 azure sdk 底层都是 c++ 的实现，有参数可以控制打印日志，可以看看日志输出。 |
 | 5 ryd994 22 小时 30 分钟前 via Android 如果不调用 azure API ，仅仅接收然后返回固定文字，还会卡吗？ 这个问题的目的是排除 azure API 以外的性能瓶颈 |
| 6 ryd994 22 小时 20 分钟前 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 21 小时 34 分钟前 via Android @ryd994 为什么要 x244? |
| 8 ryd994 15 小时 58 分钟前 via Android @hi20151215x 每个连接在连接表里的寿命是 4 （ 4 秒音频）+ 240 timewait |
 | 9 WashFreshFresh 5 小时 21 分钟前 之前做过类似语音识别，当时的优化方案是服务启动后只和语音识别服务器(也就是你的 stt)建立一次链接(每个线程复用一个 client)，期间就保活，因为每次识别调用都重新建立链接的话太慢了，也很占资源。不过这种的前提是所有语音都是一个语种。 |
Select Language