项目需要调用外部查询接口,此接口有概率会超时,由于项目处理的请求可能是持续不断的,比如每秒受理10个请求,如果进程受理该请求后,调用外部查询接口又超时了,那么这个进程可能会超时阻塞25秒(curl设置的超时时间是25秒)。此时系统可能就瘫痪了 无法受理请求了 需要等进程闲置才能恢复可访问性
通过在webman社区问答的搜索和学习,我尝试将进程数量设置得很大 4核心的服务器 我设置了100个进程 但是问题并没有消失 反而让我摸不着头脑 因为系统进程阻塞的时候 100个进程里面可能就几个瘫痪了 其他的还是闲置的 但是系统却无法受理新的请求了 甚至我ssh链接的终端也会很卡顿 因为我对linux系统不是很了解 这个问题我只能描述为: 1.webman有足够大量的进程 2.服务器核心数不多(核心数量多要花钱 舍不得) 3.少量几个进程瘫痪后其他进程并没有分担压力(活好像都派给那几个进程了,分摊不均,这个是推测猜想,另top命令查看cpu占用不到20%。) 4.对此现象我推测问题要么是webman进程派遣的请求不均匀或者核心数量少而进程数量多导致的cpu上下文切换消耗极大?
5.请教一下大佬,不想过度升级服务器的前提下 如何提高webman IO密集型请求的并发数量
升级workerman到v5 配合workerman/http-client 协程用法处理外部http请求
文档 https://www.workerman.net/doc/workerman/components/workerman-http-client.html#%E5%8D%8F%E7%A8%8B%E7%94%A8%E6%B3%95
老大 我有点不理解 我现在的项目是webman框架 您的意思是让我把这块业务独立出来 用workerman框架吗
还是说 可以直接在webman里面用这个协程http-client?
webman里面用这个协程http-client
是在当前线程开携程处理curl请求吗,爱了 windows环境可以测试吗
curl不行,要
workerman/http-client
配合workerman/workerman v5
revolt/event-loop
直接用http-client 请求即可是吗 好的好的
老大我还是有点不明白
worker进程是阻塞的 分配到worker的请求也需要同步返回结果 那么用了这个协程的http-client 就不会阻塞该进程了吗
我实在没搞懂 有大佬能解答一下吗
worker进程本身是非阻塞的,但是开发者的业务代码可能有阻塞调用,比如pdo,curl等,导致进程阻塞。
workerman/http-client 是非阻塞的库,只调用它不会阻塞进程。
老大请问这个http-client 默认示例里面的配置
Connection: keep-alive 是开启的
我想问一下 这个有必要开启吗
开启性能好
老大 协程用法提升太大了 之前cpu占用很低 程序却卡死了
现在测试超大并发 很快就处理完了 并发时cpu占用率也很高 说明协程的cpu利用率非常高
但是我遇到了一个新的问题
简单说我的业务流程
客户端->worker->查询三方接口->返回给客户端
当有大量客户端请求时,我的项目就会卡住 现在引入协程查询外部接口 已经解决了这个问题
但是请求结果有点乱套 比如客户端a、b、c请求的结果应该是 A B C
但是协程情况下 客户端a获得的结果可能是 B
或者 客户端a 对应的协程有获取到结果A 但是却分配给B了 自己在webman的控制器流程里面结果却是空
我修改了好几遍 希望把问题描述清楚 但是好像还是有点绕 老大帮忙看看吧
你要发一个能证明结果错乱的demo,并附上测试方法和结果
好的老大 我糊涂了
这协程我真不知道咋调试了 推测可能的原因是每次都会调用一个静态类
之前一个请求对应一个进程对应一个静态类对象
现在多个请求对应一个进程对应多个静态类对象
而静态类 多个对象其实是和类挂钩的 所以一个变了 别的对象都跟着变了 这个是现在的推测 我还在研究
你在这研究不如直接提交一个复现的例子给作者,他比你写得更快,好几十倍。
直接贴出你写的代码吧,你这么说根本不知道你在描述什么。说实在点,跟没说没啥区别。
问题已经解决了 是我的代码问题 就是我上面说的 我的webman控制器调用了一个静态类 http请求结果赋予给静态类的某个静态属性了 改成非静态类 实例化后 就行了
另外我看论坛好多说协程没啥用的 我只能说 就我遇到的问题 服务器配置翻倍都没啥效果 进程开100多个也没效果
现在老大出的这个协程请求太nb了 针对io堵塞 或者 请求超时 的情况 改善的不是一点点
之前压测系统直接卡死 现在压测 不仅处理完成的时间少了一半 而且管理后台一点不卡 worker也不busy
感谢webman 感谢老大 我头也不疼了
比吃药还管用
好像也没人说协程没啥用吧...
目前还没实际用到
guzzle 行不行?
牛
如果业务需要,必须在pdo事务中请求第三方接口(请求失败回滚/成功提交),这种情况下使用携程用法处理HTTP请求,最终还是导致阻塞的吧?不知道有没有优化的方向呢。
回滚这里可以交给消息队列异步处理,但是发起请求这里,你是要等待结果的,只能阻塞吧
感觉实在无法分离的阻塞业务,这里业务如果实在接受不鸟阻塞,干脆丢给fpm处理
现在的业务类似webmanAI助手这个应用。用户使用服务需要调ChatGpt接口并且扣除余额(PDO事务),不知道怎么分离比较合适。
如果你做推送的话,可以把整个事务丢给队列(这里就已经类似fpm了),队列进程开多点,这是一个通用解决方案
而且,队列的服务本来也可以单独部署
队列这种用法感觉像是Java的线程池,从Java的角度来说不建议自发自取,我之前也是这样处理但是人家觉得不太行
因为他的场景是必须等待结果的,异步队列稍微好点吧
等请求三方接口回来在进行事务 处理散