क्या मैं हेरोोकू + यूनिकॉर्न में ऐप को प्रीलोड कर रहा हूं?

Question

यूनिकॉर्न ऑन हेरोकू का उपयोग करते समय। स्केलिंग, समस्याएं होंगी, क्योंकि नव स्केल किए गए वेब डिनो को अनुरोध के द्वारा एक्सेस किया जा सकता है जब यह अभी भी ऐप लोड कर रहा है। जो ज्यादातर टाइमआउट त्रुटि में परिणाम देता है।

मैं http://codelevy.com/2010/02/09/getting-started-with-unicorn.html और https://github.com/blog/517-unicorn

दो लेख पर पढ़ने का एक सा preload_app true का उपयोग कर सुझाव दिया था। और after_fork और before_fork ब्लॉक।

रेल 3+ में, before_block में कोड अभी भी आवश्यक है? मैंने कहीं और पढ़ा, अन्यथा। कोई भी जिसने इसे पहले स्थापित करने का अनुभव किया है और साझा करना चाहते हैं?

क्या मुझे कुछ और याद आ रही है? क्या मैं ऐप को सही ढंग से लोड कर रहा हूं?

# config/initializers/unicorn.rb 
# Read from: 
# http://michaelvanrooijen.com/articles/2011/06/01-more-concurrency-on-a-single-heroku-dyno-with-the-new-celadon-cedar-stack/ 
worker_processes 3 # amount of unicorn workers to spin up 
timeout 30   # restarts workers that hang for 90 seconds 

# Noted from http://codelevy.com/2010/02/09/getting-started-with-unicorn.html 
# and https://github.com/blog/517-unicorn 
preload_app true 

after_fork do |server, worker| 
    ActiveRecord::Base.establish_connection 
end 

before_fork do |server, worker| 
    ## 
    # When sent a USR2, Unicorn will suffix its pidfile with .oldbin and 
    # immediately start loading up a new version of itself (loaded with a new 
    # version of our app). When this new Unicorn is completely loaded 
    # it will begin spawning workers. The first worker spawned will check to 
    # see if an .oldbin pidfile exists. If so, this means we've just booted up 
    # a new Unicorn and need to tell the old one that it can now die. To do so 
    # we send it a QUIT. 
    # 
    # Using this method we get 0 downtime deploys. 

    old_pid = Rails.root + '/tmp/pids/unicorn.pid.oldbin' 
    if File.exists?(old_pid) && server.pid != old_pid 
    begin 
     Process.kill("QUIT", File.read(old_pid).to_i) 
    rescue Errno::ENOENT, Errno::ESRCH 
     # someone else did our job for us 
    end 
    end 
end 

Answer 1

जो आप यहां देख रहे हैं, वह अपेक्षा की जाती है। जिस क्षण आप एक डिनो द्वारा स्केल करते हैं, हेरोकू प्लेटफॉर्म उस स्लग को एक नए डिनो पर तैनात करेगा, जो पूरी तरह से आपके अन्य डायनोस (यानी एक और यूनिकॉर्न मास्टर) से अलग है।

एक बार जब डिनो तैनात और चलाया जाता है (प्रभावी ढंग से बूट किया जाता है), रूटिंग जाल उस डिनो को अनुरोध भेजना शुरू कर देगा, जो तब रेल यूनिकॉर्न पर शुरू हो जाएगा, या जो भी सर्वर, आपने सेटअप किया है।

हालांकि, एक बार यह अनुरोध आता है कि आपके डेटा को वापस करने के लिए आपके पास 30 सेकंड विंडो है या अनुरोध रूटिंग जाल (त्रुटि एच 12) पर समाप्त हो जाएगा।

इसलिए, संक्षेप में, आपकी समस्या फोर्किंग के साथ नहीं है, यह है कि आपका एप्लिकेशन 30 सेकंड के भीतर शुरू नहीं हो सकता है, इसलिए शुरुआती टाइमआउट। फोर्किंग और पीआईडी ​​फाइलों के बारे में चिंता करना ऐसा कुछ नहीं है जिसे आपको हेरोकू मंच पर चिंता करने की ज़रूरत है।

Answer 2

केवल एक आंशिक जवाब है, लेकिन मैं इस यूनिकॉर्न विन्यास के साथ इन बुरा स्केलिंग समय समाप्ति को कम करने में सक्षम थे:

worker_processes 3 # amount of unicorn workers to spin up 
timeout 30   # restarts workers that hang for 30 seconds 
preload_app true 

# hack: traps the TERM signal, preventing unicorn from receiving it and performing its quick shutdown. 
# My signal handler then sends QUIT signal back to itself to trigger the unicorn graceful shutdown 
# http://stackoverflow.com/a/9996949/235297 
before_fork do |_server, _worker| 
    Signal.trap 'TERM' do 
    puts 'intercepting TERM and sending myself QUIT instead' 
    Process.kill 'QUIT', Process.pid 
    end 
end 

# Fix PostgreSQL SSL error 
# http://stackoverflow.com/a/8513432/235297 
after_fork do |server, worker| 
    defined?(ActiveRecord::Base) and 
    ActiveRecord::Base.establish_connection 
end 

इसके अलावा, मैं heroku labs:enable preboot का उपयोग करें (https://devcenter.heroku.com/articles/labs-preboot/ देखें)। दुर्भाग्यवश, वेब डायनोस को स्केल करते समय भी मुझे कुछ टाइमआउट दिखाई देता है।

यहाँ HireFire समर्थन मंच में एक चर्चा है, मैं शुरू की: http://hirefireapp.tenderapp.com/discussions/problems/205-scaling-up-and-down-too-quickly-provoking-503s

Answer 3

preload_app true हमारे ऐप्लिकेशन के लिए मदद की, तो यह एक शॉट देने के यदि आप तैनाती/रिबूट के दौरान समय समाप्ति के साथ मुद्दों को देख रहे हैं। टिप्पणियां कह रही हैं कि इससे मुझे यह सोचने में मदद नहीं मिलती है कि यह कोशिश करने लायक नहीं था, फिर एहसास हुआ कि वास्तव में यह आवश्यक फिक्स था।

हमारी स्थिति preboot का उपयोग कर धीमी-बूट बूट रेल ऐप थी। कुछ तैनाती और पुनरारंभ पर, हमें बहुत समय लगता है, इस बिंदु पर कि साइट को हमारी अपटाइम निगरानी द्वारा माना जाता था।

हमें एहसास हुआ कि preload_app false के साथ, यूनिकॉर्न पहले अपने पोर्ट को बांध देगा और फिर ऐप लोड करेगा। जैसे ही यह बंदरगाह बांधता है, हेरोोकू इसे यातायात भेजना शुरू करता है। लेकिन फिर इस धीमी ऐप को लोड करने के लिए बहुत समय लगता है, ताकि ट्रैफिक टाइमआउट हो।

यूनिकॉर्न शुरू करने के बाद साइट पर पहुंचने की कोशिश कर रहा है, और यह जांच कर रहा है कि आपको "उस पोर्ट पर कोई सर्वर नहीं है" टाइप त्रुटि (वांछनीय) या बहुत धीमा अनुरोध (नहीं) वांछित)।

जब हम preload_app true सेट करते हैं, तो यूनिकॉर्न बंदरगाह को बांधने तक इसमें अधिक समय लगेगा, लेकिन एक बार ऐसा होता है और हेरोोक इसे यातायात भेजता है, तो यह जवाब देने के लिए तैयार है।