我在Heroku Stack上运行Rails应用程序（包括Memcached，DJ Asynchronous worker，MongoDB持久存储）。
现在我们使用Twitter Oauth作为我们网站上唯一的身份验证选项。 （我们计划最终分支到FB connect，OpenID和/或Email /密码。）
您可能知道，Ruby / Rails应用程序不支持开箱即用的并发性。在Heroku上，你可以启动额外的应用程序实例（dynos），这会增加你的并发性（并发能力= dynos数量），但是每个实例需要36美元/月。通常，这不是问题，因为站点上的平均请求小于100毫秒。
除了Twitter OAuth之外。与Twitter相关的OAuth请求平均需要大约3,500毫秒。
所以基本上，当任何人登录整个应用程序实例时，持续3-4秒。
有没有可行的方法来缓解这种情况？将这些行动放在异步DJ工作者身上会不会很奇怪？它可能会使登录速度变慢，但至少如果一群人一次登录和/或Twitter真的很慢，这些流程不会影响其他应用程序/其他Web请求吗？
还有其他想法吗？
答案 0 :(得分：2)
我想说这个建议现在已经被取代了。我建议您使用OmniAuth，如果您需要普通的身份验证，也可以使用Devise。
OmniAuth建议使用Rack应用程序，您基本上可以让所有“大型”OAuth提供商一举成名。
有两个OmniAuth特定的RailsCasts可以引导您完全满足需要：OmniAuth Part 1和OmniAuth Part 2
答案 1 :(得分：1)
你可以将oAuth推入机架中间件应用程序 - 然后至少只有一个机架应用程序被假脱机而不是整个rails堆栈。这应该会更快一点（虽然它仍然会占用一个实例）。
话虽如此，没有理由不能将身份验证放入自己的应用程序中，特别是如果它们都在同一个域中（因此任何身份验证cookie仍然是域的本地身份）。虽然你必须非常小心安全问题 - 例如中间人攻击等等。如果有人已经完成了你的工作/错误修正，那就更好了。）
如果您使用rubyCAS，您甚至可以在独立的应用域上拥有身份验证应用：http://rubyglasses.blogspot.com/2009/12/rails-single-sign-on-with-rubycas.html