运行多用户 FreshRSS 实例的一些经验

一般项

常规的优化做做就可以了，另外 PHP 越新越好。

另外由于 FreshRSS 为每个用户创了两张数据库表（一张 article 一张 feed），所以数据库的 opened tables 会比较高，但也不用太关心这个指标，毕竟我们不可能有这么高的并发。

  • 推荐开启 WebSub。
  • 记得订阅 FreshRSS 的 GitHub Release
  • 将 ./p 作为网站根目录，不要把 FreshRSS 的根目录设为网站根目录

FreshRSS 升级

FreshRSS 升级时会把 ./data 复制一份到 ./data.bak ，这本身没啥问题。但是在我们的多用户实例上，./data/cache 轻轻松松就会积累起几万十几万个缓存文件，毕竟订阅源数量非常多。建议在升级前 cd ./data/cache && rm *.spc *.html 清理缓存。以免升级时给 ./data 打备份过久而 PHP 超时。

如果你有备份 crontab，记得排除 ./data/cache 和 ./data.bak。

新用户默认订阅源

./opml.default.xml 默认是 FreshRSS 的 GitHub Release。

新用户默认配置

创一个 ./data/config-user.custom.php ，内容如下：

<?php
return array (
        'ttl_default' => 14400, # 最小 4h 自动刷新一次
        'dynamic_opml_ttl_default' => 43200, # dynamic opml 的刷新频率
);

可用参数见 config-user.default.php 。

让用户不能把更新频率改得太高

把 app/views/configure/archiving.phtml 里的几十分钟刷新一次的选项删掉，我是只留下了最快 4h 一次的选项。注意更新 FreshRSS 后要重新删掉。

禁用不活跃用户的自动更新

调整 ./data/config.php 的 max_inactivity 值。

并行刷新订阅源优化

在 1.22.0 后，FreshRSS 给 app/actualize_script.php 加了进程互斥锁。这玩意极大拖慢了刷新一轮订阅源的效率。虽然单个刷新线程会5并发刷新 feed，但还是不够，而且一些 feed 死链，默认 20s 才会 timeout，又拖慢了全局刷新速度。

建议加下这个 patch，让你的 app/actualize_script.php 可以并行运行。

42c42
< $mutexTtl = 900; // seconds (refreshed before each new feed)
---
> $mutexTtl = 10; // seconds (refreshed before each new feed)
49c49,51
<       die();
---
>       // die();
> } else {
>       fclose($handle);
51d52
< fclose($handle);

不用担心并行刷新会导致冲突啥的，因为 feed 级别上也有锁，所以多个进程不会傻乎乎地同时去刷新同一个 feed 。

我是每 3 分钟起 9 个刷新进程，速度飕飕地。

for i in {1..9}; do sudo -u www-data /usr/bin/php /var/www/rss.othing.xyz/app/actualize_script.php & done

另外还可以启用 AutoTTL 插件，根据每个 feed 的实际更新间隔来自适应调整更新频率。不过你需要自己 patch 一下，把它改成系统级插件，而不是用户级插件。

管理插件

FershRSS 的插件手动安装和更新很麻烦。

为了方便，我做了个“FreshRSS 插件包管理器”——yzqzss/freshrss-ext-manager，妈妈再也不用担心我装的 FreshRSS 插件过时了。

备份

不推荐用 FreshRSS 自带的 cli 工具导出 sqlite dump，因为它会重排序 feed_id。另外，FreshRSS 的 Mysql/PostgreSQL 里存的 RSS 文章内容是压缩了的，导出成 sqlite dump 会解压，所以 dump 极大。

总结

经过一波优化下来，估计至少容纳 1k 用户应该没啥问题。

文章目录