search

cch123 / blog_comment

comments of xargin.com
8 stars 0 forks source link

fasthttp 快在哪里 #150

Open cch123 opened 4 years ago

cch123 commented 4 years ago

https://xargin.com/why-fasthttp-is-fast-and-the-cost-of-it/

pengpaige commented 4 years ago

这么多年过去了，基本的 workerpool 的模型还是没什么变化。最早大概是在 handling 1 million requests with go 提到，fasthttp 中的也只是稍有区别。

请问上面提到的参考文章里的 WorkerPool 实现方式和「直接使用一个 channel 然后多个订阅者从这个 chanel 并发的读取」这种方式的区别在哪里？

cch123 commented 4 years ago

@pengpaige ，他这种写法，负责任务分发的是一个协程，其它协程只关注自己的 job channel 就行，应该能一定程度上降低大家一起在同一个 channel 上抢锁的消耗

不过这也就一说，实际抢锁会不会有太多影响可以实测一下

pengpaige commented 4 years ago

@cch123 @pengpaige ，他这种写法，负责任务分发的是一个协程，其它协程只关注自己的 job channel 就行，应该能一定程度上降低大家一起在同一个 channel 上抢锁的消耗

不过这也就一说，实际抢锁会不会有太多影响可以实测一下

感谢回复！ 可不可以直白的理解成让可能的阻塞分散在更多的 job channel 中，最终降低总体被阻塞的可能？那这样隐含的前提是 cpu 线程够多？

cch123 commented 4 years ago

@pengpaige ，嗯，是的

争抢概率高的锁和不怎么争的锁两者的成本差挺多的，不怎么抢的锁一个 atomic 指令就完事了，要是都抢锁就得进 slow path，去排队啊，gopark 什么的