ibegyourpardon
2018-03-25 18:51:44 +08:00
在这里跑个题，讲性能这件事，虽然也是老生常谈。
有一句话我们可能听的比较多了，也就是绝大多数情况下，我们这些写 CRUD 做点东西的，很难触碰到一个框架本身的性能瓶颈，更多问题出现在类似数据库啊 I/O 这些地方。上面 10# 和 11# 的大佬也提到了这个观点。
这话也没错，大多数情况下确实是这样。
而且很多时候我们提出这样的说法，是因为有人会问出这种性能问题之类，比如楼主这样，在一个项目上手开始之前，先关心起性能问题来了。其实真没必要。
but
在我这一年的一些业务实践里，确实在数据库等通常我们认为先出问题的地方之外，先出现了 Laravel 这个框架的性能问题。
我也没搞错，xhprof 等工具明明白白的告诉着你呢，就是 Laravel 慢。
一段时间内，甚至严重影响到了我这业务的运行。 理由和 #5 楼说的差不多，大量第三方包的引入，写起来是爽了，是快了，跑起来，并发稍微上来点，就卡了。
而且是比数据库还先挂。我们的数据库那个机器那个性能烂的哟……没事，前面高配的机器上跑的 Laravel 还挂的更快。
考虑过 Lumen 这回事，最后还是放弃，没意义。
目前解决方案是在已有的框架能满足业务的基础上，做一些拆分，有点类似微服务的性质，把某些重度业务用原生或者其他框架重写，既不会有非常大的工作量，又能给原先的 Laravel 减负。
但回到楼主的问题里，我仍然坚持那个观点，只管上，没到你操心性能的时候。真的到了操心性能的时候，那是公司业务欣欣向荣你开心都来不及的时候。 像我这边 Laravel 崩到不行的时候，就是赶上了 2017 年底公司最大型的一个活动，流量远远超出我们预期，才变成那样。但给我重来一次，我仍然会在最开始选择 Laravel，写起来简单粗暴，能应付各种多变的需求，部署容易，为啥不用。。
虽然以前说 DB 往往比 Laravel 先挂，现在我这里有个 Laravel 比 DB 先挂的反例，但还没到挂的时候，就先别操那么多心。
真的。踩坑一年的过来人告诉你，放心踩，再来一次，我还会选择 Laravel。