github-starred/frp
2
0
Fork 0
mirror of https://github.com/fatedier/frp.git synced 2026-05-15 08:05:49 -06:00
Code Issues 40 Projects Packages Wiki Activity Actions 1

[GH-ISSUE #4689] [Feature Request] frp方案求建议 #3705

New issue
Closed
opened 2026-05-05 14:22:27 -06:00 by gitea-mirror · 10 comments
gitea-mirror commented 2026-05-05 14:22:27 -06:00
Owner
Copy link

Originally created by @pkxutao on GitHub (Mar 3, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4689

Describe the feature request

没找到合适的issue母版，见谅
非常感谢frp作者，我们用于生产环境，目前现状如下，现在想做一个10000个客户端的方案，不知道目前这个服务器配置是否能撑得住？有没有压力测试的办法？是否需要升级？（客户端升级成本稍微有点高），目前的版本功能完全能满足要求，就是不知道后续的版本是否在性能方面有所提升（看了所有版本更新信息，没看到这方面的更新），再次感谢作者
服务器现状
8H24G
CPU占用：8.2%
内存占用：16%
带宽占用： 上下行： 55KB/s
frp现状
使用版本：0.31.2 （发布时间：2020/02/04）
客户端数量：2554
连接数：6436
CPU占用：21.3%
内存占用：1.5%（400MB）

Describe alternatives you've considered

No response

Affected area

  • Docs
  • Installation
  • Performance and Scalability
  • Security
  • User Experience
  • Test and Release
  • Developer Infrastructure
  • Client Plugin
  • Server Plugin
  • Extensions
  • Others
Originally created by @pkxutao on GitHub (Mar 3, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4689 ### Describe the feature request 没找到合适的issue母版，见谅 非常感谢frp作者，我们用于生产环境，目前现状如下，现在想做一个10000个客户端的方案，不知道目前这个服务器配置是否能撑得住？有没有压力测试的办法？是否需要升级？（客户端升级成本稍微有点高），目前的版本功能完全能满足要求，就是不知道后续的版本是否在性能方面有所提升（看了所有版本更新信息，没看到这方面的更新），再次感谢作者 服务器现状 8H24G CPU占用：8.2% 内存占用：16% 带宽占用： 上下行： 55KB/s frp现状 使用版本：0.31.2 （发布时间：2020/02/04） 客户端数量：2554 连接数：6436 CPU占用：21.3% 内存占用：1.5%（400MB） ### Describe alternatives you've considered _No response_ ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others
gitea-mirror 2026-05-05 14:22:27 -06:00
gitea-mirror commented 2026-05-05 14:22:31 -06:00
Author
Owner
Copy link

@xqzr commented on GitHub (Mar 4, 2025):

应该更关心操作系统的内核参数

<!-- gh-comment-id:2697993806 --> @xqzr commented on GitHub (Mar 4, 2025): 应该更关心操作系统的内核参数
gitea-mirror commented 2026-05-05 14:22:32 -06:00
Author
Owner
Copy link

@pkxutao commented on GitHub (Mar 5, 2025):

应该更关心操作系统的内核参数

请问具体是哪方面呢？可以详细描述下么

<!-- gh-comment-id:2700203560 --> @pkxutao commented on GitHub (Mar 5, 2025): > 应该更关心操作系统的内核参数 请问具体是哪方面呢？可以详细描述下么
gitea-mirror commented 2026-05-05 14:22:33 -06:00
Author
Owner
Copy link

@xqzr commented on GitHub (Mar 5, 2025):

应该更关心操作系统的内核参数

请问具体是哪方面呢？可以详细描述下么

例如，可能会遇到 too many open files 、 nf_conntrack table full 之类的上限

<!-- gh-comment-id:2700570429 --> @xqzr commented on GitHub (Mar 5, 2025): > > 应该更关心操作系统的内核参数 > > 请问具体是哪方面呢？可以详细描述下么 例如，可能会遇到 `too many open files` 、 `nf_conntrack table full` 之类的上限
gitea-mirror commented 2026-05-05 14:22:34 -06:00
Author
Owner
Copy link

@zhumeichun commented on GitHub (Mar 18, 2025):

我更关心的是，你们是怎么保存这上万个客户端的连接信息的？还是使用自带的这种toml来保存吗？

<!-- gh-comment-id:2732322958 --> @zhumeichun commented on GitHub (Mar 18, 2025): 我更关心的是，你们是怎么保存这上万个客户端的连接信息的？还是使用自带的这种toml来保存吗？
gitea-mirror commented 2026-05-05 14:22:34 -06:00
Author
Owner
Copy link

@pkxutao commented on GitHub (Mar 19, 2025):

我更关心的是，你们是怎么保存这上万个客户端的连接信息的？还是使用自带的这种toml来保存吗？

数据库呗，frp新特性我都没用到，因为现在的版本太旧了

<!-- gh-comment-id:2735726843 --> @pkxutao commented on GitHub (Mar 19, 2025): > 我更关心的是，你们是怎么保存这上万个客户端的连接信息的？还是使用自带的这种toml来保存吗？ 数据库呗，frp新特性我都没用到，因为现在的版本太旧了
gitea-mirror commented 2026-05-05 14:22:35 -06:00
Author
Owner
Copy link

@wuai1024 commented on GitHub (Mar 25, 2025):

我更关心的是，你们是怎么保存这上万个客户端的连接信息的？还是使用自带的这种toml来保存吗？

数据库呗，frp新特性我都没用到，因为现在的版本太旧了

数据库保存了之后如何运行呢，生成 配置文件后，调用 shell 运行吗？ 还有没有更优雅的方法

<!-- gh-comment-id:2750697057 --> @wuai1024 commented on GitHub (Mar 25, 2025): > > 我更关心的是，你们是怎么保存这上万个客户端的连接信息的？还是使用自带的这种toml来保存吗？ > > 数据库呗，frp新特性我都没用到，因为现在的版本太旧了 数据库保存了之后如何运行呢，生成 配置文件后，调用 shell 运行吗？ 还有没有更优雅的方法
gitea-mirror commented 2026-05-05 14:22:36 -06:00
Author
Owner
Copy link

@zhumeichun commented on GitHub (Mar 26, 2025):

我更关心的是，你们是怎么保存这上万个客户端的连接信息的？还是使用自带的这种toml来保存吗？

数据库呗，frp新特性我都没用到，因为现在的版本太旧了

实际上你们基于这个是改过的嘛,把用户信息啥的存储到数据库去了？我们也有这样的需求，但公司没goer，太难受。

<!-- gh-comment-id:2752896595 --> @zhumeichun commented on GitHub (Mar 26, 2025): > > 我更关心的是，你们是怎么保存这上万个客户端的连接信息的？还是使用自带的这种toml来保存吗？ > > 数据库呗，frp新特性我都没用到，因为现在的版本太旧了 实际上你们基于这个是改过的嘛,把用户信息啥的存储到数据库去了？我们也有这样的需求，但公司没goer，太难受。
gitea-mirror commented 2026-05-05 14:22:36 -06:00
Author
Owner
Copy link

@wuai1024 commented on GitHub (Mar 26, 2025):

我更关心的是，你们是怎么保存这上万个客户端的连接信息的？还是使用自带的这种toml来保存吗？

数据库呗，frp新特性我都没用到，因为现在的版本太旧了

实际上你们基于这个是改过的嘛,把用户信息啥的存储到数据库去了？我们也有这样的需求，但公司没goer，太难受。

存数据库这个简单的，frps 有插件，可以鉴权的。

<!-- gh-comment-id:2752944501 --> @wuai1024 commented on GitHub (Mar 26, 2025): > > > 我更关心的是，你们是怎么保存这上万个客户端的连接信息的？还是使用自带的这种toml来保存吗？ > > > > > > 数据库呗，frp新特性我都没用到，因为现在的版本太旧了 > > 实际上你们基于这个是改过的嘛,把用户信息啥的存储到数据库去了？我们也有这样的需求，但公司没goer，太难受。 存数据库这个简单的，frps 有插件，可以鉴权的。
gitea-mirror commented 2026-05-05 14:22:36 -06:00
Author
Owner
Copy link

@pkxutao commented on GitHub (Mar 27, 2025):

我更关心的是，你们是怎么保存这上万个客户端的连接信息的？还是使用自带的这种toml来保存吗？

数据库呗，frp新特性我都没用到，因为现在的版本太旧了

实际上你们基于这个是改过的嘛,把用户信息啥的存储到数据库去了？我们也有这样的需求，但公司没goer，太难受。

监控了frp的日志，把客户端上下线的状态实时同步了到数据库，数据库保存了所有客户端的连接信息，因为客户端前面肯定需要在别的服务认证的嘛，现在准备自己开发个frps插件，用来对客户端做全生命周期的管理，最近看了下插件就是rpc的接口，挺简单的

<!-- gh-comment-id:2756070998 --> @pkxutao commented on GitHub (Mar 27, 2025): > > > 我更关心的是，你们是怎么保存这上万个客户端的连接信息的？还是使用自带的这种toml来保存吗？ > > > > > > 数据库呗，frp新特性我都没用到，因为现在的版本太旧了 > > 实际上你们基于这个是改过的嘛,把用户信息啥的存储到数据库去了？我们也有这样的需求，但公司没goer，太难受。 监控了frp的日志，把客户端上下线的状态实时同步了到数据库，数据库保存了所有客户端的连接信息，因为客户端前面肯定需要在别的服务认证的嘛，现在准备自己开发个frps插件，用来对客户端做全生命周期的管理，最近看了下插件就是rpc的接口，挺简单的
gitea-mirror commented 2026-05-05 14:22:37 -06:00
Author
Owner
Copy link

@github-actions[bot] commented on GitHub (Apr 11, 2025):

Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

<!-- gh-comment-id:2795499978 --> @github-actions[bot] commented on GitHub (Apr 11, 2025): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
dev
new
master
copilot/review-pull-request-5198
v0.68.1
v0.68.0
v0.67.0
v0.66.0
v0.65.0
v0.64.0
v0.63.0
v0.62.1
v0.62.0
v0.61.2
v0.61.1
v0.61.0
v0.60.0
v0.59.0
v0.58.1
v0.58.0
v0.57.0
v0.56.0
v0.55.1
v0.55.0
v0.54.0
v0.53.2
v0.53.1
v0.53.0
v0.52.3
v0.52.2
v0.52.1
v0.52.0
v0.51.3
v0.51.2
v0.51.1
v0.51.0
v0.50.0
v0.49.0
v0.48.0
v0.47.0
v0.46.1
v0.46.0
v0.45.0
v0.44.0
v0.43.0
v0.42.0
v0.41.0
v0.40.0
v0.39.1
v0.39.0
v0.38.0
v0.37.1
v0.37.0
v0.36.2
v0.36.1
v0.36.0
v0.35.1
v0.35.0
v0.34.3
v0.34.2
v0.34.1
v0.34.0
v0.33.0
v0.32.1
v0.32.0
v0.31.2
v0.31.1
v0.31.0
v0.30.0
v0.29.1
v0.29.0
v0.28.2
v0.28.1
v0.28.0
v0.27.1
v0.27.0
v0.26.0
v0.25.3
v0.25.2
v0.25.1
v0.25.0
v0.24.1
v0.24.0
v0.23.3
v0.23.2
v0.23.1
v0.23.0
v0.22.0
v0.21.0
v0.20.0
v0.19.1
v0.19.0
v0.18.0
v0.17.0
v0.16.1
v0.16.0
v0.15.1
v0.15.0
v0.14.1
v0.14.0
v0.13.0
v0.12.0
v0.11.0
v0.10.0
v0.9.3
v0.9.2
v0.9.1
v0.9.0
v0.8.1
v0.8.0
v0.7.0
v0.6.0
v0.5.0
v0.3.0
v0.2.0
v0.1.0
Labels
Clear labels   
In Progress

   
WIP

   
WaitingForInfo

   
bug

   
doc

   
duplicate

   
easy

   
enhancement

   
future

   
help wanted

   
invalid

   
lifecycle/stale

   
need-issue-template

   
need-usage-help

   
no plan

   
proposal

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
todo
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/frp#3705
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?