项目使用的是 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 条附言 · 1 天前
本质上，我的项目就是售卖 azure 实时 stt 的。。。客户通过 wss 链接我的服务，然后服务端通过 azure 的 sppech sdk 调用 stt ， 最后返回识别的文本。
上面的问题，就是在压测的时候碰到的。 高并发下，体验效果直接骤降
上面的问题，就是在压测的时候碰到的。 高并发下，体验效果直接骤降
 |
1
Seanfuck 1 天前
这是啥场景，这种不都是客户端直连 azure 服务吗？
|
 |
3
pengyOne OP @Seanfuck 客户端 wss 链接我的 java 服务， 实时传输音频流，我的服务通过 azure 的 java sppech sdk ，去调用 azure 的实时语音转文本服务
|
 |
4
gfreezy 1 天前
细节太多，具体的 stt 格式、buffer 大小，连接怎么开启关闭有各种可能。先判断是 java 的问题还是 azure sdk 的问题。多开几个进程试试。
azure sdk 底层都是 c++ 的实现，有参数可以控制打印日志，可以看看日志输出。 |
 |
5
ryd994 1 天前 via Android
如果不调用 azure API ，仅仅接收然后返回固定文字，还会卡吗？
这个问题的目的是排除 azure API 以外的性能瓶颈 |
|
6
ryd994 1 天前 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 1 天前 via Android
@ryd994 为什么要 x244?
|
|
8
ryd994 22 小时 10 分钟前 via Android
@hi20151215x 每个连接在连接表里的寿命是 4 （ 4 秒音频）+ 240 timewait
|
 |
9
WashFreshFresh 11 小时 33 分钟前
之前做过类似语音识别，当时的优化方案是服务启动后只和语音识别服务器(也就是你的 stt)建立一次链接(每个线程复用一个 client)，期间就保活，因为每次识别调用都重新建立链接的话太慢了，也很占资源。不过这种的前提是所有语音都是一个语种。
|
|
10
pengyOne OP @gfreezy 服务端接收 opus ，转 pcm 传输到 azure ，buffer 是 38k 。。。各种测试基本都排除了 java 方面的问题，高并发下 azure speech sdk 的识别器建立延时会拉长从几 ms ，拉到了几十几百甚至上千的 ms 。。。
@ryd994 去掉 azure api 的调用后，其它逻辑 500 并发测试的结果是正常的。 并发测试的时候还没到 30000 级别， 只是 10 轮的 500 ，即 5000 个 今天改了下 key 的轮询策略，不再十多个 key 轮询， 而是每个服务放两个 key ，测试了一遍。。。三台 8 核 32g 部署服务，，对中文 500 并发耗时相对能接受，但切换成小语种泰语越南语，就最多 300 个并发。超了就会耗时剧增 |
|
11
pengyOne OP @WashFreshFresh 识别器复用太麻烦了，高并发下也不太现实。。。我这个还是实时语音，需要时间戳
|
|
12
gfreezy 1 小时 22 分钟前 via iPhone
出口带宽够吗
|
Select Language