workman进程处理问题
环境workman协议http://127.0.0.1:8081，Nginx代理跳转到8081，tp5+workman，开8进程，业务对外curl请求银行项目，超时3秒；同一时间并发300+请求，都未超时，想请教一下此时wookman的8进程是否只能并发处理8个请求，后面的是否都需要排队？4核4线程CPU怎么发挥？和Nginx+php+fastcgi比起来处理速度怎么样，fastcgi可以动态生成work是不是会好一点？
3706 3 1
3个回答
相似问题
年代过于久远，无法发表回答
月贡献榜
赞助商
热门问答
workerman 里面的redis 队列是基于redis的什么特性实现的？
联表一次查询和查询后循环内再查询别的表组装数据，哪个性能好呢？
PHP8.4下webman直接用topthink/think-orm想了解数据库连接该写在哪里
webman想使用人大金仓数据库，如何处理？ 求方案
微信SDK，关于webman里推荐的
redis-queue 延迟任务 可否延迟第二天触发？
127.0.0.1:1238地址显示已被占用?
请问下现阶段是否有必要使用异步mysql查询？
请教：webman如何让错误直接在网页显示，而不是在命令行打印出来？
webman不错，但不建议官方做webman-admin
如果workerman里业务用curl，8个进程只能并发处理8个请求，也就是一个进程处理完一个请求后，才会处理下一个，后面的请求排队。
如果curl改成workerman/http-client，8个进程可以并发处理更多的请求，每个请求不用排队，workerman会并发处理。
如果业务是调用curl的话，性能瓶颈在curl，理论上
nginx+workerman比Nginx+php+fastcgi稍好一些，但是效果差别不大。如果workerman使用workerman/http-client则并发要比Nginx+php+fastcgi好很多。业务中有阻塞，请求就会等待。采用异步mysql，是否可以解决或缓解请求排队？
mysql的话直接用同步阻塞就可以了，因为mysql连接数是瓶颈，mysql默认连接数一般是100，虽然可以调高，但是调高后mysql连接数过大直接影响mysql性能。一个请求假设发起3个异步mysql请求，就占用了3个mysql连接，300并发请求可能直接占用900mysql连接，即使你用了mysql连接池，假设连接池上限100个mysql连接(已经很多了)，300并发打过来还是要排队，所以mysql异步解决不了多大问题。使用异步+mysql连接池和多开一些进程+mysql单例+阻塞访问mysql效果其实差不多，但是明显mysql单例阻塞式访问代码更简单，更稳定。
非常感谢。websocket协议下processes设为1时onmessage中收到用户并发请求也是同理（同时只能处理一个请求）？
谢谢细致的回答。理解了：多开进程，处理时间久的部分异步掉（粗暴的理解）
项目同时用到了，http和websocket，笨拙的写了个共用处理逻辑的框架。
有一点不清楚，就是websocket协议下processes设为1时onmessage中收到用户并发请求也是同理（同时只能处理一个请求）？
大佬，你是怎么 做的web服务给tp5的，我现在不知道怎么搞定伪静态
看情况，onmessage里是同步阻塞代码就是并发处理一个请求。如果onmessage里是异步非阻塞就是并发处理多个请求。但是从更微观上来讲，同一个cpu某一时刻只能运行处理一个请求。所以从这一点来讲不管你是同步阻塞还是异步非阻塞，还是协程，同时只能处理一个请求。
谢谢细致的回答