आप जानते हैं कि प्रदर्शन एक विशेषता है। और विकास के दौरान बहुत सी प्रदर्शन समस्याओं का पता लगाया जा सकता है और उन्हें ठीक किया जा सकता है।
लेकिन उन मंदी का क्या जो केवल उत्पादन में दिखाई देती हैं? क्या आपको कोड की प्रत्येक पंक्ति में लॉग संदेश जोड़ना है? इससे चीजें और भी धीमी हो जाएंगी! या क्या आप बहुत सारे छोटे "शायद यह इसे ठीक कर देता है" यह देखने के लिए भेजता है कि क्या चिपक जाता है?
इसका विश्लेषण करने के लिए आपको अपने कोड को बर्बाद करने की आवश्यकता नहीं है। इसके बजाय, rbtrace
आज़माएं - इसे।
अपने चल रहे रूबी ऐप को ट्रेस करें
आरबीट्रेस के साथ, आप प्रदर्शन समस्याओं का पता लगा सकते हैं, किसी अन्य रूबी प्रक्रिया के अंदर कोड चला सकते हैं, और बिना कोई कोड जोड़े लॉग विधि कॉल कर सकते हैं। बस gem "rbtrace"
जोड़ें आपके Gemfile
. पर ।
मैंने रूबी में मेमोरी लीक डीबग करने के बारे में सैम केसर की अद्भुत पोस्ट से 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}'
यह कमाल है। लेकिन आप और भी बहुत कुछ कर सकते हैं।
आरबीट्रेस के साथ आप क्या कर सकते हैं?
क्या आप कभी उन 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
=> [#<Thread:0x007ff4fcc9a8a8@/usr/local/lib/ruby/gems/2.2.0/gems/puma-2.6.0/lib/puma/server.rb:269 sleep>, #<Thread:0x007ff4fcc9aa10@/usr/local/lib/ruby/gems/2.2.0/gems/puma-2.6.0/lib/puma/thread_pool.rb:148 sleep>, #<Thread:0x007ff4fcc9ab50@/usr/local/lib/ruby/gems/2.2.0/gems/puma-2.6.0/lib/puma/reactor.rb:104 sleep>, #<Thread:0x007ff4f98c0410 sleep>]
हां, -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 का उपयोग किस लिए कर सकते हैं?