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

तो चलिए शुरू करते हैं।

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

मैं स्थानीय इंटरनेट या कंप्यूटर की कठिन समस्याओं और खामियों को दूर करने का प्रस्ताव रखता हूं, जिसके लिए सिस्टम प्रशासक के सीधे हस्तक्षेप की आवश्यकता होती है। यह ट्रोजन वायरस, हार्डवेयर, ब्राउज़र या ऑपरेटिंग सिस्टम, राउटर पर MTU, गलत DNS सेटिंग्स या DNS विफलताओं और समस्याओं की एक पूरी श्रृंखला हो सकती है, जिनका पता लगाया जा सकता है, लेकिन लेख, इस मामले में, एक पुस्तक में बदल जाएगा या यहां तक ​​कि प्रशिक्षण पाठ्यक्रम में।

इस तथ्य पर ध्यान दें कि हमें इंटरनेट से कोई समस्या नहीं है और साइटें सामान्य रूप से लोड हो रही हैं, लेकिन हमारी साइट रुक-रुक कर उपलब्ध है या बिल्कुल उपलब्ध नहीं है।

कैसे एक कारण खोजने के लिए?

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

ट्रेसरआउट और पिंग सरल टीम हैं, विकिपीडिया पर इस विषय पर बहुत ही सुलभ वर्णन के साथ लेख हैं:
https://ru.wikipedia.org/wiki/Traceroute
https://ru.wikipedia.org/wiki/Ping

यदि ट्रैसरूट साइट के रास्ते में ट्रंक चैनलों पर कहीं भी चिपक जाता है, तो मैं सुझाव देता हूं कि आप निश्चित रूप से जांच लें कि आपके प्रदाता के बाहर वैश्विक नेटवर्क के अन्य सर्वर (कंप्यूटर) से सर्वर / साइट कैसे दिखाई दे रहे हैं। वे, उच्च संभावना के साथ, अन्य राजमार्गों का उपयोग करते हैं और यह अक्सर देखा जाता है कि ट्रेसरआउट सफलतापूर्वक अन्य चैनलों से आपके सर्वर पर गुजरता है। उदाहरण के लिए
http://network-tools.com/default.asp?prog=express&host=www.reg.ru

यदि सब कुछ क्रम में है, तो या तो आपके प्रदाता या उसके प्रदाताओं को समस्याओं का एक उच्च स्तर है, लेकिन आपके सर्वर के पास नहीं और उस पर नहीं।
अब आप अपने स्थानीय प्रदाता का तकनीकी समर्थन कह सकते हैं और पूछ सकते हैं: "वहां के मुख्य चैनल क्या हैं?";)

2. इंटरनेट चैनल की गति और स्थिरता सर्वर से आपके रास्ते में सबसे धीमी और सबसे खराब संचार चैनल की गति और स्थिरता है। आप निर्धारित कर सकते हैं कि क्या पैकेट के साथ समस्याएं हैं "जिस तरह से", विभिन्न प्रदाताओं के बीच या आपके और प्रदाता के बीच बड़े पैमाने पर देरी, mtr उपयोगिता का उपयोग कर, और उपयोगिता के परिणाम विशेष रूप से एक बड़े पैकेट आकार और इसके संभावित विभाजन (उदाहरण के लिए, 1500 बाइट्स) के संकेत हैं। ।

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

कॉल उदाहरण:

mtr -s 1500 --report .com 

