你好，首先非常感谢你开发的新版 RSS 轮询管理界面，这真的带来了很大的改变！
我们的网站有几十个 RSS 源。我注意到在 Sidekiq 中，某些源的某些任务可能需要二十分钟甚至更长时间，这很容易导致队列堵塞。
虽然有一个 RSS polling feed request timeout（RSS 轮询源请求超时）的设置，但这并不是问题所在。RSS 源本身可以很快获取到，加载速度也很快（至少在我用浏览器同时尝试访问同一个源时，Sidekiq 却还在为此挣扎）。问题似乎在于，某些 RSS 源包含了播客的所有剧集（而不仅仅是最近 10-15 集），并且 Discourse 似乎会处理所有这些条目，即使这些剧集已经下载过且没有任何变化。基本上，由于这些没有变化、没有新剧集的 RSS 源，Sidekiq 很容易就会忙碌半小时甚至更久。
理想情况下，Discourse 应该能迅速检测到没有变化，然后继续执行后续操作。
可选地，可以提供一个设置，将读取限制在源的前 NN 个条目。
或者，至少可以设置一个时间限制，如果轮询在 NN 分钟（5 分钟，或最多 10 分钟）内未能完成，则强制结束。
我想知道，当一个源的处理时间超过 10 分钟且 Sidekiq 100% 繁忙时，具体会发生什么。究竟是什么操作会耗时这么久，并且处理起来如此繁重。
你认为这是当前插件中可以改进的地方吗？
2 个赞
我很乐意帮忙改进，你能分享一下你的订阅源（feed）的 URL 吗？这样我可以在本地更好地进行测试。（如果你想保持私密，欢迎私信我）
2 个赞
非常感谢 @zogstrip 的快速回复！这些 RSS 源是公开的，实际上我们推荐任何喜欢独立收听西班牙语播客和广播节目的人使用。 
我们在此处维护了一份临时禁用的有效 RSS 源列表，以让服务器喘口气：Limpieza de RSS feeds - nº 3 por icaria36 - Sobre Podkasts - Podkasts
其中许多使用 WordPress，我们可以请他们编辑 RSS 中的条目数量。但许多使用的是 iVoox，这至少在西班牙语国家是一个非常流行的平台。他们会在 RSS 中包含节目的所有剧集，这是一家（相对）规模较大的公司，甚至很难找到一个能联系到人的“联系我们”链接。所以我们在那里陷入了困境。对于你的测试，我会先开始添加 iVoox 的源，如果你需要更多，我们可以继续添加。
附注：你可以从一个异常长的源开始：<![CDATA[Es lo que hay - Lliure directe]]>
1 个赞
我有几个正在开发中的 PR，应该能大幅提升轮询/导入大型 feed 的速度
2 个赞
天哪！！！！！
非常感谢！这既快速又精准。
我们很高兴能通过报告这个问题做出一点小小的贡献。虽然我们的情况可能算是个比较特殊的边缘案例（我猜？），但这个解决方案将在一定程度上提升几乎所有使用此插件的 Discourse 实例的性能。
我看到补丁已经合并了。这是否意味着我们现在可以通过更新 Discourse 来获取这些更改？
2 个赞
Moin
7
“Merged”（已合并）意味着更改已进入 main 分支。通常，论坛不会跟踪 main 分支，而是跟踪 latest 分支。这意味着合并之后，你仍然需要等待自动测试运行并通过。
当你查看 Commits · discourse/discourse · GitHub 时，可以看到 zogstrip 的提交刚刚完成了这一过程（那里有一个绿色的对勾，而上面的提交仍然显示棕色圆点）。
现在，当你查看 latest 分支时，也能看到这些提交：Commits · discourse/discourse · GitHub
因此，如果你跟踪的是 latest 分支（论坛默认如此），你现在就可以更新以拉取这些提交。
2 个赞
我已经重新启用了 RSS 订阅源，第一轮 RSS 更新基本上已经顺利完成。出现了 86 篇新文章，其中许多来自几天前，这意味着之前有多个订阅源未能完成处理，而现在它们已经完成了。非常好！
非常长的订阅源仍然可能让一个任务占用很长时间，但我只看到 3 个超过 10 分钟。这个在运行 1 小时后仍在进行中……但它确实非常长，所以也许这是合理的？不过，单个订阅源占用一个任务这么长时间本身就有问题。也许这与它是许久以来的第一次完整导入有关？我会在下一轮 RSS 更新时再次检查（我们将其设置为 180 分钟）。
1 个赞
也许那个运行了一个小时的作业卡在了导入之外的某个环节？我刚刚注意到，该源的所有文章似乎都已经导入完毕，包括图片和其他所有内容。至少从用户的角度来看，导入似乎已经完成了。也许这是一个异常情况。我会在再运行几轮 RSS 后再次汇报。
不错 
这些订阅源是“新的”还是之前已经导入过了？我在改进初始导入速度方面没怎么做工作，因为这主要受限于我们创建新主题的速度。
它们都已经导入过了。
好的，为了测试，我们将轮询频率改为了 10 分钟（之后我们会改回 180 分钟，这对我们来说已经足够了）。在 zogstrip 修复之后，大多数 feed 都在一分钟或更短的时间内处理完毕。只有少数几个非常长的 feed 可能会达到 2 分钟甚至更久，但从未（据我所见）超过 5 分钟。这个 RSS feed 是唯一一个稳定达到 4 分钟或更久的，但它极其长，所以我不确定针对这种用例还能做什么。即使是浏览器也需要一段时间才能仅仅将其渲染出来。（而且我们可能会因为无关的原因将其移除。）
整个轮询过程不超过 5-6 分钟，这令人惊叹。这是一个巨大的改进。对我来说，此报告可以解决了。再次非常感谢，@zogstrip。
1 个赞
