每个 HTTP 请求是否有一个 Rack 应用程序实例？
我正在构建一个名为 Lovers 的 Facebook 应用程序，使用 Heroku 上的 Sinatra 应用。它在Heroku 的bamboo-mri-1.9.2 堆栈 上运行 Ruby 1.9.2。
这是一个模块化 Sinatra 应用< /a>，以及 恋人源代码，我为 Sinatra 应用程序 (Lovers::Application) 的每个实例提供一个 Facebook::Application 实例：
require 'sinatra/base'
class Lovers::Application < Sinatra::Base
attr_reader :facebook
def initialize(app=nil)
@facebook = Facebook::Application.new(
Lovers::Conf.fb_app_id,
Lovers::Conf.fb_app_secret,
Lovers::Conf.fb_canvas_name)
super(app)
end
# ...
end
这样，您就可以执行 Lovers.application.facebook 从 Lovers 模块内的任何位置访问 Facebook::Application 实例，比如从 Lovers::用户。
这是否有意义，或者我应该让 Lovers::Application 的所有实例（如果有多个）共享同一个 Facebook::Application 实例，即， Lovers.facebook。这就是我们为 Redis 所做的事情：Lovers.redis，这对我来说很有意义。我想我倾向于将其更改为后者，但我想在更改之前确定一下。你怎么认为？
最后，每个 HTTP 请求是否有一个 Lovers::Application 实例？
更新：
我阅读了 Heroku Dynos。显然，每个 dyno（进程）都运行一个 Lovers::Application 实例。因此，在阅读了在之间共享全局变量之后进程，我认为这意味着如果我在 Lovers::Application 类中定义一个类变量 @@hit_count ，它将具有不同的值，具体取决于哪个dyno 收到请求，假设我每次请求主页时都会增加 @@hit_count ，即：
@@hit_count = 0
get "/" do
@@hit_count += 1
end
I'm building a Facebook app called Lovers, using a Sinatra app on Heroku. It's running on Ruby 1.9.2 on Heroku's bamboo-mri-1.9.2 stack.
It's a modular Sinatra app, and in the Lovers source code, I'm giving each instance of the Sinatra app (Lovers::Application) an instance of Facebook::Application:
require 'sinatra/base'
class Lovers::Application < Sinatra::Base
attr_reader :facebook
def initialize(app=nil)
@facebook = Facebook::Application.new(
Lovers::Conf.fb_app_id,
Lovers::Conf.fb_app_secret,
Lovers::Conf.fb_canvas_name)
super(app)
end
# ...
end
That way, you can do Lovers.application.facebook to access the Facebook::Application instance from anywhere within the Lovers module, say from Lovers::User.
Does this make sense, or should I just have all instances of Lovers::Application (if there's ever more than one) share the same Facebook::Application instance, i.e., Lovers.facebook. That's what we're doing for Redis: Lovers.redis, which makes sense to me. I guess I'm leaning toward changing it to the latter, but I want to make sure before I change it. What do you think?
Finally, is there one instance of Lovers::Application per HTTP request?
UPDATE:
I read up on Heroku Dynos. Apparently, each dyno (process) runs an instance of Lovers::Application. So, after reading about sharing a global variable among processes, I think that means that if I define a class variable @@hit_count in the Lovers::Application class, it will have different values depending on which dyno receives the request, assuming I increment @@hit_count every time the home page is requested, i.e.:
@@hit_count = 0
get "/" do
@@hit_count += 1
end
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
“最后，每个 HTTP 请求是否有一个 Lovers::Application 实例？”
每个进程/dyno 有一个实例。
“它会根据哪个dyno接收请求而具有不同的值，假设我每次请求主页时都会增加@@hit_count”
是的，如果您需要全局状态，则必须将状态保留在进程/dyno之外。有许多不同的方法可以做到这一点，您选择哪种方法将取决于您的应用程序的详细信息和流量水平。如果您没有获得大量流量，您可以执行一些简单的操作，例如将其保存在数据库中。您可以在 postgres 或 mysql 中对 hit_count 等进行原子增量。但是，如果流量很大，这种方法可能会成为瓶颈。
"Finally, is there one instance of Lovers::Application per HTTP request?"
There's one instance per process/dyno.
"it will have different values depending on which dyno receives the request, assuming I increment @@hit_count every time the home page is requested"
yes, if you need global state you have to keep the state outside of your process/dyno. There are many different ways to do this, and which you choose will depend on the details of your app and your traffic levels. If you don't get a lot of traffic you can do something as simple as keeping it in your database. You can do atomic increments in postgres or mysql for something like hit_count. However, this approach may become a bottleneck if you have a lot of traffic.