Yahoo.com के लिए सत्यापन अनुरोध:

 HOST: xxx.reg.ru Loss% Snt Last Avg Best Wrst StDev 1.|-- 31.31.xxx.xxx 0.0% 10 43.4 16.7 0.5 102.8 33.1 2.|-- bdi-799.sr7.msk1.ip.di-ne 0.0% 10 1.5 1.5 1.5 1.7 0.1 3.|-- vlan-793.br1.msk1.ip.di-n 0.0% 10 0.8 0.8 0.8 0.9 0.0 4.|-- 31.28.19.100 0.0% 10 0.9 4.5 0.9 36.8 11.3 5.|-- ae0-948-rt2.spb.cloud-ix. 90.0% 10 14.7 14.7 14.7 14.7 0.0 6.|-- ae0-59-rt1.frk.cloud-ix.n 10.0% 10 37.7 37.8 37.7 38.3 0.2 ... 15.|-- po-15.bas2-7-prd.gq1.yaho 10.0% 10 204.7 207.0 204.5 211.1 2.8 16.|-- ir1.fp.vip.gq1.yahoo.com 10.0% 10 204.7 227.4 204.7 281.4 32.1 

हमारे लिए संकेतक सूची में हमारे अंतिम सर्वर के प्रतिशत पैकेट हानि (हानि%) का मूल्य होगा। मध्यवर्ती सर्वर पर नुकसान, अगर वे अंतिम को प्रभावित नहीं करते हैं, तो सबसे अधिक संभावना है कि उनके लिए परीक्षण पैकेट की संख्या की सीमितता के कारण (आईसीएमपी ट्रैफ़िक)।

आमतौर पर, अगर बड़े पैकेट का 30 - 50% नुकसान होता है, तो कनेक्शन समस्याएं पहले से ही ध्यान देने योग्य हो जाती हैं (पृष्ठ "चिपक जाता है", अंडरलोड वस्तुओं के कारण धीमा हो जाता है), और प्रतिशत जितना अधिक होता है, उतना ही मुश्किल होता है।

कुछ मध्यवर्ती नोड पर समस्याएं उत्पन्न हो सकती हैं, उदाहरण के लिए, अपने कार्यालय से प्रदाता (यदि कोई हो) के अगले वाई-फाई लिंक पर। इसके अलावा, इसका कारण प्रदाताओं के बीच संचार और पैकेट मार्ग में समस्याएं हो सकती हैं।

एक चैनल (अंग्रेजी में) के साथ समस्याओं का निदान करने के लिए mtr का उपयोग करने पर एक विस्तृत लेख यहां या विकिपीडिया पर पाया जा सकता है।
विंडोज एनटी में एमआरटी यूटिलिटी जैसा कुछ है।

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

3. यदि उपरोक्त परीक्षणों से कोई समस्या सामने नहीं आई, तो हम मुख्य दृश्य और सुविधाजनक टूल का उपयोग करते हैं - क्रोम डेवलपर टूल (सफारी में वेब इंस्पेक्टर, फ़ायरफ़ॉक्स डेवेलपर टूल):
https://developers.google.com/chrome-developer-tools/
https://developer.apple.com/library/safari/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/Introduction/Introduction.html
https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor

Chrome डेवलपर टूल (मेनू -> टूल -> डेवलपर टूल) के साथ काम करते समय, "नेटवर्क" टैब में, हम अपनी साइट के पेज को रीफ्रेश करते हैं और इस पर एक रिपोर्ट प्राप्त करते हैं कि कैसे सभी संसाधन लोड किए गए हैं:



साइट पेज के सफल लोडिंग (यद्यपि धीमे) पर, यह देखा जाएगा: जब पेज की मुख्य सामग्री लोड हो जाती है और यह प्रदर्शन के लिए बनना शुरू हो जाता है, जब सभी एम्बेडेड जावा स्क्रिप्ट साइट पर काम करना शुरू कर देते हैं, पेज तत्वों के साथ काम करने के लिए बंधे होते हैं और मुख्य कोड के पूर्ण लोडिंग की प्रतीक्षा करते हैं और आवश्यक होते हैं अपरिभाषित अतिरिक्त नेस्टेड तत्व। यह क्षण ऊपर की तस्वीर में है: ब्लू वर्टिकल लाइन DOMContentLoaded ईवेंट है, और लाल वर्टिकल लाइन windows.onLoad ईवेंट का संचालन है (जब स्क्रिप्ट पहले ही काम कर चुकी है और तत्वों के साथ पूरा पृष्ठ बन गया है, तो चित्रों की सामग्री लोड हो जाती है)।

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



