हमें अक्सर Sidekiq को ऑप्टिमाइज़ या मॉनिटर करने के बारे में सवाल मिलते हैं। निगरानी हमारा काम है, लेकिन Sidekiq के प्रदर्शन को अनुकूलित करना एक अलग ही खेल है। वास्तव में, अनुकूलन जटिल है, लेकिन आइए सरल उत्तरों को देखकर शुरू करते हैं...
गति बढ़ाने के दो तरीके
शुरुआत में, गति को दो तरीकों से बढ़ाया जा सकता है — बड़े काम करके (जो अधिक मेमोरी या IO ले सकते हैं या अधिक जटिल हो सकते हैं), या concurrency सेटिंग्स या workers को समायोजित करके (जो अधिक CPU और संभवतः IO का उपयोग करेंगे)। आउच, वास्तविकता पहले ही दस्तक दे रही है: गति की एक कीमत होती है। यदि आप अतिरिक्त मेमोरी, IO या CPU खर्च कर सकते हैं तो यह मुफ़्त है, लेकिन हमें लगता है कि उन ट्रेड-ऑफ को समझना महत्वपूर्ण है जिन्हें करने की आवश्यकता हो सकती है।
Concurrency सेटिंग्स के माध्यम से गति बढ़ाना
Sidekiq अपनी प्रक्रिया में कई थ्रेड्स का उपयोग करके concurrency को संभालता है। इस तरह, यह एक साथ कई नौकरियों को संसाधित कर सकता है, प्रत्येक थ्रेड एक समय में एक नौकरी को संसाधित करता है। डिफ़ॉल्ट रूप से, Sidekiq प्रति प्रक्रिया 10 थ्रेड्स का उपयोग करता है। आप इसे अधिक थ्रेड्स का उपयोग करने के लिए कॉन्फ़िगर कर सकते हैं, इस प्रकार concurrency बढ़ा सकते हैं।
ध्यान दें कि नया concurrency मॉडल आपके ऐप द्वारा समर्थित होना चाहिए। उदाहरण के लिए, इसे डेटाबेस से कनेक्शन के एक बड़े पर्याप्त पूल की आवश्यकता होती है और आपके होस्ट को IO संचालन में वृद्धि को संभालने में सक्षम होना चाहिए। अधिक जानकारी के लिए Sidekiq के concurrency पर दस्तावेज़ देख सकते हैं।
कई Workers चलाकर गति बढ़ाना
कई प्रक्रियाओं को उत्पन्न करने के अलावा, आप कई workers भी चला सकते हैं। इस तरह, आप किसी भी CPU-गहन भागों को स्केल कर सकते हैं, चीजों को समानांतर में चला सकते हैं जब वे अन्यथा CPU पर एक-दूसरे के रास्ते में होते यदि वे एक प्रक्रिया में चलते। हमने पहले Ruby में concurrency और Global Interpreter Lock के बारे में इस लेख में लिखा है यदि आप उस पर पकड़ बनाना चाहते हैं।
क्या यह काम करता है या टूटता है? क्या निगरानी करें और हमारे मैजिक डैशबोर्ड
डिफ़ॉल्ट पैरामीटर्स को बदलने से आपके एप्लिकेशन के प्रदर्शन पर प्रभाव पड़ सकता है। सेटिंग्स बदलने से पहले, यह देखने के लिए निगरानी स्थापित करने की सिफारिश की जाती है कि परिवर्तन सकारात्मक प्रभाव डालते हैं या प्रदर्शन को खराब करते हैं।
आइए जांच करके शुरू करें कि क्या हम होस्ट स्तर पर चीजों को तोड़ रहे हैं। आप देखना चाहेंगे कि आप जिस हार्डवेयर पर चल रहे हैं, उस पर आपका ऐप कितना संसाधन-गहन है। यदि आपके पास मेमोरी और CPU में क्षमता बची है, तो आप चीजों को थोड़ा तेज़ बनाने के लिए concurrency सेटिंग्स बढ़ा सकते हैं।
चाहे आप किसी भी APM (एप्लिकेशन परफॉरमेंस मॉनिटरिंग) का उपयोग करें, उसके पास शायद होस्ट मेट्रिक्स को ट्रैक करने का एक तरीका होगा। यदि आप AppSignal का उपयोग करते हैं, तो आपके होस्ट के लिए डैशबोर्ड स्वचालित रूप से बनाए जाते हैं। यह सुनिश्चित करने के लिए कि चीजें वास्तव में हाथ से निकलने से पहले आपको अलर्ट मिले, आप AppSignal के Anomaly detection का उपयोग करके विशिष्ट होस्ट पर CPU उपयोग के लिए आसानी से अलर्ट सेट कर सकते हैं।
अब, आइए देखें कि Sidekiq स्तर पर चीजें टूट तो नहीं रही हैं। आपका पसंदीदा APM शायद आपको अपने बैकग्राउंड जॉब्स के लिए किसी मैन्युअल तरीके से निगरानी और अलर्टिंग सेटअप करने की अनुमति देगा। AppSignal पर, यह बहुत आसान है: जब आप हमारे जेम का हालिया संस्करण चलाते हैं तो Sidekiq मैजिक डैशबोर्ड (जो आपके अंत से किसी सेटअप के बिना उत्पन्न होता है) में हम इसे आपके लिए ट्रैक करते हैं।
इस सेटअप में, आप प्रति कतार जॉब स्थिति की निगरानी करना चाहेंगे और Slack, PagerDuty, ईमेल या जो भी आप उपयोग करते हैं, उस पर अलर्ट होने के लिए विफलता दर के लिए एक ट्रिगर सेट करेंगे।
कम, बड़े जॉब्स?
हमने CPU का त्याग करके गति बढ़ाने पर एक त्वरित नज़र डाली है। अब, आइए मेमोरी या IO, या अधिक जटिलता का त्याग करके गति बढ़ाने को देखें। आप सोचेंगे कि आप बड़े जॉब्स बनाकर ऐसा कर सकते हैं। विचार यह होगा कि बड़े जॉब्स तेज़ हो सकते हैं क्योंकि उनमें प्रति ऑपरेशन Sidekiq ओवरहेड नहीं होता। हालांकि, हमारे अनुभव में, Sidekiq ओवरहेड शायद ही कभी आपके प्रदर्शन को खत्म करता है। अक्सर, यह डेटाबेस क्वेरीज़ होती हैं जो जॉब करता है जो प्रदर्शन को खत्म कर सकती हैं। हम देखते हैं कि अधिक जॉब्स को मिलाकर, कम क्वेरीज़ करने के लिए है बेहतर प्रदर्शन का एक महत्वपूर्ण तरीका। सरल शब्दों में: 1 रिकॉर्ड के 1000 अपडेट के बजाय 1000 रिकॉर्ड का एक अपडेट करना।
यह देखने के लिए क्या निगरानी करें कि यह काम करता है या टूटता है?
सबसे पहले, आप यहां भी प्रति कतार जॉब स्थिति की निगरानी करना चाहेंगे और विफलता दर के लिए एक ट्रिगर सेट करेंगे। चूंकि जॉब्स अधिक समय लेते हैं और अधिक संचालन करते हैं, आप Sidekiq के मेमोरी उपयोग की निगरानी भी करना चाहेंगे। आपको Sidekiq मेमोरी उपयोग पर एक अलर्ट सेट करना चाहिए, लेकिन विशेष रूप से, AppSignal के Anomaly detection का उपयोग करके मेमोरी खत्म होने वाले होस्ट के लिए।
आपको प्रति कतार कतार की लंबाई की निगरानी भी करनी चाहिए। यह आपको सचेत करेगा जब बैकलॉग बन रहा हो—जब वर्कर्स के पास कतार में उससे अधिक हो जितना वे संसाधित कर सकते हैं। हम आपको अपने 'महत्वपूर्ण' जॉब कतार के लिए Anomaly detection ट्रिगर सेटअप करने की सलाह देते हैं।
एक ट्रेड-ऑफ जो आपको अपने APM में नहीं दिखेगा
बड़े जॉब्स के साथ बड़ी समस्या यह है कि उन्हें कोड करना कठिन होता है। आपको व्यक्तिगत जॉब्स को स्पष्ट रूप से idempotent बनाना होगा और उनकी स्थिति का ट्रैक रखना होगा। एक सरल उदाहरण में: जब आपके पास एक जॉब हो जो एक व्यक्ति को मेल करता है और वह विफल हो जाता है, तो आप बिना अधिक नुकसान के इसे रीट्राई कर सकते हैं। 1000 लोगों को मेल करते समय, यदि जॉब विफल हो जाता है, तो आप उन 240 लोगों को फिर से मेल नहीं करना चाहते जिन्हें आप जॉब विफल होने से पहले मेल कर चुके थे। यह सुनिश्चित करना कि ऐसा न हो, कोड को अधिक जटिल बनाता है।
वास्तविकता की वास्तविक जटिलता
एक और वास्तविकता जांच का समय। अक्सर, आपके बैकग्राउंड प्रोसेस Sidekiq में चल रही किसी चीज़ के कारण धीमे नहीं हो सकते। ऐसा हो सकता है कि आप जिस डेटाबेस को क्वेरी कर रहे हैं वह धीमा है क्योंकि जिस होस्ट पर वह चलता है वह मेमोरी से बाहर जा रहा है। इस पोस्ट में उपयोग करने के लिए एक अच्छा उदाहरण ढूंढते समय, हम ऐसे ही एक परिदृश्य में भागे: यह पता चला कि अवधि चरम पर थी क्योंकि बाहरी API का प्रतिक्रिया समय लंबा था। Sidekiq में ऐसा कुछ भी नहीं है जो इसे हल करेगा।
क्योंकि एक समस्या एक जगह देखी जा सकती है लेकिन पूरी तरह से कहीं और पैदा हो सकती है, AppSignal पर हमने उत्पाद को इस तरह बनाया है कि इसमें त्रुटियां, प्रदर्शन, और होस्ट मेट्रिक्स सभी एक साथ हैं। इस दृश्य के संयुक्त मेट्रिक्स समस्या के मूल कारण को ढूंढना आसान बनाएंगे।
कोई आसान जवाब नहीं हैं, है ना?
हालांकि हमने इस लेख को Sidekiq की निगरानी और अनुकूलन की मूल बातों के साथ शुरू किया, हम तुरंत उस वास्तविकता में भागे कि गति की कीमत CPU और IO होगी। या मेमोरी। या अधिक जटिलता पेश करेगी। और हालांकि हमने आपके आर्किटेक्चर में प्रदर्शन की कुछ जटिलता को छुआ, वास्तविकता यह है कि हमने इस पोस्ट में 99% कठिन चीजों को छोड़ दिया।
तो, भले ही हमने सरल उत्तरों के लिए आपकी उम्मीदें छीन ली हों, हम आशा करते हैं कि इस लेख ने आपके Sidekiq सेटअप को अनुकूलित और मॉनिटर करने पर कुछ दिलचस्प विचार प्रेरित किए होंगे!
