付费求一个 go 项目程序优化方案，给系统提高并发

[LemonLeon]

这是一个开源的 chatgpt 接口转发系统，使用 Go 程序编写。

https://github.com/songquanpeng/one-api

在实际使用过程中，高并发已经达到极限，但是系统的资源利用率非常低。我需要一个工程师协助我，找出并发限制的瓶颈，加以优化。

背景参考：
centos 4h8g oneapi
实测并发量 2000 rpm 附近

提升系统性能可以有效增加并发量，另一个系统 6h8g 并发量可以达到 5000 rpm 。
但是高并发的时候，cpu 资源利用率并不高，不清楚限制的因素到底是什么。

-
大家的时间都很宝贵，我会为此付费。评论区留下你的联系方式

也欢迎各位佬在评论区提提建议！！

[Immortal]

有没有可能是 gpt 到达限制了
试试其他平台的接口然后测下并发?

[ETiV]

？？？
你直接问 GPT 不就好了

[LemonLeon]

@ETiV 不行，gpt 做不了这个任务

[LemonLeon]

@Immortal 不会是 GPT 限制，后台官方接口的数量成倍增加，并发量没有变化。

目前可以确定是服务器资源的问题，更准确说是 oneapi 程序没有很好的利用系统资源

[dxb848295325]

我有兴趣，微信 18628069445

[kidlj]

瓶颈八成在 IO ，特别是网络 IO 。

[deorth]

加服务器

[idblife]

关注一下，这个项目不错

[tonywangcn]

感兴趣 wx dG9ueXdhbmdpbw==

[gongquanlin]

之前研究了下这个项目源码，到处都是 case xxxx ，维护起来真 tm 费劲。
能开源确实很值得鼓励，单纯的是我认为里面的设计很难接受，正在开发替代品

[lzgshsj]

作者就在 v2

[fengxsong]

```
if err != nil {
fatalLog(...)
}
return err
```

😄

[kuaner]

直接联系作者给出个 Pro 版本

[RockChinQ]

估计是 上游渠道较慢 导致的利用率低，这几天 OpenAI 确实经常 429 。建议你，后端搭建多个 oneapi 实例 分别接入不同的 OpenAI 账号，最好是分布在不同的服务器上，前端再用一个 oneapi 来做负载均衡。

[voidmnwzp]

用单个 g 重新封装 epoll 试试

[luguhu]

既然明确资源利用率非常低, 那不如直接起多个进程做负载均衡. 简单快捷

[lifei6671]

你是怎么确定并发已经达到了极限的？

[cosiner]

cpu, mem 都没满，正常应该是可以支撑更多请求的，不会是带宽不够吧

[monsterxx03]

确定上游没到极限的话，大概率是锁竞争过多导致 cpu 利用率上不去。
给个思路，runtime.SetMutexProfileFraction(5) 打开 mutex profiling
然后看 pprof 的 mutex 火焰图，看瓶颈在哪。

简单看了下代码 https://github.com/songquanpeng/one-api/blob/01f7b0186fae589e0e5fb83ab0e6d033ba5339aa/controller/relay-text.go#L376 比如这个地方直接用了一个全局的 httpClient, 里面是从连接池里取连接时候是有锁的，之前碰到过这个问题，优化办法是根据 cpu 核心数实例化多个 client, 每次随机挑一个发请求。

另外 http.Client 的 MaxIdleConnsPerHost 默认值是 2 ，conn 会被频繁回收，试试设置成几百。

[1423]

看起来程序员确实是太多了