c++ - 如何在最短时间内做超大量的HTTP请求

Question

所以我们有一个非常庞大的数据库，其中包含大约 300,000 个 url。这些 url 必须被 ping 并从中获取数据。(这些 url 是正在播放歌曲的广播电台。数据是元数据)

其中一些有时不活跃，有时活跃。在任何给定时间，大约有 80,000 人处于事件状态。有的 react 慢，有的 react 快。我有一台服务器，我正在考虑使用 C++ 来做到这一点我的目标是在 1 分钟内 ping 和解析(或抓取)它们并不断重复该过程，因为信息(播放的歌曲)会随着时间而改变。大多数时间为 2-7 分钟。但我不确定这是否可能。我应该采取什么方法来做到这一点？我想过创建两个程序，一个用于测试 url 是否处于事件状态并每天运行两次。以及通常需要多长时间才能做出回应。是平时 react 慢还是现在 react 慢。

另一个进行实际的爬行，其中最快的将首先被爬行和一些响应更快的 url 的专用线程。

拜托，我会喜欢更多更好的想法或更好的解决方案。任何人都可以告诉我如何进行数学运算以找出我应该分配给每个专用线程的数量，以便在最少的时间内获得结果

Answer 1

你不需要你的 CPU 性能(现在不是你的瓶颈)，但你需要避免网络层停顿......如果请求超时是 60 秒，并且你有 16 个线程，并且非常命中 16慢速服务器(最终会超时)，你通常会停顿 60 秒并且不会再处理任何东西。

所以我会从假设 500 个线程开始(比如 15-30 秒的超时，如果你知道非常慢的 radio 甚至能够适应这种情况的话)，并保留一些关于它们周转的统计数据，并继续动态添加更多工作线程对于每个在 2-3 秒内没有得到响应的原件。 80000/500 = 160，所以每个“通常很快”的工作线程必须 ping 大约 160 个 url，如果每个都需要 2 秒，那仍然是 320 = 5 分钟!所以 500 听起来是最少的。

就是说，拥有 500 个以上的线程会给 CPU 和内存带来一定的负担(不确定有多少，通过良好的线程/内存模型实现，对于具有 GB RAM 的现代 x86 CPU 来说，500 听起来并不多，即使 5000 听起来仍然合理)，但我会更担心网络层和周围可能存在的防火墙，你需要像网络这样的服务器级网络来处理如此多的请求(如果我想在家里尝试类似的东西，我自己的路由器会用默认设置，将其检测为某种 DoS 攻击)。

所以得到一些统计请求平均需要多长时间，然后用你的目标时间(2-7 分钟)，然后将 url 的数量除以这些，比如平均 ping 5 秒，回合时间 3 分钟 = 300,000/(3*60/5) = 至少需要 8333.33 个线程。然后，您将必须分析您的应用程序以验证，如果有 8000 个线程，它不会因其他原因而阻塞，但它确实会按预期处理任务。

(另一种选择是从单线程触发异步 http 请求，但这种方式会以任何方式为每个任务创建自己的线程，所以我宁愿自己管理线程，并使用同步 http 调用)

并考虑动态增长机制……您可以保留一些计数器，了解上一秒添加了多少新请求，以及完成了多少请求(响应或失败)，并且在运行几秒钟后这些应该开始形成某种“吞吐量”统计数据，然后如果吞吐量低于所需阈值，您可以添加更多线程。

关于事件/不活动...将响应时间/最后一次查看/最后一次检查与 url 保持在一起，并添加一些进一步的逻辑以仅在有意义时检查 url(比如不在接下来的 60 秒内，如果它只是响应，或在上次测试 6 小时后检查不活动)。您还需要避免同时在两个不同的线程中检查相同的 url，因此一些中央管理器代码应该为线程提供目标(也许是一些 FIFO 线程安全队列......实际上你可以使用它的大小来估计工作线程正在处理它，因此当您看到队列没有足够快地清空时，您可以添加更多线程 = 避免将统计代码添加到线程本身)。