如何在代码层面 提升项目的性能以及并发？

1. 如果是想要防止接口挂掉，就做限流
2. 如果要提升接口的 qps 的话，就提高接口性能，从接口整条链路去做优化

你这样说的就很大了 比如可以 msql 可以有些数据变成 es 查询 同步处理的东西用 mq 处理变成异步 fpm 框架更换 swoole hyperf 换成协程框架 mysql 更换读写分离 多住多从，如果可以改为微服务再次提高 不过 php 微服务太少

查询类的接口可以单独用 webman 做，数据还可以从缓存中取

如果一定在代码层面提高性能，我想到的是降低时间，空间复杂度。比如我曾经把一个功能的时间复杂度从 O(N^M) 搞到了 O(N*M)。

代码层面的优化，个人倾向于在易读、易理解、易拓展上做文章。

老项目改造我做得不少，看回复你们旧项目用的是 CI，这东西应该很旧了。 但大体的 php 老应用优化思路应该接近。 如果想从代码层提高性能，可以尝试：

1. 引入 composer，减少代码量。这一步很简单同时收益很大。注意在 composer.json 中声明好你们的 php 版本等环境信息，防止引入一些太新版本的 lib。
2. 删除重复代码。具体可以使用 phpcpd 或者 phpstorm inspect 来检查，前期先删除重复代码，可以大量减少后续的优化工作。
3. 搞清楚哪里慢。CI 项目我不太了解要怎么处理，如果框架内没 Hooks / 事件订阅这种机制，应该要自己去魔改框架。可以尝试在框架、控制器、服务相关地方补充下打 log 逻辑，我建议用 symfony/stopwatch。
4. 知道哪里慢就好搞了。如果对于系统内一些地方不满意，可以适当在这里对部分进行重构。一般，php 应用慢大概率都是数据库查询相关的问题。。。

对于旧项目，除非十分十分有把握（你是老板并且不缺钱、老板亏钱你能哄等等），要不千万别整个重构。旧项目的重构风险必然大于收益的，技术人员不应该自己去决定这种技术成本的决策工作。 最后，任何 swoole 系的项目，都不可能保证你顺利将 fpm 引用迁移到 swoole/swow 生态。workerman/webman 稍微好点，但一样没有 fpm 稳定。别搞。