👩🏼‍🤝‍👩🏻 👨🏿‍🏭 👨🏿‍✈️ रेल की सूक्ष्मता 4

रेल 4.0 में, config.threadsafe विकल्प डिफ़ॉल्ट रूप से सक्षम हो जाएगा! और इस पाठ में आप सीखेंगे कि आखिर यह क्या करता है, यह उत्पादन को कैसे प्रभावित करता है और इसे आम तौर पर थ्रेड्स के साथ कैसे व्यवहार करना चाहिए।

रेल 4 सूक्ष्मता चक्र की सामग्री

कैश पचता है
Turbolinks
धागा सुरक्षा

आरोन पैटरसन (टेंडरलोवे) ने कुछ समय पहले एक ब्लॉग पोस्ट किया था। इसमें, उन्होंने रेल पटरियों में थ्रेड्स विकल्प के बारे में बात की और उल्लेख किया कि सबसे अधिक संभावना है कि रेल 4 रिलीज में डिफ़ॉल्ट रूप से सक्षम होगी। इसलिए, इस कड़ी में मैं इसके बारे में बात करूंगा।

आरंभ करने के लिए, पहले से ही नामक एक साधारण रेल 3 एप्लिकेशन बनाएं:

अंतिम

$ rails new thready $ cd thready

उत्पादन के लिए एप्लिकेशन कॉन्फ़िगरेशन फ़ाइल को खोलना और देखना यह दर्शाता है कि विकल्प पर टिप्पणी की गई है:

/config/environments/production.rb

 # Enable threaded mode # config.threadsafe!

आपको यह समझना चाहिए कि इसके शामिल होने का मतलब बहु-थ्रेडेड अनुप्रयोग में जादुई परिवर्तन नहीं है। फिर, वह क्या कर रही है? थ्रेडसेफ़ का स्रोत कोड देखते समय ! विधि यह देखा जा सकता है कि विकल्पों का सेट स्थापित किया जा रहा है:

 def threadsafe! @preload_frameworks = true @cache_classes = true @dependency_loading = false @allow_concurrency = true self end

पहले 3 विकल्प तथाकथित अधीर अनुप्रयोग लोडिंग के लिए जिम्मेदार हैं। इस प्रकार, जब आवेदन शुरू होता है, तो यह भागों में लोड करने के बजाय, अपनी संपूर्णता में तुरंत लोड हो जाता है, जैसा कि थ्रेडसेफ़ अक्षम होने पर होता है ।

चौथा विकल्प, Rack :: Lock की मध्यवर्ती परत के उपयोग से allow_concurrency कट जाती है। टर्मिनल में डेवलपर मोड में रेक मिडलवेयर कमांड को चलाने पर, आप देख सकते हैं कि रैक :: लॉक उन पहली परतों में से एक है जो गतिविधि को पंजीकृत करती है:

अंतिम

 $ rake middleware use ActionDispatch::Static use Rack::Lock #    .

उत्पादन और चलाने में थ्रेडसेफ़ विकल्प चालू करना:

 $ rake middleware RAILS_ENV=production

यह परत अब दिखाई नहीं देगी। इस सवाल का जवाब देने के लिए "रैक क्या करता है :: लॉक करें", स्रोत कोड पर एक नज़र डालें ( ध्यान दें, परिवर्तन को कम करने के लिए प्रबंधित फ़ाइल ):

/lib/rack/lock.rb

 require 'thread' require 'rack/body_proxy' module Rack class Lock FLAG = 'rack.multithread'.freeze def initialize(app, mutex = Mutex.new) @app, @mutex = app, mutex end def call(env) old, env[FLAG] = env[FLAG], false @mutex.lock response = @app.call(env) response[2] = BodyProxy.new(response[2]) { @mutex.unlock } response rescue Exception @mutex.unlock raise ensure env[FLAG] = old end end end

जब अगला अनुरोध कॉल विधि में आता है, तो उसके अंदर म्यूटेक्स ऑब्जेक्ट पर एक लॉक लगाया जाता है और उसके बाद ही अनुरोध को संसाधित किया जाता है, जिसके बाद ब्लॉक को हटा दिया जाता है। यह दृष्टिकोण सुनिश्चित करता है कि किसी भी समय केवल एक अनुरोध पर कार्रवाई की जाएगी। प्रक्रिया की बेहतर समझ के लिए, मैं इसे स्पष्ट रूप से दिखाऊंगा। ऐसा करने के लिए, एक विधि के साथ एक नया नियंत्रक बनाएं:

