我们正在构建一个严重依赖 RSS Polling 的网站（一个播客社区，每个播客都有自己的类别和自己的 RSS，在新剧集发布到其平台时发布新帖子）。我想知道我们因成功而“死亡”的风险有多大，即引入的 feed 数量超出了 RSS Polling 的处理能力。
具体来说：
一个反复出现但迄今为止无害的错误 可能与拥有多个 feed 有关，这促使我现在提出这些问题，而不是等到为时已晚。 
正如我们所料，随着我们为网站添加更多 feed，这个问题变得越来越重要。
现在，当我们添加一个新的 feed 时，几乎可以肯定第一次导入不会在预期的 10 分钟内完成（根据设置中定义的轮询频率）。
此外，在定义所有 feed 的管理页面中，feed 的排序……可能会发生变化。feed 较少时，它始终是一个静态列表，按添加 feed 的顺序排序。我不知道是什么导致了顺序的变化，也不知道 feed 在较新的排序中遵循什么原则。
我只是想知道这些是否只是一个更大问题的症状，这个问题将导致我们的网站崩溃或使 feed 的轮询/发布不可靠。
我认为这是最相关的问题。如果有人能指出指示轮询的代码片段，也许我可以自己解决。
只是一个更新，我们了解到这个问题与 feed 的数量无关。现在已经解决了。非常好！
也对这里的性能相关问题感兴趣
Sidekiq 提供了一些答案。
今天我注意到页面加载花费的时间有点太长了。过去几天我已经在一些地方注意到一些迟钝，例如 Discourse 链接渲染为页面标题所需的时间。
我检查了 Sidekiq，有 100 多个任务已排队，5 个正在运行。几乎所有这些都是 RSS 轮询提要。我将轮询周期从 10 分钟更改为 1 小时，并删除了任务。
然后我检查了服务器，这是更改之前和之后发生的情况：
我的猜测（仅基于此，我还没有检查代码）是 RSS 轮询会发送提要到队列，数量取决于你有多少。队列将确保有合理数量的同时运行任务。但是……我猜风险在于提要队列会变得非常长，以至于当新的 RSS 轮询启动时，上一个仍在运行，这时情况就会变得糟糕，直到重置，但队列会再次增长，等等。
如果我的分析是错误的，请纠正我。
更新：RSS 轮询正在运行，+60 个提要（在一个仍然是新社区，没有大量活动，甚至在休息时间活动更少的情况下）。
你好，你是否已经了解到可使用的订阅源数量是否有上限？谢谢。
