Ruby 守护进程和频率
我写了这个 ruby 守护进程，想知道是否有人可以看一下它，并告诉我我所采取的方法是否正确。
#!/usr/bin/env ruby
require 'logger'
# You might want to change this
ENV["RAILS_ENV"] ||= "production"
require File.dirname(__FILE__) + "/../../config/environment"
$running = true
Signal.trap("TERM") do
$running = false
end
service = Post.new('http://feed.com/feeds')
logger = Logger.new('reader.log')
while($running) do
# Log my calls
logger.info "Run at #{Time.now}"
service.update_from_feed_continuously
# only run it every 5 minutes or so
sleep 300
end
我觉得最后一个循环不太正确，并且可能会占用大量内存，但我不确定。另外，这 5 分钟似乎永远不会恰好每 5 分钟发生一次，我会看到 4-6 分钟的变化。
提前致谢
I've written this ruby daemon, and was wondering if somebody could have a look at it, and tell me if the approach I've taken is correct.
#!/usr/bin/env ruby
require 'logger'
# You might want to change this
ENV["RAILS_ENV"] ||= "production"
require File.dirname(__FILE__) + "/../../config/environment"
$running = true
Signal.trap("TERM") do
$running = false
end
service = Post.new('http://feed.com/feeds')
logger = Logger.new('reader.log')
while($running) do
# Log my calls
logger.info "Run at #{Time.now}"
service.update_from_feed_continuously
# only run it every 5 minutes or so
sleep 300
end
I feel like this last loop is not quite the right thing to do, and can be memory intensive, but I'm not sure. Also, the 5 minutes seem to never happen exactly every 5 minutes, and I'll see variations of 4-6 minutes.
thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
大约一年前有一篇非常有趣的文章：
Ruby 守护进程：验证良好行为
There was a quite interesting article about a year ago:
Ruby Daemons: Verifying Good Behavior
时间差异可能来自于
service.update_from_feed_continuously所花费的时间。这是一项重要的计算还是依赖于 Web 服务的计算（它们增加的延迟可能会使许多客户端计算相形见绌）。但不确定其余部分的结构，抱歉！
The time discrepancy could come from how long
service.update_from_feed_continuouslytakes. Is this a non-trivial computation or one that relies on a web service (their added delays could dwarf many client-side computations).Not sure about the structure of the rest though, sorry!