ssig33.com

OpenFastladder ホスティングをする上でのダーティーなハック

fl.ssig33.com の運用シリーズ。前回のクローラの記事に書かなかったこと。

OpenFastladder にはいくつか致命的なパフォーマンス上のボトルネックとなるコードがあります。一人で立てて一人で使う分には大抵問題になりませんが、使う人が増えてくると厳しくなってきます。

ですから、それらを潰す方法を紹介します。僕のとった対策はどれもとても最悪な対策で、抜本的な対策を思いついた人は、 fastladder/fastladder に PR を出してもらえると泣いて喜びます。

※この記事はこのリビジョン時の情報です。

ここです。標準でこの API は購読フィードを 100 件ずつ取得していきます。ですからこの箇所のせいで API を一回叩くごとに 100 回 SQL が発行されます。

個人で使う場合はこれくらい問題ないのですが、ホスティングする場合は対策した方がよいです。

api#subs の内容をキャッシュするバッチを作って全ユーザーに大して延々とキャッシュさせ続ける
- ユーザーがアクセスしてきたりして、未読フィードが既読フィードになるタイミングなどでキャッシュは飛しましょう
読み込み件数の設定を大きめにしておく
- subs は最初に 100 件取得したら、その最後の Subscription の id から次のページを取得するので、原理的に 2 ページ目以降のキャッシュは困難です。よってキャッシュできる 1 ページ目をなるべく大きくしておきましょう。キャッシュするのだから大きくても大丈夫。
  - 無論 1 ページ目があまりにも大きすぎるとキャッシュ作成のコストが大きくなりすぎるかもしれませんから、ユーザビリティとそのあたりのコストは随時測定する

OPML の読み込みは、アクションの最中にアップロードされた OPML の分だけフィードが実在しているか探索します。これはお話にならないコードで、個人で使う分でも十分不都合があります。

delayed_job_active_record を使って、 OPML の読み込みを非同期化した。バックグラウンドジョブに回された都合、確認画面を出すことが出来ないので、アップロードされた OPML 内のフィードは問答無用で全部購読するようにした。