अंतिम

 $ rails g controller foo bar

बनाई गई विधि में, वर्तमान धागा एक सेकंड के लिए सो जाएगा, जिसके बाद कुछ रहस्यमय पाठ प्रदर्शित किया जाएगा:

/app/controllers/foo_controller.rb

 class FooController < ApplicationController def bar sleep 1 render text: "foobar\n" end end

अब सर्वर को डेवलपमेंट मोड में शुरू करें। ध्यान दें कि WEBrick का उपयोग किया जाता है (डिफ़ॉल्ट रूप से यह बस है)। अब, कंसोल के एक अलग टैब में, हम कर्ल का उपयोग करके साइट के लिए एक अनुरोध करेंगे:

अंतिम

 $ curl http://localhost:3000/foo/bar foobar

उम्मीद के मुताबिक संदेश आने से पहले दूसरी देरी हो गई। अब हम एक साथ 5 समानांतर अनुरोध करेंगे। ऐसा करने के लिए, अतुल्यकालिक अनुरोध करने के लिए & प्रतीक का उपयोग करें:

 % repeat 5 (curl http://localhost:3000/foo/bar &) % foobar foobar foobar foobar foobar

यहां, निश्चित रूप से, यह दिखाई नहीं देता है, लेकिन ये 5 उत्तर बारी-बारी से आए, एक के बाद एक, कुल 5 सेकंड लगे। यह उपरोक्त अनुक्रमिक अनुरोध प्रसंस्करण के कारण है। अब उत्पादन मोड में सर्वर शुरू करें और फिर से इसके समानांतर 5 अनुरोध करें:

अंतिम

 % rails s -e production % repeat 5 (curl http://localhost:3000/foo/bar &)

सर्वर से सभी 5 प्रतिक्रियाएं एक साथ आएंगी, सक्षम थ्रेडसेफ़ के लिए धन्यवाद !, विकल्प, जिसके कारण रैक :: लॉक परत का अब उपयोग नहीं किया जाता है। तो अब अनुरोधों को अतुल्यकालिक रूप से संसाधित किया जाता है, चीयर्स!

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

आप देख सकते हैं कि यूनिकॉर्न कैसे व्यवहार करेंगे। ऐसा करने के लिए, आपको निम्न पंक्ति को अनसुना करना होगा:

/ जेमफाइल

 # Use unicorn as the app server gem 'unicorn'

फिर बंडल इंस्टॉल चलाएं। अब, यूनिकॉर्न कमांड का उपयोग करके, आप उत्पादन मोड में रेल एप्लिकेशन के लिए सर्वर शुरू कर सकते हैं:

अंतिम

 $ unicorn -E production -p 3000

फिर से कर्ल शुरू करके, आप देखेंगे कि कोई मल्टीथ्रेडिंग नहीं है। यह है कि यूनिकॉर्न एक कार्यकर्ता के साथ कैसे काम करता है। गेंडा को अतिरिक्त म्यूटेक्स और रैक :: लॉक परत की आवश्यकता नहीं होती है। यह इस कारण से है कि थ्रेडसेफ़ विकल्प ! उत्पादन में डिफ़ॉल्ट रूप से सक्षम किया जाएगा: प्रसंस्करण अनुरोधों और प्रवाह के लिए तर्क उत्पादन में पर्यावरण पर छोड़ दिया जाता है। लेकिन यह मत भूलो कि इस विकल्प के समावेश में अधीर, संपूर्ण एप्लिकेशन को डाउनलोड करने के लिए मजबूर करना भी शामिल है, जिससे कुछ दुष्प्रभाव हो सकते हैं। इसलिए उत्पादन पर जाने से पहले अपने एप्लिकेशन को परीक्षण सर्वर पर अच्छी तरह से जांचना न भूलें!

एक और छोटा नोट: थ्रेडसेफ़ विकल्प ! अपने काम के तर्क को बेहतर दिखाने के लिए 4 रेलों की रिहाई में अपना नाम बदल सकते हैं।

इसलिए, हम पहले से ही जानते हैं कि यूनिकॉर्न और पैसेंजर मल्टीथ्रेडिंग का समर्थन नहीं करते हैं, लेकिन अगर आप इसके समर्थन के साथ सर्वर चाहते हैं तो क्या होगा? प्यूमा बचाव के लिए आता है। यह सर्वर मोंगरेल पर आधारित है, जिसके कारण यह कई थ्रेड का उपयोग करके किसी भी रैक एप्लिकेशन को चलाने में सक्षम है। प्यूमा रूबी, रुबिनियस और यहां तक कि एमआरआई का समर्थन करता है। आइए कोशिश करते हैं:

/ जेमफाइल

 # Use unicorn as the app server # gem 'unicorn' gem 'puma'

अब उत्पादन मोड में सर्वर चलाएं:

अंतिम

 $ rails s puma -e production

चल रहा कर्ल अब, आप देखेंगे कि सर्वर से प्रतिक्रियाएं लगभग तुरंत आती हैं।

रूबी को ग्लोबल इंटरप्रेटर लॉक नामक इस संस्करण के लिए अंतर्निहित तंत्र के कारण एमआरआई में प्यूमा बहुत अच्छी तरह से काम नहीं करेगा। लेकिन जेबी और रुबिनस के पास बेहतर थ्रेडिंग समर्थन है, इसलिए प्यूमा उनमें बेहतर काम करेगा।

बेशक, मल्टीथ्रेडिंग का उपयोग करते समय, आपको अपने एप्लिकेशन और इसकी सुरक्षा में कोड की सावधानीपूर्वक निगरानी करने की आवश्यकता है। यहाँ असुरक्षित कोड का एक छोटा सा उदाहरण दिया गया है:

/app/controllers/foo_controller.rb

 class FooController < ApplicationController @@counter = 0 def bar counter = @@counter sleep 1 counter += 1 @@counter = counter render text: "#{@@counter}\n" end end

नियंत्रक में एक वर्ग चर होता है जिसे @@ काउंटर कहा जाता है, प्रत्येक बार बार विधि कहा जाता है। विधि में ही, हम वर्ग चर के मान को बचाते हैं, एक सेकंड के लिए सोते हैं, फिर मान लौटाते हैं और इसे स्क्रीन पर प्रदर्शित करते हैं। आइए देखें कि एकल-थ्रेडेड वातावरण में सब कुछ कैसे काम करेगा:

अंतिम

 $ rails s

4 बार कर्ल चलाएं, जिसके बाद 4 अंक दिखाई देंगे, प्रत्येक दूसरे विलंब के साथ:

अंतिम

 % repeat 4 (curl http://localhost:3000/foo/bar &) % 1 2 3 4

अब सर्वर बंद करें और प्यूमा को उत्पादन मोड में चलाएं:

अंतिम

 $ rails s puma -e production

उसका निष्कर्ष अलग होगा:

अंतिम

 % repeat 4 (curl http://localhost:3000/foo/bar &) % 1 1 1 1

अब अनुरोधों को एक साथ, कई थ्रेड्स में संसाधित किया जाता है। इस प्रकार, अंतिम अनुरोध पूरा होने से पहले ही अपना काम पूरा करने में कामयाब हो गया। इसलिए, डेटा के साथ काम करते समय आपको बहुत सावधान रहना चाहिए (@@ काउंटर, उदाहरण के लिए), जिसमें कई थ्रेड्स तक पहुंच होती है। समस्या को हल करने के लिए, आपको एक प्रकार की म्यूटेक्स का उपयोग करना चाहिए:

/app/controllers/foo_controller.rb

 class FooController < ApplicationController @@counter = 0 @@mutex = Mutex.new def bar @@mutex.synchronize do counter = @@counter sleep 1 counter += 1 @@counter = counter end render text: "#{@@counter}" end end

फ़्रेम कोड mutex'om थ्रेड-सुरक्षित हो जाता है। उसके बाद, आपको एप्लिकेशन सर्वर को पुनरारंभ करने और फिर से कर्ल का उपयोग करने की आवश्यकता है। काउंटर अब सही ढंग से काम करता है, क्योंकि कोड थ्रेड को क्रमिक रूप से एक के बाद एक संसाधित करता है।

क्लास और ऑब्जेक्ट चर, वैश्विक चर और स्थिरांक जैसी चीजें म्यूटेक्स के अंदर उपयोग की जानी चाहिए। दुभाषिया से चेतावनी के बावजूद, रूबल में स्थिरांक को बदला जा सकता है। हालांकि लाइनों की तरह। स्ट्रिंग्स के मामले में, उन्हें बदलने पर रोक लगाने के लिए फ्रीज विधि का उपयोग करें। और यह मत भूलो, कृपया, कि वर्ग के अंदर कोड को साझा की गई मेमोरी है, इसलिए आपको एप्लिकेशन लोड करने के बाद गतिशील रूप से कक्षा में ही विधियाँ सम्मिलित करने की आवश्यकता नहीं है।

सौभाग्य से, आपके एप्लिकेशन को थ्रेड-सेफ़ में कनवर्ट करना उतना मुश्किल नहीं है जितना कि यह पहले लग सकता है। एक नियम के रूप में, आपको बार-बार बदलती जानकारी साझा करने की संभावना नहीं है। और यदि आपको ऐसा करना है, तो ऐसा करने के लिए जाने-माने तरीकों पर ध्यान देना बेहतर है। यह संभावना है कि अधिक सुरुचिपूर्ण तरीके मौजूद हैं।

शायद, एक मुश्किल काम यह सुनिश्चित करना होगा कि आपके आवेदन में उपयोग किए गए सभी रत्न थ्रेड-सुरक्षित हैं। उपयोग किए गए पुस्तकालयों से README पढ़ें, अगर वहां कोई आवश्यक जानकारी नहीं है, तो शायद आपको ट्रैकर में एक टिकट बनाना चाहिए।

एक अन्य समस्या है जो एक मल्टीथ्रेडेड एप्लिकेशन में सामना की जा सकती है और यह डेटाबेस कनेक्शन पूल के साथ जुड़ा हुआ है। यह पूल डेटाबेस से एक साथ कनेक्शन की संख्या निर्धारित करता है और डिफ़ॉल्ट रूप से 5 के बराबर है। प्रदर्शन के लिए, मैंने म्यूटेक्स टिप्पणी की।

/app/controllers/foo_controller.rb

 def bar #@@mutex.synchronize do counter = @@counter sleep 1 counter += 1 @@counter = counter #end render text: "#{@@counter}\n" end

अब आवेदन करने के लिए 12 एक साथ अनुरोध करने की कोशिश करने के बाद, यह स्पष्ट हो जाएगा कि कनेक्शनों की सीमित संख्या के कारण उनमें से केवल 4 ही पास हुए हैं। इस तथ्य के बावजूद कि इस पद्धति में कोई DB अनुरोध नहीं किया गया है, रेल अभी भी प्रत्येक अनुरोध के लिए कनेक्शन सुरक्षित रखता है। और अगर अनुरोध के दौरान पर्याप्त कनेक्शन नहीं होंगे, तो आवेदन तब तक इंतजार करेगा जब तक कि वह अपना स्वयं का प्राप्त न कर ले। इस प्रकार, यदि अनुरोध में देरी हो रही है, तो टाइमआउट त्रुटियां डालना शुरू हो जाएगा और डेटाबेस पूल से उपलब्ध कनेक्शन की कमी के कारण अन्य अनुरोध भी गिर जाएंगे।

पूल में मूल्य को 15 तक बढ़ाकर, आप पिछले कर्ल अनुरोध को दोहरा सकते हैं और सभी अनुरोध सफल होंगे।

आपका ध्यान के लिए धन्यवाद!

लेखक से प्रकाशित करने की अनुमति दी गई थी (क्योंकि यह एक पेड स्क्रेंस्ट का अनुवाद है)। कृपया पीएम में सभी अशुद्धियों और त्रुटियों की रिपोर्ट करें।

आवेदन

मेरे ब्लॉग को सब्सक्राइब करें !

रेल की सूक्ष्मता 4 - थ्रेड-सुरक्षा

More articles: