प्रोडक्शन में Ruby प्रदर्शन डीबगिंग में महारत: सिद्ध तकनीकें

आप जानते हैं कि प्रदर्शन एक सुविधा है। और बहुत सारी प्रदर्शन समस्याएं विकास के दौरान पाई और ठीक की जा सकती हैं।

लेकिन उन मंदी के बारे में क्या जो केवल प्रोडक्शन में दिखाई देती हैं? क्या आपको हर एक कोड लाइन पर लॉग संदेश जोड़ने होंगे? यह चीजों को और भी धीमा कर देगा! या आप यह देखने के लिए टन छोटे "शायद यह इसे ठीक करता है" कमिट शिप करते हैं कि क्या चिपकता है?

आपको इसका विश्लेषण करने के लिए अपने कोड को बर्बाद नहीं करना होगा। इसके बजाय, इसे rbtrace-इंग करने का प्रयास करें।

अपने चल रहे Ruby ऐप को ट्रेस करें

rbtrace के साथ, आप प्रदर्शन समस्याओं का पता लगा सकते हैं, दूसरे Ruby प्रोसेस के अंदर कोड चला सकते हैं, और कोई कोड जोड़े बिना मेथड कॉल लॉग कर सकते हैं। बस अपने Gemfile में gem "rbtrace" जोड़ें।

मैंने सैम सैफ्रॉन के Ruby में मेमोरी लीक डीबग करने पर अद्भुत पोस्ट से rbtrace के बारे में सीखा (जिसे आपको वास्तव में देखना चाहिए, अगर आपने पहले से नहीं देखा है)।

उस पोस्ट में, सैम ने एक प्रोसेस द्वारा उपयोग किए जाने वाले सभी ऑब्जेक्ट्स को देखने के लिए rbtrace का उपयोग किया:

bundle exec rbtrace -p $SIDEKIQ_PID -e 'Thread.new{GC.start;require "objspace";io=File.open("/tmp/ruby-heap.dump", "w"); ObjectSpace.dump_all(output: io); io.close}' 

यह कमाल है। लेकिन आप बहुत कुछ कर सकते हैं।

rbtrace के साथ आप क्या कर सकते हैं?

कभी प्रोडक्शन में चल रहे अपने SQL स्टेटमेंट्स (और उन्होंने कितना समय लिया) देखना चाहते थे?

~/Source/testapps/rbtrace jweiss$ rbtrace -p $RAILS_PID --methods "ActiveRecord::ConnectionAdapters::PostgreSQLAdapter#execute_and_clear(sql)" *** attached to process 7897 ActiveRecord::ConnectionAdapters::PostgreSQLAdapter#execute_and_clear(sql="SELECT \"articles\".* FROM \"articles\" WHERE \"articles\".\"id\" = $1 LIMIT 1") <0.002631> 

2 सेकंड से अधिक समय लेने वाले सभी मेथड कॉल?

~/Source/testapps/rbtrace jweiss$ rbtrace -p $RAILS_PID --slow 2000 *** attached to process 8154 Integer#times <2.463761> ArticlesController#create <2.558673> 

क्या आप जानना चाहते हैं कि कोई निश्चित मेथड हर बार कब कॉल होता है?

~/Source/testapps/rbtrace jweiss$ rbtrace -p $RAILS_PID --methods "ActiveRecord::Persistence#save" *** attached to process 8154 ActiveRecord::Persistence#save <0.010964> 

आपके ऐप द्वारा चलाए जा रहे थ्रेड्स देखें?

~/Source/testapps/rbtrace jweiss$ rbtrace -p $RAILS_PID -e "Thread.list" *** attached to process 8154 >> Thread.list => [#, #, #, #] 

हां, -e के साथ आप अपने सर्वर के अंदर रूबी कोड चला सकते हैं:

~/Source/testapps/rbtrace jweiss$ rbtrace -p $RAILS_PID -e "ActiveRecord::Base.connection_config" *** attached to process 8154 >> ActiveRecord::Base.connection_config => {:adapter=>"postgresql", :pool=>5, :timeout=>5000, :database=>"rbtrace_test"} 

हां, ठीक है, अब मैं थोड़ा डर गया हूं। लेकिन यह अभी भी बहुत अच्छा है। (और केवल उन उपयोगकर्ताओं को जो प्रोसेस के साथ खिलवाड़ करने की अनुमति रखते हैं, rbtrace कर सकते हैं, इसलिए यह शायद ठीक है)।

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

आपको समस्याओं को ठीक करने के लिए टन टेस्ट कमिट और लॉग संदेश बनाने की ज़रूरत नहीं है। आप बस सर्वर पर हॉप कर सकते हैं, कुछ डेटा प्राप्त कर सकते हैं, और वापस हॉप आउट कर सकते हैं। और यहां तक कि अगर मैं प्रोडक्शन में इसका उपयोग करने में पूरी तरह से सहज नहीं हूं, तो मुझे यकीन है कि यह हमारे टेस्ट वातावरण में भी मदद करेगा।

आप कैसे हैं? आप rbtrace का उपयोग किस लिए कर सकते हैं?