大家的原始laravel项目，能支撑多大并发？

两台 4h8G，200+ 并发

买啥服务器，直接上severless，不用关心服务器，自动扩容不香嘛

并发的压力基本都集中在数据库的io。对于laravel，那就缓存+数据库+异步队列的形式去处理。

4g+8g,php-fpm的方式，一台机器200+QPS，应该是没有问题的，我这个是普通10台机器，然后弄了自动扩容

在乎性能 脱离 fpm 模式

php-fpm并发是这么算的，一个子进程处理一个请求，假如你一个接口响应时间是200毫秒，一个子进程一秒可以处理5个请求，假设你是用fpm静态进程的模式，开200个php-fpm子进程的话。那就是5*200=1000个请求每秒。QRS就是1000,但现实中，项目里面每个接口的响应时间都不同，所有要根据实际来评估，监控好慢的接口，和慢接口的请求频率。

理论和实际有很大的差别，包括CPU, 内存占用，服务器的负载。

抗并发就拆，mysql ，redis ，这些先拆出去，在研究代码和框架，

我测试也是在 250+ 左右，全部做缓存的情况下，不让数据库承压

不用在意这些，我都已经明确的截图发出来了，10台WEB，可以支持3600QPS，还是先业务达到这个QPS再想别的吧。估计90%以上的项目是达不到这个QPS的

一问就是高并发，张口就是微服务，上了线后看一看，用户只有3个一个是老板2个是测试

都在扯并发的问题，啥事并发？上面评论 @农夫山泉 这位大哥说的很清楚了，先不谈语言特性，不管啥语言，最终的落地都在mysql上，也就是数据库决定了并发的上限，任何语言，开发方式都是一样的，难道java，go开发就不用redis吗？也就是说在同一套环境下，php和其他语言区别不大，唯一有区别的也就只有异步操作了，但对于web项目来说，很多逻辑都是线性的，也就是说上一步写数据库没执行完，下一步就没法操作，这种业务逻辑，换任何语言都是白搭，因为都得等待前面的执行结果，js的sync await懂吧，不管你执行的多快，都得await上一个结果，所以对于一个项目评定什么语言合适，唯一参考项就是项目中线性逻辑多与不多，多的话无所谓啥语言，啥语言都能上，这时就可以考虑开发效率与后期的拓展性了，论开发效率php当之无愧，些许性能差距对于抢占市场来说不值一提，毕竟活着才能有后面的kpi。随着发展，Java因为有了Spring的出现，开发效率也是大大的提升，而后期拓展性也比php强太多了，导致php目前在Java面前的优势不再，最重要的经济原因，很多创业公司倒闭，造成了如今的局面，但能说现在的php不行吗？不行的只是国内环境，据我所知，php在国外依然是比较热门的，所以不行只是经济而已，当前局面下，讨论语言孰强孰弱已然没有任何意义，对公司来说，抢占市场很重要，对个人来说，找到工作最为重要，回到楼主提问，laravel项目能支撑多少并发？首先，laravel是一个经过全球开发者验证的框架，性能或许不会是顶尖，但也绝对不是一个初创公司能够诟病的，如果是新项目，最好是快速落地看看能不能打开市场，而不是在这考虑性能问题，有这时间，项目都搭建好了，在写注册登录逻辑了

承压最大的是数据库，特别是磁盘io性能。并发响应go确实更快，但瓶颈不在这。云服务器的磁盘性能都很差，最好数据库用专用的。

这种属于什么级别？