जैसा कि हम यहां देखते हैं, हमारा ब्राउज़र 68 मिलीसेकंड के लिए सर्वर से डेटा का इंतजार कर रहा था (सर्वर ने हमसे प्राप्त अनुरोध पर एक पृष्ठ बनाया) और इसे 2 मिलीसेकंड (जो काफी तेज है) के लिए स्वीकार किया गया था।

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

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

अवरुद्ध करने का एक सामान्य कारण किसी भी बाहरी सांख्यिकी संग्रह सेवाओं, विज्ञापन इंजनों या लिंक विनिमय पृष्ठों पर पृष्ठ की सामग्री को संशोधित करने (DOMContentLoaded घटना से पहले) की सामग्री को संशोधित करने / बनाने के काम की शुरुआत के क्षण की निर्भरता है। आमतौर पर ये "अन्य" बाहरी स्क्रिप्ट डालने के लिए स्क्रिप्ट के टुकड़े होते हैं:

 <script> document.write('<scr'+'ipt type="text/javascript"'+' src="http://jsc.dt00.net .... </script> 

ये सिस्टम अन्य लोगों के सर्वर पर स्थित हैं और अक्सर हमारे सिस्टम प्रशासकों के लिए दुर्गम हैं, इसलिए वे उदाहरण के लिए जैसा चाहें वैसा व्यवहार कर सकते हैं:



यही है, जब तक कि <script ...> ब्लॉक को लोड और निष्पादित नहीं किया जाता है, जो बदले में एक बाहरी संसाधन को संदर्भित करता है, ब्राउज़र इससे परिणामों की अपेक्षा करेगा, अक्सर पृष्ठ सामग्री को प्रदर्शित नहीं करता है या गलत तरीके से प्रदर्शित करता है, हालांकि आधुनिक ब्राउज़र इंजन वक्र से आगे हो सकते हैं।

इसलिए ऊपर दिए गए स्क्रीनशॉट में, adobi.ru (admobi.js) से विज्ञापन स्क्रिप्ट को लोड करने के कारण पृष्ठ पर लिपियों का काम 135 एमएस की देरी से शुरू हुआ। ऐसे समय होते हैं जब सर्वर विज्ञापन कोड और आंकड़े वितरित करने के लिए उपलब्ध होता है, लेकिन धीरे-धीरे प्रतिक्रिया करता है, और ब्राउज़र, इसके साथ सफलतापूर्वक जुड़ा हुआ है, दसियों सेकंड के लिए प्रतिक्रिया की प्रतीक्षा कर सकता है।

4. ट्रेसरूट (पी। 1) के साथ, डेवलपर टूल (पृष्ठ 3) के माध्यम से एक पृष्ठ को लोड करने के बारे में जानकारी, उदाहरण के लिए, समान बाह्य विश्लेषक सेवाओं का उपयोग करके "अपने सर्वर पर अजीब नज़र" के साथ जाँच की जा सकती है:
http://www.uptrends.com/aspx/free-html-site-page-load-check-tool.aspx

यह कैसा दिखता है:




और http://tools.pPN.com/fpt/

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



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

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

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

• प्लगइन्स के संचालन में समस्या, जो आधुनिक ब्राउज़रों में टन हैं:
  
  • सब कुछ अनप्लग करें और तुलना करें;
  • या इसके विपरीत, सक्षम (के लिए देखो!) एडब्लॉक और भूतिया प्लगइन्स।
  
  
• ब्रेक के बाद सर्वर के साथ पहला संपर्क।
  प्रारंभिक कुंजी विनिमय और प्रमाणपत्र सत्यापन के कारण ब्राउज़र के लिए एक सुरक्षित एसएसएल सत्र की शुरूआत आमतौर पर धीमी होती है। यह सिर्फ तब होता है जब आप साइट पर एक ब्रेक या क्लीजिंग / कीज़ के बाद प्रवेश करते हैं।
  
• अन्य लोगों (बाहरी) स्क्रिप्ट और पृष्ठ तत्वों को लोड करते समय प्रमाण पत्र या कुंजी प्राप्त करने के साथ लॉग्स जो प्रदर्शन को अवरुद्ध कर सकते हैं: सांख्यिकी संग्राहक, विज्ञापन नेटवर्क, बैनर एक्सचेंज।
• पिछले पैराग्राफ से सभी उल्लिखित तत्व, अगर हमारे सर्वर के साथ कनेक्शन अच्छा है, लेकिन इस एम्बेडेड तत्व को देने वाले सर्वर के साथ यह खराब है या यह अतिभारित है।
  जैसा कि ऊपर दिए गए पैराग्राफ में से एक में कहा गया है, जब तक स्क्रिप्ट लोड नहीं होती है, तब तक पेज रेंडर करने के लिए "स्टिक" हो सकता है, ऑनडोम / ओनलॉड को देरी से संसाधित किया जाता है। अक्सर ऐसा होता है कि अन्य पृष्ठों को देखते समय, यह तत्व पहले से ही कैश्ड है और सब कुछ क्रम में है। यहां आप इन बाहरी सर्वरों के अनुरोधों को बाहर करने का प्रयास कर सकते हैं (फिर, हम डेवलपर टूल में ब्रेक को देखते हैं) उन्हें मेजबान फ़ाइल में थोड़ी देर के लिए होस्ट फ़ाइल में जोड़कर बदल सकते हैं:
  
  • आंकड़े-संग्रह server.ru 127.0.0.1;
  • ad-server.com 127.0.0.1;
  • और अन्य सर्वर, लिपियों को पृष्ठ पर कहा जाता है।
  
  हमें याद रखना चाहिए कि अगर हम अपने नेटवर्क के अंदर इंटरनेट पर कुछ सर्वरों के बजाय "अपने लैपटॉप पर सीधे" (स्थानीयहोस्ट, 127.0.0.1 पर) रिडायरेक्ट करते हैं, तो हमें दूसरी देरी मिल सकती है, जैसा कि ऊपर दिए गए उदाहरण में है, जहां हमारे पास यह है पोर्ट टाइमआउट से प्रतिक्रिया नहीं करता है।
  
• यदि पेज लोड संतुलन के दौरान बदले में एक नहीं बल्कि कई सर्वरों को लौटाता है, तो ऐसा होता है कि कुछ समय के बाद हमें किसी प्रकार का "तंग" सर्वर मिलता है, और फिर फिर से फास्ट करने के लिए।
  यहां आप देख सकते हैं कि क्या उन लोगों के लिए एक अलग सर्वर नाम है जिनसे लोड वितरित किया गया है, और सीधे काम करते हैं।
• स्थैतिक अपलोड सर्वर के साथ एक समस्या है अगर यह किसी अन्य सर्वर द्वारा जारी किया जाता है। यहां, बाद के डाउनलोड अक्सर क्रम में होते हैं, चूंकि सभी स्टेटिक्स समाप्ति समय के ध्यान देने योग्य मार्जिन के साथ आते हैं, इसलिए जब वे एक बार धीमा हो जाते हैं, तो पृष्ठ सामान्य रूप से लोड होते हैं। डेवलपर टूल कैश को साफ़ करने या अक्षम करने के विकल्पों के साथ इसे स्पष्ट रूप से देखने में मदद करेगा।
• यदि आपकी साइट के पृष्ठों को संपादित करते समय "ब्रेक" मनाया जाता है, तो आप पृष्ठ से बाहरी विज्ञापन और आंकड़ों के तत्वों और ब्लॉकों को छोड़कर बदल सकते हैं और अद्यतन कर सकते हैं, निर्धारित कर सकते हैं कि समस्या क्या है।

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