想问下目前大佬们用的laravel主要用了哪些优化方式？

最有效的解决方案就是, 从 PHP- FPM 模式 转变到 PHP-Cli 模式.

社区已经有相关项目在从事这方面, 你可以本地写一个demo 试试:
分享创造：无需修改任何代码和扩展将你的Laravel项目性能提高20倍

还有一个方法, 就是整体提升服务器配置, 缺点是费钱.

octane+swoole

如果你的请求量不低，可以考虑使用 redis 扩展的连接池。

然后PDO，使用持久链接。

PHP 有个 preload。你可以看看

要考虑风险哈。

swoole

没啥业务逻辑也要几百毫秒 就不正常 除非服务器离得远

具体问题具体分析，建议楼主先跟剧业务量和响应时长进行统计来确定接口优化的优先级，然后才是找到具体的瓶颈。再看看该瓶颈在项目中是否具有普遍性（出现次数）和严重程度，根据以上两点进行优先级排序，查找优化方案。

很忌讳的就是从框架层面寻求优化方案，也许都用了也无法解决具体问题。

用go重写

linux + opcache + artisan cache + artisan optimize

linux + opcache最为主要,基本接口都在 30ms 内处理完成。

其他的小优化只能降低 0.5 - 1ms,也无所谓。

吐槽楼上的: 除非官方放弃fpm,只做 cli,不然 cli 就是歪门邪道。

生态都是fpm的,用cli小心走火入魔,换语言才是正道。。

谁都听过每个语言都有自己特点吧,现在并没有完美的语言。

php 的特点开发快,用cli,没发现这个特点在消失?

Optimize Octane

生产环境有用 Octane 走的 Roadrunner 引擎，代替 php-fpm 解决了请求这块的瓶颈，剩下就都是数据库的瓶颈了

fpm调优，传统FPM模式优化只有如此了，如不改动现有代码、可以考虑接入Mysql连接池，当然通过swoole、workman之类的扩展加速也可以(没尝试不改动原有系统加速)，，，推荐依次重构访问量过高的业务到swoole/webman，，，当然暴力点加机器是没问题的 :joy:

opcache + jit 是王道 如果这个都有瓶颈，说明需要扩服务器了

Octane，切换octane时需要关注下静态变量，还有一些exit，sleep之类的操作。 自己在开发环境多测测就可以，不迈出第一步，永远出不去 此外，你得看看整个服务请求，哪个地方耗时多，如果是框架，就优化框架，业务就优化业务

当然你可以直接换好点的服务器