怎么找到适合本身业务并发量所需服务器配置流程步骤详解
管理员 发布于 4年前 500
怎么找到适合本身业务并发量所需服务器配置流程步骤详解
刚刚我在laravel社区看到这么一问，我觉的很有意义，所以记录一下
问题：求助 1000 并发量所需服务器配置？
求助点：
1. 具体服务器几核几 G
2. 接口域名并发设置大小
3. 数据库连接设置大小
我的处理：
1 台主服务器 8 核 16g 8m 带宽
1 从服务器 2 和 2g 2m 带宽 （按量付费）
主从服务器环境:
php7.2,(swoole 扩展，opcache 扩展，redis 扩展)
mysql5.6,
nginx1.16.1
框架 laravel5.5 (因为 6.0 很多插件不成熟)，缓存采用 redis，访问量大的表都做了索引处理。图片存储 oss，js,css 存储 oss
主从都采用 swoole 加速，
主从 swoole 配置
SWOOLE_HTTP_HOST=127.0.0.1
SWOOLE_MAX_REQUEST=1
SWOOLE_HTTP_WEBSOCKET=false
SWOOLE_HTTP_REACTOR_NUM=16
SWOOLE_HTTP_WORKER_NUM=100
SWOOLE_HTTP_TASK_WORKER_NUM=100
SWOOLE_MAX_REQUEST=3000
我的结果：单页面接口请求返回最大数据 150kb，能稳定运行 600-800 并发；
600 并发用户访问流畅（小于 3 秒），800 并发用户访问缓慢（平均 8 秒）
最佳答案：
千万不要被网上的言论带歪了，辟谣：
单纯凭经验断定一个 PHP-FPM workers 进程占用多少内存是没用的，单个 worker 进程的最高内存占用至少是「在 max_requests 内，内存占用最高的那次 request 所申请的内存」。
启动大量的 PHP-FPM workers 进程并不能提升高并发的承载能力，反而会导致大量 CPU 上下文切换，尤其是如果你的业务偏向于计算、单次请求所消耗的时间很长，增加 PHP-FPM 进程数量反而会导致平均请求处理时长飙升。
Swoole / 容器 / Kubernetes 之类的东西并不是银弹，你需要深入学习才能了解它（们）适不适合你的场景和需求。如果你没有投入大量精力改造的准备，我不建议你考虑这些方案。并且，使用所谓的「容器」的确能够将单个容器的 CPU 和内存压到很低，但容器还是要运行在实际的物理机器上的，这对提升并发量并没有什么帮助，反而将一部分计算资源划分给了容器调度进程。
我的建议是：
在新业务上线前，要得出你需要多大机器，你需要：(QPS*ART)/NOW=1。
QPS = Queries per Second. 每秒请求数量，也就是所谓的「并发量」。
ART = Average Response Time. 平均响应时间，单位秒。
NOW = Number of Workers. PHP-FPM Worker 的数量。
根据单位推算，这个公式可以写为 (N/s*s)/N = 1，因此成立。
假设 QPS = 1000，ART = 0.1s，那么 NOW 为 100 才能够在理想状态下，刚好满足你的业务需求（也就是所有请求都可以在不排队的情况下完成处理）。
那么为了推算 NOW，你就需要知道 ART。你可以在一台 1 核心 CPU 的机器上跑一下你的业务，PHP-FPM max_children 保持为 1 即可。随后用压测工具跑单并发，即可计算大概的平均响应时间。务必单线程，否则没有参考价值。
得到 NOW，也就是所需的 Worker 数量之后，你就可以开始推算需要多大机器了。
一般来说，Worker 进程不建议超过 CPU 核心数的 2～4 倍。因此你可以使用 NOW / 2 甚至 NOW / 4 得到你所需要的 CPU 核心数。
至于内存，你同样可以在一台内存足够的机器上跑一跑你的业务，max_children 调大些，通过 systemctl 之类的工具观察 FPM Worker 进程的内存占用，得出一个大概内存占用量的大概数值，随后将平均内存占用量 * NOW 即可。
最后，在生产环境中，建议你：
先按照推算数量向上提高一个档位，部署一台机器。
随后通过 htop 等工具观察实际的 CPU 和内存使用率，尤其是 Load Average 的值。
如果比较稳定或者偏低，可以再降低一个档位部署一台机器（先不要销毁老机器）。
随后在业务低峰将 DNS 记录指向新机器，注意 DNS 记录的 TTL 不要太高。
观察新机器的 Load Average，如果偏高或者雪崩可以立即将 DNS Record 回滚到老机器，恭喜你找到了适合你的机型。如果仍然偏低，可以继续循环第 3 - 5 步，最终实践出最适合你的 Instance Type。
请勿发布不友善或者负能量的内容。与人为善，比聪明更重要！
该博客于2020-12-7日，后端基于go语言的beego框架开发
前端页面使用Bootstrap可视化布局系统自动生成
是我仿的原来我的TP5框架写的博客，比较粗糙，底下是入口
侯体宗的博客
文章标签
- test 三种扣减库存方案 Hyperf2.1启动报错端口占用 上外网神器Ghelper 上外网神器集装箱 laravel中HMVC模式 Hyperf框架验证器 Hyperf自定义函数编写 Hyperf对象转成数组 PHP2021面试题集 centos7系统上挂载 Hyperf框架 秒杀系统的设计 Laravel Octane PHP数组底层实现原理 php7垃圾回收机制 Laravel中类型转换 mysql事务特征及隔离级别 Linux-awk命令 mysql编码 JWT源码实现 Laravel内核分析 Laravel中的用法 centos7+go环境+beego框架 go+beego框架开发博客 go+beego开发博客首页 go+beego自定义公共函数 beego注册_登录_查询 beego控制器创建 Beego框架安装 go语言环境安装 laravel+Elasticsearc laravel运行原理 windows7搭建Vuejs环境 Laravel分块 laravel去重(distinct() laravel集合 laravel+mysql读写分离 laravel5+复杂原生sql laravel+MissMyCat/al lnmp sessio laravel自定义数组分页 laravel中.env配置 laravel8队列发邮件 码云仓库常用操作 laravel8配置163SMTP laravel8配置全局函数 laravel/jetstream之认证 laravel/jetstream
友情链接
