4

Heroku スタック (Memcached、DJ 非同期ワーカー、MongoDB 永続ストレージを完備) で Rails アプリを実行しています。

現在、当サイトでは Twitter Oauth を唯一の認証オプションとして使用しています。(最終的には、FB コネクト、OpenID、および/または電子メール/パスワードに拡張する予定です)。

おそらくご存じのとおり、Ruby/Rails アプリはそのままでは同時実行をサポートしていません。Heroku では、追加のアプリ インスタンス (dyno) をスピンアップして、同時実行数 (同時実行能力 = dyno の数) を増やすことができますが、それぞれ 36 ドル/月の費用がかかります。

サイトでの平均リクエストは 100 ミリ秒未満であるため、通常、これは問題ではありません。

Twitter OAuth を除く。Twitter への OAuth 関連のリクエストには、平均で約 3,500 ミリ秒かかります。

基本的に、誰かがログインすると、アプリ インスタンス全体が 3 ～ 4 秒間停止します。

これを軽減する適切な方法はありますか？これらのアクションを非同期 DJ ワーカーに入れるのは変ですか? ログインが少し遅くなる可能性がありますが、少なくとも多数の人が一度にログインしている場合や Twitter が非常に遅い場合、これらのプロセスはアプリの残りの部分や他の Web リクエストに影響しませんか?

他のアイデアはありますか？

4

2 に答える 2

2

このアドバイスは今では取って代わられていると言えます。通常の認証も必要な場合は、代わりに OmniAuth を使用することをお勧めします。

OmniAuth は、示唆されているようにラック アプリであり、基本的に、すべての「大きな」OAuth プロバイダーが一斉に動作します。

必要なものを正確に説明する 2 つの OmniAuth 固有の RailsCasts があります: OmniAuth Part 1とOmniAuth Part 2

于 2010-11-08T17:00:24.300 に答える
1

oAuth をラック ミドルウェア アプリにプッシュすることもできます。その場合、レール スタック全体ではなく、少なくともラック アプリのみがスプールされます。これにより、少し速くなるはずです (それでもインスタンスを占有しますが)。

そうは言っても、特にすべてが同じドメイン内にある場合は、独自のアプリに認証を配置できない理由はありません (したがって、認証 Cookie はドメインに対してローカルのままです)。ただし、セキュリティの問題には本当に注意する必要があります-たとえば、中間者攻撃など。誰かがすでに作業/バグ修正を行っている場合:)

rubyCAS を使用すると、独立したアプリ ドメインに認証アプリを配置することもできます: http://rubyglasses.blogspot.com/2009/12/rails-single-sign-on-with-rubycas.html

于 2010-08-11T08:57:31.700 に答える