假设我有一个在S服务器上运行的Web应用程序,每个服务器平均有C个核心.我的应用程序正在处理任何时刻的R请求的平均值.假设R大约是S*C的10倍,那么由于每个核心已经处理了大约10个请求,因此将多个核心的请求工作分散的优势不会很小吗？
如果我是对的,为什么这个人说并发对于Python作为Web开发语言的未来如此重要？
我可以看到为什么我的论点不正确的原因很多.也许应用程序会收到一些非常难以处理的请求,这些请求的数量超过可用内核.或者,请求的难度可能存在很大差异,因此一个核心可能不幸并且连续发出10个困难请求,结果是其中一些核心需要的时间比合理的长.鉴于撰写上述文章的人比我更有经验,我认为这是一个很大的机会我错了,但我想知道为什么.
在您设计的假设情况下,每个核心有大约10个"正在运行"的请求,只要明智地处理请求到核心的分配(甚至可能是最简单的循环负载平衡),如果每个请求都可以.要求在其整个生命周期内生活在一个核心上.
的一点是,该方案中只是一种可能性- 沉重的请求,可以真正受益(以较低的延迟方面)从编组每个请求多个内核肯定的另一种可能性.我怀疑在今天的网络上你的场景更加普遍,但是它确实很好处理这两种类型,并且"批处理"后台处理也是如此....特别是因为核心数量(而不是每个核心的速度)这些日子里,正在增长的是什么,以及将会持续增长的是什么.
我不得不反对Jacob Kaplan-Moss的智慧,但我习惯于在我的雇主那里以比他似乎提倡的更好,更明确和更透明的方式获得相当好的并发性 - mapreduce用于类似批处理的工作,基于分布式哈希的分片,用于注册N个后端以分割1个查询的工作,等等.
也许我只是没有足够的实际经验(比如)Erlang,Scala或者Haskell相对较新的软件事务内存,看看它们在低QPS上如何通过数千个内核的数十个或几千个核的高利用率来扩展,每Q工作量高的工作量...但在我看来,这种情况的灵丹妙药(扣除相对有限的情况子集,你可以转向mapreduce,pregel,分片等)还没有用任何语言发明的.使用明确的,精心设计的架构,至少在我的工作经验中,Python在处理此类场景时肯定不比Java,C#或C++差.
京公网安备 11010802040832号 | 京ICP备19059560号-6 