ssig33.com

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

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

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

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

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

1. 購読フィード一覧の取得が大変に重い

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

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

対処

2. OPML の読み込みが重い

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

対処

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

まとめ

この世は地獄だ

back to index of texts


Site Search

Update History of this content