xdebug व्यवस्थापक के हाथों में

लेख वेब-सर्वर के सिस्टम प्रशासकों द्वारा xdebug के संभावित उपयोग के बारे में बात करेगा। ऐसा लग सकता है कि व्यवस्थापक को कोड के निदान और डिबगिंग में शामिल नहीं होना चाहिए, क्योंकि यह प्रोग्रामर का काम है। ऐसा है। लेकिन, कैसे, एक समस्या की स्थिति में, प्रोग्रामर को यह समझाने के लिए कि उसका कोड इष्टतम नहीं है (यदि यह वास्तव में ऐसा है) और प्रोग्रामर को हर समय फिर से काम करने की आवश्यकता होती है: "हमारे साथ सब कुछ ठीक है - सर्वर की मरम्मत करें"? कल्पना कीजिए कि यह एक प्रोग्रामर है जिसके साथ बहस करना अवांछनीय है। उदाहरण के लिए, हमारा बहुत प्रिय और अडिग ग्राहक।

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

दिलचस्प है, ऐसी समस्याओं के कारणों को लगभग कहीं भी छिपाया जा सकता है। और कई कारण हो सकते हैं, और समस्याओं को स्वयं को पुन: पेश करना मुश्किल हो सकता है। उपयोगकर्ता निम्न स्तर पर "ब्रेक" के रूप में वर्गीकृत करता है:

• साइट के नेटवर्क एक्सेस चैनल में देरी
• सर्वर हार्डवेयर समस्याएँ
• पर्याप्त सर्वर संसाधन नहीं
• एक उप-इष्टतम ऑपरेटिंग सिस्टम
• उप-इष्टतम सॉफ्टवेयर
• तृतीय-पक्ष संसाधनों तक पहुंच के साथ समस्याएं, जिनके लिए एक्सेस को सिंक्रोनाइज़ किया जाता है
• Suboptimal साइट कोड

प्रशासक का कार्य पहचान करना है और यदि संभव हो तो इन समस्याओं को खत्म करना चाहिए। यदि वे, निस्संदेह, जिम्मेदारी के क्षेत्र में हैं। और अंतिम और, संभवतः, दंडात्मक बिंदु उसके जिम्मेदारी के क्षेत्र में शामिल नहीं हैं। लेकिन यह भी दिखाना आवश्यक है कि समस्या इन बिंदुओं में ठीक है।

यह बाद के मामले के बारे में है जिसे हम अपने लेख में चर्चा करेंगे। अभ्यास से पता चलता है कि यह मामला साइट के धीमे संचालन से जुड़ी सभी समस्याओं का लगभग 90% है। गैर-इष्टतम कोड, खराब लिखित SQL क्वेरी, तालों का अनुचित उपयोग - यह सब साइट को धीमा कर सकता है। और अगर कुछ बिंदु तक शक्तिशाली हार्डवेयर खराब कोड को पचा सकता है, तो एक निश्चित बिंदु "x" के आगमन के साथ, यह केवल लोड का सामना करना बंद कर देता है। क्षमता को और अधिक बढ़ाना संभव है, लेकिन, सबसे पहले, वे किसी दिन बाहर चलाएंगे, और दूसरी बात, यह अनावश्यक उपकरण लागत है। इसलिए, सबसे पहले, समस्या का समाधान साइट कोड के विश्लेषण से शुरू होना चाहिए।

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

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

हां, मैं पूरी तरह से भूल गया, यह PHP में विकसित होने के बारे में है! अधिकांश वेब प्रोग्रामर इसका उपयोग और प्यार करते हैं। हालांकि, "प्रेम" की कीमत पर सवाल बल्कि विवादास्पद है।

Xdebug

Xdebug एक PHP डेवलपर द्वारा लिखा गया एक PHP एक्सटेंशन है और php कोड में डिबगिंग जानकारी एकत्र करने और विश्लेषण करने के लिए डिज़ाइन किया गया है। यह ध्यान रखना महत्वपूर्ण है कि यह एक ओपन-सोर्स प्रोजेक्ट है।

हम सिस्टम एडमिनिस्ट्रेटर के प्रिज्म के माध्यम से xdebug पर विचार करेंगे, केवल कार्यक्षमता को प्रभावित करने के लिए जो साइट कोड को संपादित करने की आवश्यकता नहीं है, और सर्वर को भी धीमा नहीं करता है।

जाहिर है, कोई भी रूपरेखा या अनुरेखण कोड निष्पादन के दौरान अतिरिक्त देरी का परिचय देता है। इसलिए, निदान को साइट के प्रदर्शन को प्रभावित नहीं करना चाहिए।

Xdebug स्थापना

Centos / RHEL / फेडोरा का उपयोग करते समय, Xdebug को स्थापित करने का सबसे आसान तरीका EPEL रिपॉजिटरी से इंस्टॉल करना है:

$ यम php-pecl-xdebug स्थापित करें

Pecl का उपयोग कर स्थापना:

$ pecl xdebug स्थापित करें

आप स्रोत कोड से xdebug को पहले http://xdebug.org/download.php पर डाउनलोड करके भी स्थापित कर सकते हैं:

$ टार xvzf xdebug-2.2.1.tgz
$ cd xdebug-2.2.1
$ phpize
$ ./configure --enable-xdebug
$ मे && मेक इनस्टॉल

Xdebug सेटअप

मूल सेटअप केवल नए स्थापित एक्सटेंशन को php.ini फ़ाइल से कनेक्ट करना होगा। इस फ़ाइल में, आपको लाइन की उपस्थिति के लिए जाँच करनी होगी:

zend_extension = /path/to/xdebug.so
xdebug.default_enable = 0
xdebug.overload_var_dump = 0

यदि लाइन को php.ini या किसी भी सम्मिलित फाइल में नहीं जोड़ा गया है, उदाहरण के लिए /etc/php.d/xdebug.ini , तो आपको इसे मैन्युअल रूप से करना होगा। फिर वेब सर्वर को पुनरारंभ करें।

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

विश्लेषण के साथ शुरुआत करना: ट्रेस फ़ंक्शन कॉल

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

• कोड प्रारंभ और समाप्ति समय
• कार्यात्मक आदेश
• प्रत्येक फ़ंक्शन निष्पादन समय
• प्रत्येक फ़ंक्शन द्वारा मेमोरी की खपत

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

xdebug.collect_params इंगित करता है कि फ़ंक्शन तर्कों के बारे में जानकारी एकत्र करने के लिए आपको कितना विवरण चाहिए। 0 - न्यूनतम, जानकारी एकत्र नहीं की जाती है। 1 - संख्या और प्रकार के तर्कों के बारे में जानकारी एकत्र की जाती है। 3 - तर्कों के अर्थ के बारे में जानकारी। 4 - पूर्ण जानकारी: हस्तांतरण के समय प्रकार, नाम, तर्क मूल्य। हम जितनी अधिक जानकारी चाहते हैं, अनुरेखण में अधिक समय लगेगा।
xdebug.show_mem_delta प्रत्येक फ़ंक्शन को कॉल करने पर अंतिम रिपोर्ट में मेमोरी खपत में अंतर को प्रतिबिंबित करने या न करने का निर्धारण करता है।
xdebug.trace_enable_trigger मांग पर अनुरेखण शुरू करने की क्षमता को सक्षम या अक्षम करता है।
xdebug.auto_trace हर बार आपके द्वारा साइट के पृष्ठों तक पहुँचने पर ट्रेस की स्वचालित शुरुआत को सक्षम या अक्षम करता है।
xdebug.collect_assignments में रिपोर्ट में चर असाइनमेंट जानकारी शामिल या शामिल नहीं है।
xdebug.collect_includes में रिपोर्ट में जुड़ी फ़ाइलों के बारे में जानकारी शामिल है या शामिल नहीं है।
xdebug.collect_return में फ़ंक्शन द्वारा दिए गए मानों के बारे में रिपोर्ट जानकारी शामिल है या शामिल नहीं है।
xdebug.trace_output_dir उस निर्देशिका को निर्दिष्ट करता है जिसमें रिपोर्ट डाली जाएगी।
xdebug.trace_output_name रिपोर्ट के लिए फ़ाइल नाम बनाता है।

शेष चर रिपोर्ट के दृश्य प्रदर्शन से जुड़े हैं, और हमें कोई दिलचस्पी नहीं है। मानक रूप विश्लेषण के लिए काफी स्वीकार्य प्रतीत होता है।

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

हम ट्रांसफर किए गए वैरिएबल, कनेक्टेड फाइल्स और फंक्शनल कॉल्स के बीच खपत की गई मेमोरी में अंतर के बारे में अधिकतम जानकारी एकत्र करेंगे। रिपोर्ट को / var / tmp में जोड़ा जाएगा। अन्य सेटिंग्स डिफ़ॉल्ट रूप से होंगी। परिणामस्वरूप, php.ini में निम्नलिखित पंक्तियाँ जोड़ें:

xdebug.trace_enable_trigger = 1
xdebug.auto_trace = 0
xdebug.collect_params = 4
xdebug.show_mem_delta = 1
xdebug.trace_output_dir = / var / tmp


और हम वेब सर्वर को रिबूट करते हैं। विश्लेषण के लिए, निम्नलिखित कोड लें:

<?php require "config.inc"; require "class/db.php"; for ($i = 1; $i < 6; $i++) { show_num($i); } $v = array(); alloc_array(1024); $db = DB::Get("mysql", HOST, USER, PASS, NAME); $db->connect(); echo "finished"; function show_num($i) { ($i % 2) ? show_odd($i) : show_even($i); } function show_odd($i) { echo "odd: $i<br>"; } function show_even($i) { echo "even: $i<br>"; sleep(1); } function alloc_array($size) { global $v; for ($i = 0; $i < $size; $i++) { $v[] = $i; } } ?> 

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

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

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

जावास्क्रिप्ट: document.cookie = "XDEBUG_TRACE = 1"


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

  TRACE START [2012-09-25 11:19:54]
     0.0005 645152 +645152 -> {मुख्य} () /var/www/test.phpPoint
     0.0007 649296 +4144 -> आवश्यकता (/var/www/config.inc) /var/www/test.php:4
     0.0007 649504 +208 -> परिभाषित ('HOST', '10 .1.1.1 ') /var/www/config.inchaps
     0.0008 649536 +32 -> परिभाषित ('NAME', 'db') /var/www/config.inc:4
     0.0008 649568 +32 -> परिभाषित ('USER', 'u0') /var/www/confile.inchaps
     0.0008 649600 +32 -> परिभाषित ('पास', 'पीएस') /var/www/config.inc6
     0.0012 695728 +46128 -> आवश्यकता (/var/www/class/db.php) /var/www/test.phpeps
     0.0013 694736 -992 -> show_num ($ i = 1) /var/www/test.php:8
     0.0013 694736 +0 -> show_odd ($ i = 1) /var/www/test.php:21
     0.0013 694864 +128 -> show_num ($ i = 2) /var/www/test.php:8
     0.0013 694864 +0 -> show_even ($ i = 2) /var/www/test.php:21
     0.0014 694960 +96 -> नींद (1) / सवर्ण / व्रत / पंथ ।30
     1.0033 694864 -96 -> show_num ($ i = 3) /var/www/test.php:8
     1.0034 694864 +0 -> show_odd ($ i = 3) /var/www/test.php:21
     1.0034 694864 +0 -> show_num ($ i = 4) /var/www/test.php:8
     1.0034 694864 +0 -> show_even ($ i = 4) /var/www/test.php:21
     1.0035 694960 +96 -> नींद (1) / सवर्ण / व्रत / पंथ ।30
     2.0047 694864 -96 -> show_num ($ i = 5) /var/www/test.php:8
     2.0048 694864 +0 -> show_odd ($ i = 5) /var/www/test.php:21
     2.0048 695224 +360 -> आबंटन_अर्ज़ ($ आकार = 1024) /var/www/test.php/13
     2.0057 843024 +147800 -> DB :: Get ($ प्रकार = 'mysql', $ host = '10 .1.1.1 ', $ उपयोगकर्ता =' u0 ', $ पास =' ps ', $ db =' db ') / var /www/test.php:15
     2.0057 843664 +640 -> absDB -> __ निर्माण ($ होस्ट = '10 .1.1.1 ', $ उपयोगकर्ता =' u0 ', $ पास =' ps ', $ db =' db ') / var / www / वर्ग / db। php: 10
     2.0058 843664 +0 -> DB -> __ निर्माण ($ होस्ट = '10 .1.1.1 ', $ उपयोगकर्ता =' u0 ', $ पास =' ps ', $ db =' db ') / var / www /' db '। php: 36
     2.0058 844000 +336 -> DB-> निर्माण () /var/www/class/db.php:19
     2.0058 844016 +16 -> absDB-> कनेक्ट () /var/www/test.php:16
     2.0058 844368 +352 -> mysqli_connect ('10 .1.1.1 ',' u0 ',' ps ',' db ') /var/www/class/db.php:47
    11.0164 8432
 TRACE END [2012-09-25 11:20:05] 

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

आइए समझने की कोशिश करें कि कोड धीरे-धीरे चलने का क्या कारण है। सबसे पहले, mysqli_connect () फ़ंक्शन का लंबा काम, जिसमें लगभग 9 सेकंड लगते हैं, हड़ताली है। जाहिर है, दूरस्थ सर्वर तक पहुंचने में समस्याएं हैं। ध्यान दें कि इस फ़ंक्शन को अमूर्त और कक्षाओं की कई परतों के माध्यम से कहा जाता है। कई रूपरेखाओं के लिए, यह एक सामान्य बात है। इसके अलावा, नींद () फ़ंक्शन में देरी होती है, जिसे उपयोगकर्ता द्वारा परिभाषित show_even () फ़ंक्शन में कहा जाता है।

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

हम सभी फ़ंक्शन को दिए गए तर्कों के बारे में सभी आवश्यक जानकारी देखते हैं, जिससे डेवलपर इन रिपोर्टों की सोर्स कोड से तुलना कर सकेगा।

कोड प्रोफाइलिंग

यह एक और अवसर का उल्लेख करने योग्य है कि xdebug कोड में अड़चन खोजने के लिए प्रदान करता है, और जिसे सर्वर व्यवस्थापक साइट कोड में बदलाव किए बिना उपयोग कर सकता है। यह प्रोफाइलिंग है। कुकी चर के नाम को छोड़कर, फ़ंक्शन ट्रेस प्रारंभ होने पर उसी तरह से प्रोफाइलिंग शुरू होती है। XDEBUG_TRACE के बजाय, XDEBUG_PROFILE का उपयोग किया जाता है। प्रोफाइलिंग के परिणामस्वरूप, हमें डेटा के साथ एक फ़ाइल मिलती है, जिसे vgrgrind से callgrind_annotate उपयोगिता द्वारा पहचाना जा सकता है, और विंडोज के लिए KDE या WinCacherrind के लिए KCacheGrind उपयोगिता का उपयोग करके रेखांकन भी प्रदर्शित किया जा सकता है। उनमें से KCacheGrind कार्यक्षमता में सबसे अमीर है।

फ़ंक्शन ट्रेसिंग निर्देशों के समान निर्देशों का उपयोग करके ऑन-डिमांड रूपरेखा को कॉन्फ़िगर किया जा सकता है:

xdebug.profiler_enable = 0
xdebug.profiler_enable_trigger = 1
xdebug.profiler_output_dir = / var / tmp