因为要处理 耗时的接口 一个接口请求大概要3秒 是第三方接口 不占用服务器资源 打算开200个线程 处理 实在不行只能换swoole 协程
这么耗时的任务怎么不用异步任务的方式
webman现在可以用协程了
这种第三方耗时的请求用协程
协程保存上下文需要使用内存,本质上还是用内存换效率,消费能力也是生产=消费,如果任务累积到一定程度,那么内存占用还是很高,下游的消费速度还是很重要的;建议使用队列,消费者数量>生产者数量保证消费能力,队列设置容量上限,以免生产>消费将资源耗尽。
你换协程也是等待,等待的时间会更长,swoole的协程没记错的话是单线程协程,也就是如果这个协程上被分配了100个3秒的请求,99个还是在等而已;webman开的进程数也是接收的数据在等罢了,超出了当前进程设置的buffer以后才会拒绝,每超出buffer的话,请求是在排队。
同上,建议走队列,假如一个请求要3秒,这3秒算是硬性资源,不会因为你用了协程它就变成了只要1秒
协程是好东西,但不是解决一切问题的良药
遇到跟楼主同样的问题,比如某个服务需要请求第三方的结果并立即返回给前端,假设这种情况下,同时200用户请求,这个时候webman应该没解了吧?还是说开个200进程?队列不能立即返回,这种方案暂不考虑。
如果是其他语言,解决的方案也是开线程,线程达到上限了也是阻塞等待; 这种情况在做大数据相关的项目的时候比较多见,一个计算任务少则几百毫秒,多则上分钟,通常来说有以下几种解决方案:
如果本身就要阻塞等待结果,那么最好的方式就是排队,进程数开大一点,http buffer设置高一些,但实际上不能根本解决这个问题。
加机器解决,就是ch兄上面说的,消费者大于生产者一个道理,无非是这次的消费者是更多的机器
这么耗时的任务怎么不用异步任务的方式
webman现在可以用协程了
这种第三方耗时的请求用协程
协程保存上下文需要使用内存,本质上还是用内存换效率,消费能力也是生产=消费,如果任务累积到一定程度,那么内存占用还是很高,下游的消费速度还是很重要的;建议使用队列,消费者数量>生产者数量保证消费能力,队列设置容量上限,以免生产>消费将资源耗尽。
你换协程也是等待,等待的时间会更长,swoole的协程没记错的话是单线程协程,也就是如果这个协程上被分配了100个3秒的请求,99个还是在等而已;webman开的进程数也是接收的数据在等罢了,超出了当前进程设置的buffer以后才会拒绝,每超出buffer的话,请求是在排队。
同上,建议走队列,假如一个请求要3秒,这3秒算是硬性资源,不会因为你用了协程它就变成了只要1秒
协程是好东西,但不是解决一切问题的良药
遇到跟楼主同样的问题,比如某个服务需要请求第三方的结果并立即返回给前端,假设这种情况下,同时200用户请求,这个时候webman应该没解了吧?还是说开个200进程?队列不能立即返回,这种方案暂不考虑。
如果是其他语言,解决的方案也是开线程,线程达到上限了也是阻塞等待;
这种情况在做大数据相关的项目的时候比较多见,一个计算任务少则几百毫秒,多则上分钟,通常来说有以下几种解决方案:
如果本身就要阻塞等待结果,那么最好的方式就是排队,进程数开大一点,http buffer设置高一些,但实际上不能根本解决这个问题。
加机器解决,就是ch兄上面说的,消费者大于生产者一个道理,无非是这次的消费者是更多的机器