प्रदर्शन समस्या: पहले अनुरोध पर देरी


36

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

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

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

मुझे आगे कहां जाना होगा?


2
आपको बता नहीं सकता कि मैं इसे कितना हल करना चाहता हूं। मेरा कार्य सिद्धांत यह है कि एक या एक घंटे के बाद क्रोन चला गया है (कैश फ्लश करना) और उन सभी गैर-कैश्ड डेटाबेस प्रश्नों की आवश्यकता के कारण पहले अनुरोध में कुछ समय लगता है। लेकिन मैं सिर्फ अनुमान लगा रहा हूँ
क्लाइव

मेरे साथ भी वही दिक्कत है। अनाम उपयोगकर्ताओं के लिए कैशिंग सक्षम करने से समस्या हल हो गई, लेकिन मुझे पता है कि यह एक अच्छा समाधान नहीं है
znat

@ किम: मैं सोच रहा था कि क्या आपको समस्या का मूल और / या एक अच्छा समाधान मिल गया है
znat

2
उत्तर के एक जोड़े ने गरीब आदमी के क्रोन का उल्लेख किया है: क्या कोई भी समस्या की पुष्टि कर सकता है कि क्या वे क्रोनब का उपयोग करके क्रोन को ट्रिगर करते हैं, या यदि वे गरीब आदमी के क्रोन पर भरोसा करते हैं?
एंडी

6
दरअसल, यदि यह क्रोन है, तो यह संभवतः क्रोन नहीं है, लेकिन अपडेट_क्रॉन () जो नई रिलीज़ की तलाश में है, इसमें काफी समय लग सकता है। यदि यह समस्या है, तो यह देखने के लिए update.module को अक्षम करने का प्रयास करें।
बेर्दिर

जवाबों:


16

तीन चीजें हैं जो मैं जांच करूंगा।

एक, यदि आप एक उत्पादन साइट पर हैं और PHP फ़ाइलों का संपादन नहीं कर रहे हैं, तो आपको यह सुनिश्चित करना चाहिए कि एपीसी सक्षम है, पर्याप्त मेमोरी है, और एक लंबी टीटीएल है (आप एक दिन के साथ जा सकते हैं या यदि आप चाहते हैं तो कभी भी समाप्त नहीं हो सकते)। आप सेटिंग पर भी विचार कर सकते हैं apc.stat=0एपीसी डॉक्स जानकारी आप टीटीएल स्थापित करने के लिए पास सभी आवश्यक। मेमोरी की मात्रा चुनने के लिए, आपको apc.php फ़ाइल को कहीं संरक्षित रखना चाहिए और मेमोरी उपयोग और मंथन के आँकड़ों की निगरानी करनी चाहिए। एपीसी मेमोरी को समायोजित करें ताकि आपकी मिस रेट बहुत कम हो। प्रारंभिक सुस्ती इसलिए हो सकती है क्योंकि APC भरा हुआ है और खाली हो रहा है (IIRC, APC संपूर्ण कैश को डंप करता है जब वह LRU या अधिक उन्नत कैश रणनीतियों को नियोजित करने के बजाय पूर्ण है)।

दूसरा, सुनिश्चित करें कि आपने MySQL को उचित रूप से ट्यून किया है। आप अपने बफर आकारों को समायोजित करने के लिए mysqltuner का उपयोग कर सकते हैं। डिस्क और / या क्वेरी कैश मिस से लोडिंग टेबल के कारण आपकी प्रारंभिक सुस्ती हो सकती है। जबकि सही नहीं है, mysqltuner आपको सही दिशा में जा रहा है।

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


मैंने लगभग सभी (एम / एल / डब्ल्यू) एएमपी देव के ढेर, यहां तक ​​कि विशेष रूप से बिटमनी जैसे ड्रुपल के लिए भी, बुरी तरह से ट्यून किए गए हैं या बिल्कुल भी ट्यून नहीं किया है (मुझे लगता है कि एक्वाकिया के देव स्टैक अपवाद हैं)। और निश्चित रूप से एक उत्पादन मशीन के लिए एक डिफ़ॉल्ट mySQL स्थापित नहीं है। InnoDB लॉगफ़ाइल्स डिफ़ॉल्ट रूप से 5M की तरह होते हैं और आवंटित मेमोरी मिनीस्कुल होती है। अक्सर एक उचित ट्यूनिंग एक साइट को तड़क-भड़क बनाने के लिए जरूरी है - यहां तक ​​कि सिर्फ my-medium.cnf या my-big.cnf में छोड़ने के लिए पर्याप्त है।
लीबी

इस सवाल के बहुत सारे अच्छे जवाब थे, सभी को धन्यवाद जो इस टिप्पणी को देखता है और पोस्ट में योगदान देता है। मुझे लगा कि इस विशेष उत्तर ने मुख्य मुद्दों को अच्छा और संक्षिप्त रूप से अभिव्यक्त किया है; इन 3 बिंदुओं की पूरी तरह से जाँच करने से विभिन्न विभिन्न मशीनों पर Drupal साइटों को तेजी से चलाने में मदद मिली है। धन्यवाद @MPD
क्लाइव

9

Ivanhoe123 शायद सही है: Drupal 7 डिफ़ॉल्ट रूप से सक्षम 'खराब मैन्स क्रोन' के साथ आता है। संक्षेप में, इसका मतलब यह है कि ड्रुपल पृष्ठ को प्रस्तुत करने से पहले क्रोन चलाया जाता है, जिससे हर चीज में देरी होती है।

हमेशा उत्पादन साइटों पर एक असली क्रोन नौकरी का उपयोग करने का प्रयास करें। अधिक तकनीकी जानकारी के लिए http://drupal.org/cron देखें , या अपनी होस्टिंग कंपनी से बात करें।

इसे निष्क्रिय करने के लिए, व्यवस्थापक / कॉन्फ़िगरेशन / सिस्टम / क्रॉन पर जाएं और 'नेवर' चुनें।


मुझे नहीं लगता कि क्रोन को निष्क्रिय करना समस्या को हल कर रहा है, अधिक संभावना है कि इसे बाद के लिए छिपाया जाए। लेकिन कम से कम मुझे लगता है कि आप प्रदर्शन की समस्या को थोड़ा कम कर सकते हैं;)
wiifm

1
गुण क्रोन को अक्षम करने के लिए नहीं कह रहे हैं; जब कोई उपयोगकर्ता साइट पर किसी पृष्ठ पर जा रहा हो, तो क्रोन कार्यों को लागू करने के विकल्प को बदलने के लिए कह रहा है। यह एक विशिष्ट विकल्प है जो कि Drupal 6 को Poormanscron मॉड्यूल में लागू किया गया था । उस विकल्प को बदलने का मतलब क्रोन कार्यों को अक्षम करना नहीं है।
kiamlaluno

8

Devel आप किसी भी लंबे समय से चल रहा है प्रश्न है कि क्या मॉड्यूल प्रदान करता है डेटाबेस लॉगिंग की जाँच करने के।

यदि यह XHProf या XDebug को लेने में मदद नहीं करता है और दोषी कोड ढूंढता है । XHProf (एक प्रोफाइलर) आपको सर्वर पर निष्पादित होने वाले सभी कार्यों का एक अच्छा नक्शा खींचता है, और यह आपको बताता है कि कौन से लोग सबसे अधिक निष्पादन समय का उपभोग कर रहे हैं। दूसरी ओर, जब XDebug (एक डिबगर) को एक IDE जैसे कि ग्रहण ( वीडियो देखें ) से कॉन्फ़िगर किया गया है, तो यह आपको हर फ़ंक्शन को LIVE निष्पादित करने की अनुमति देता है। प्रोफाइलर आपको अंदाजा लगाएगा कि क्या निष्पादित किया जा रहा है; डिबगर आपको दिखाएगा कि इसे क्यों निष्पादित किया जा रहा है।


2
हां, इस तरह की चीज़ों के कई संभावित कारण हैं, XhProf को आमतौर पर वास्तविक समस्या का पता लगाने का सबसे अच्छा तरीका है।
बेर्दिर

6

बस सवाल के स्वाद से, मैं तुरंत तीन (3) चीजों के बारे में सोचता हूं

  • MySQL Storage Engine / CPU
  • डेटाबेस कैशिंग
  • टेबल लॉकिंग

MySQL संग्रहण इंजन

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

यहाँ मैं DBA StackExchange में और इस साइट में MySQL ट्यूनिंग के लिए MySQL ट्यूनिंग के संबंध में इस बारे में कुछ पोस्ट किए गए हैं

डेटाबेस कैशिंग

सभी MyISAM डेटा को InnoDB में बदलने के लिए एक और मजबूत तर्क यह है कि MySQL डेटा / इंडेक्स को कैसे कैश करता है। MyISAM स्टोरेज इंजन केवल इंडेक्स को कैश करता है। InnoDB डेटा और इंडेक्स को कैश करता है । इसके प्रकाश में, आप निम्न में से किसी एक को समायोजित करने के लिए इनोबीडी बफर पूल के लिए पर्याप्त मेमोरी आवंटित कर सकते हैं (जो भी छोटा हो)

  • सभी InnoDB डेटा और इंडेक्स (आदर्श यदि आपके पास इसके लिए पर्याप्त रैम है और साथ ही ओएस के लिए; बाद में देरी को समाप्त करता है)
  • इंस्टॉल की गई RAM का 75% (यदि आपके पास अधिक InnoDB डेटा / इंडेक्स है जो RAM; विलंब को कम करता है)

यदि आप MySQL 5.1 का उपयोग कर रहे हैं, तो आप innodb_max_dirty_pages_pct = 0. सेट कर सकते हैं । यह डिस्क I / O को थोड़ा बढ़ा देगा, लेकिन InnoDB बफर पूल को पुराने डेटा और इंडेक्स पेजों को बिना डिस्क I / O सर्जेस के घूमने की अनुमति देने के लिए पर्याप्त मंजूरी दी जाएगी। MySQL 5.5 और MySQL 5.1 के InnoDB प्लगइन को इस समायोजन की आवश्यकता नहीं है क्योंकि इसमें एक बेहतर डिफ़ॉल्ट बफ़र पूल फ्लशिंग तंत्र है।

यदि InnoDB का उपयोग करना सवाल से बाहर है, तो आपको मेम्केड या वार्निश के साथ जाने की आवश्यकता हो सकती है। यह डेवलपर को यह निर्धारित करने की अनुमति देता है कि कब तक कैश्ड डेटा सर्वर रैम में रहेगा। स्वाभाविक रूप से, यह आपके आवेदन को यादगार / वार्निश-जागरूक बनाने के लिए विकासात्मक वृद्धि की आवश्यकता होगी।

टेबल लॉकिंग

उपसंहार

MySQL Restart के बाद आप प्रारंभिक देरी से बच नहीं सकते। फिर भी, एक बार जब आप उपरोक्त सुझावों / सूचनाओं का उपयोग करके MySQL को बढ़ाते हैं, तो आपको बाद के विलंब का अनुभव नहीं करना चाहिए।


वास्तव में उपयोगी जानकारी, धन्यवाद। क्या ये समस्याएँ इस समस्या के लिए नियमित रूप से / लगातार हो रही हैं? अधिकांश रिपोर्ट मैंने देखा है कि प्रारंभिक पृष्ठ लोड के लिए वापस आने में 30-60 मिनट के लिए साइट पर निष्क्रियता का परिणाम होता है
क्लाइव

2
@ क्लिक करें सभी MyISAM डेटाबेस के लिए, यह तब होगा जब MyISAM इंडेक्स पेज MyISAM कुंजी कैश में घंटों पहले लोड किए गए थे और लंबे समय तक उपयोग नहीं किए गए थे। उस चक्रीय-आउट डेटा के लिए कॉल करने के लिए MyISAM के लिए डिस्क रीड की आवश्यकता होगी। यह समान व्यवहार InnoDB के लिए भी हो सकता है, खासकर अगर InnoDB बफर बहुत छोटा है। चूंकि InnoDB डेटा और इंडेक्स पेजों को कैश करता है, सभी MyISAM को InnoDB में परिवर्तित करता है और एक बड़े InnoDB बफर पूल का उपयोग करके ऐसे पेज लोड मुद्दों को कम या कम कर सकता है।
RolandoMySQLDBA

ग्रेट मैं इसके आधार पर कुछ प्रोफाइलिंग करूंगा, आशाजनक लगता है। धन्यवाद फिर से
क्लाइव

2
@ क्लिक मैं आपके प्रोफाइलिंग करने के लिए एमके-क्वेरी-डाइजेस्ट या पीटी-क्वेरी-डाइजेस्ट का उपयोग करने की सलाह देना चाहूंगा। मैंने DBA StackExchange में एक अच्छी पटकथा लिखी है, एक crontab से हर निश्चित अंतराल की रूपरेखा तैयार करने के लिए: dba.stackexchange.com/a/8382/877
RolandoMySQLDBA

5

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

यदि यह कैशिंग समस्या नहीं है, तो डेटाबेस को राइट करने के लिए डेवेल की क्वेरी लॉग के साथ-साथ MySQL के लॉग का उपयोग करें। इसके अतिरिक्त, यदि आपके पास सर्वर पर ऑपकोड या समान प्रदर्शन-बढ़ाने वाले कैश हैं, तो उनके साथ कुछ नंबर प्राप्त करने का प्रयास करें और फिर वापस।


4

लगता है जैसे क्रोन चल रहा है।

यहां अपनी सेटिंग्स जांचें: व्यवस्थापक / कॉन्फ़िगरेशन / सिस्टम / क्रॉन


3

मैंने ड्रुपल को इस वजह से अपने आखिरी प्रोजेक्ट के लिए छोड़ दिया।

हालांकि मुझे एक से अधिक कारण होने चाहिए। मुझे अभी तक एक 'फिक्स ऑल' सॉल्यूशन ढूंढना है जो हर बार काम करता है जब यह मुद्दा उठता है।

Syslog और Ubuntu / Debain

पहली बार जब मैंने रुक-रुक कर 15 सेकंड लोड किया था, उस समय ड्रूपल (डेडिकेटेड, नॉन-शेयर्ड) डेबियन / उबंटू आधारित सिस्टम पर चल रहा था। Syslog मॉड्यूल को अक्षम करना मेरे लिए समाधान था।

जैसा @BetaRide ने कहा, xDebug या कुछ अन्य PHP प्रोफाइलर का उपयोग करना अत्यंत ज्ञानवर्धक है।


फिर भी एक समस्या - एक समाधान

मेरे अन्य इंस्टॉल के लिए, मैं अभी भी एक नुकसान में हूं।

यह समस्या मेरे विकास सर्वर पर अधिक ध्यान देने योग्य है और मेरा कम ट्रैफ़िक Drupal इंस्टॉल करता है।

वर्कअराउंड के रूप में मैंने साइटों को होम पेज को हर 60 सेकंड में लोड करने के लिए क्रोन जॉब सेटअप किया है और साथ ही ड्रुपल की क्रोन स्क्रिप्ट को हर 300 सेकंड में। यह स्पष्ट रूप से इष्टतम नहीं है, लेकिन मैं मानव आगंतुक के बजाय 15 सेकंड लोड समय का अनुभव करना या कर्ल करना चाहूंगा।


3

कई लोग सुझाव देते हैं कि यह समस्या समकालिक पृष्ठभूमि प्रक्रियाओं को अवरुद्ध करने से संबंधित हो सकती है , विशेष रूप से भारी क्रोन नौकरियों से संबंधित है ।

यदि सही है, तो gielfeldt * द्वारा सक्रिय विकास के तहत मॉड्यूल की एक बड़ी जोड़ी मौजूद है जो इस मुद्दे को ठीक से काट सकती है, या कम से कम, कुछ सुराग दे सकती है और साइट बिल्डरों को उनके मामलों में विशिष्ट दोषियों का निदान और उपचार करने में मदद कर सकती है। दोनों गैर-अवरुद्ध एसिंक्रोनस HTTP या आदेशों के साथ अवरुद्ध सिंक्रोनस प्रक्रियाओं को प्रतिस्थापित करते हैं, और दोनों प्रासंगिक रिपोर्ट पेश करते हैं जो परेशानी प्रक्रियाओं की पहचान कर सकते हैं:

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

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

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

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


* कोई संबद्धता नहीं, मैं उनके काम का सिर्फ एक अत्यधिक प्रभावित उपयोगकर्ता हूँ


2

चूंकि यह मुझे एक बार फिर से मार रहा है, इसलिए मैं समस्या की जांच शुरू करता हूं। मैं निश्चित रूप से इसकी पुष्टि कर सकता हूं

  1. drupal_cron_run()पोरमैन के क्रोन ऑफ कोर द्वारा ट्रिगर करने के लिए एक कॉल मेरे देव मशीन पर अनुरोध समय में ~ 5 एस जोड़ता है। यह करने के लिए कॉल के आसपास परीक्षण uncommenting द्वारा परीक्षण किया जा सकता drupal_cron_run()में modules/system/system.moduleमेंsystem_run_automated_cron()
  2. सभी कैश समाशोधन मेरी देव मशीन पर अनुरोध समय में ~ 2s जोड़ता है। drush cc allपृष्ठ को फिर से लोड करके और पुनः लोड करके इसका परीक्षण किया जा सकता है ।

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

मुझे यकीन नहीं है कि कैशिंग के बारे में। मैंने इस साइट के लिए डिफ़ॉल्ट कैश सेटिंग को नहीं छुआ है। मुझे लगता है कि ड्रूपल समय-समय पर सभी कैश का पुनर्निर्माण कर रहा है, शायद क्रोन द्वारा ट्रिगर किया गया है, लेकिन मुझे यकीन नहीं है कि यह कैसे किया जाता है। लेकिन जब मैं पेज को कुछ घंटों के बाद हिट करता हूं, तो 7s की देरी बहुत ज्यादा होती है।


1

इस तरह के मुद्दे आपको पागल कर सकते हैं और जब मैं इसी तरह की स्थितियों में रहा था, तो यह पता लगाने में मदद करता है कि उस समय समस्या एक कदम चल रही है और फिर इसे अनाम और लॉग इन उपयोगकर्ता के रूप में परीक्षण करें। (प्याज परत विधि)

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

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

  2. यदि चरण 1 से परिणाम अच्छे हैं और सर्वर तेजी से प्रतिक्रिया दे रहा है और निम्नलिखित अनुरोध तेजी से हो रहे हैं, तो अपने वर्तमान साइट से केवल थीम को क्लीन इंस्टॉल साइट में स्थापित करें और फिर से परीक्षण करें। यदि सब कुछ अभी भी तेजी से प्रतिक्रिया करता है, तो आपका विषय समस्या नहीं है और आपको चरण 3 जारी रखना चाहिए अन्यथा आपको अपने विषय * 1 को डीबग करना शुरू करना होगा।

  3. यदि चरण 2 पर परीक्षणों के बाद भी साइट तेजी से आपकी वर्तमान साइट में मॉड्यूल पर लाना शुरू करती है और प्रत्येक मॉड्यूल * 2 को जोड़ने और सक्षम करने के बाद प्रतिक्रिया समय का परीक्षण करना सुनिश्चित करें।

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

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

* 1 परीक्षण विषय: यह प्रक्रिया एक सुपर विस्तृत विषय में मुश्किल हो सकती है, यहाँ कुछ संकेत दिए गए हैं:

  1. यदि आप किसी बाहरी js या css लाइब्रेरी से लिंक करते हैं, तो उसी की एक स्थानीय प्रति का उपयोग करने का प्रयास करें।

  2. फ़ंक्शन के लिए अपने template.php फ़ाइल की जाँच करें जिसमें लंबी या अंतहीन छोरों के साथ-साथ प्रीप्रोसेस फ़ंक्शन और / या हुक थीम फ़ंक्शन हो सकते हैं।

  3. अन्य टेम्प्लेट फ़ाइल (page.tpl.php, आदि) की जाँच करें और सरणियों और वस्तुओं के कच्चे PHP प्रसंस्करण के लिए देखें।

  4. यदि "दृश्य" का उपयोग करके और टेम्पलेट फ़ाइलों को देखा जाता है, तो तब भी जांचें।

  5. हमेशा डबल रास्तों की जांच करें, छवियों, जेएस और सीएसएस फ़ाइलों का अनुकूलन करें। कभी-कभी किसी भी फाइल में कोड के कई स्निपेट का उपयोग करने पर js फाइलें कुछ भारी हो सकती हैं।

* 2 परीक्षण मॉड्यूल: परीक्षण मॉड्यूल थोड़ा अलग है क्योंकि PHP के साथ भारी हेरफेर के उपयोग की अनुमति है। यहाँ कुछ संकेत दिए गए हैं:

  1. समुदाय समर्थित मॉड्यूल (CCK, Views, etc) में drupal.org पर कतारें हैं। यह देखने के लिए कि क्या आपकी समस्या के बारे में कोई मौजूदा समस्या है या नहीं और यदि संभावना है कि इसे ठीक करने के लिए कोई पैच हो सकता है।

  2. स्वयं कस्टम कोडित मॉड्यूल, यदि आप कोडित हैं तो आपको इसे ठीक करना होगा, ठीक है। अपने कोडिंग को दोबारा जांचें और api.drupal.org के खिलाफ फ़ंक्शन के उपयोग की जांच करें, आप एक हुक के बजाय एक ओवरकिलिंग फ़ंक्शन का उपयोग कर सकते हैं।

  3. इंटरनेट साझा कस्टम कोड मॉड्यूल, चरण 2 में के रूप में करते हैं, लेकिन इस बार आप मूल मॉड्यूल लेखक से भी संपर्क कर सकते हैं और उसे समस्या के बारे में बता सकते हैं।

  4. यदि आपकी साइट एक अपग्रेड (D5 -> D6 -> D7) माइग्रेशन या अपग्रेड स्क्रिप्ट की जांच करती है (आमतौर पर मॉड्यूल.इनस्टॉल फ़ाइल में) तो आपको धीमी एसक्यूएल क्वेरी एक्स को तेज बनाने के लिए नए टेबल कॉन्फ़िगरेशन पर एक अतिरिक्त "इंडेक्स" की आवश्यकता हो सकती है। ।

  5. यदि आपको लगता है कि आपके पास समस्या के बारे में सुरंग की दृष्टि है, तो थोड़ा बाहर निकलें और किसी अन्य गतिविधि को पूरी तरह से अन-संबंधित करें और फिर बाद में मुद्दे को फिर से देखें।

  6. यदि आप कोड के एक खंड पर समस्या को इंगित करते हैं, लेकिन इसे ठीक करने के तरीके के बारे में सिर या पूंछ नहीं बना सकते हैं, तो यह समझाने की कोशिश करें कि उस अनुभाग को उस व्यक्ति को क्या करना है जिसका कोई विचार नहीं है कि कैसे प्रोग्राम करना है या कैसे ड्रुपल काम करना है और होना है हैरान होने के लिए तैयार

नोट: यदि आपकी साइट को फिर से बनाने के बाद अलार्म न हो, तो सभी एक आकर्षण की तरह काम करना शुरू करते हैं, जो कंप्यूटर की सबसे अच्छी विशेषताओं में से एक है।


1
मैंने सिर्फ एक खाली ड्रुपल और कोई देरी नहीं की। इसलिए अगला कदम मेरी थीम को आगे बढ़ा रहा है। हालाँकि, मुझे बहुत समय लगने वाला है क्योंकि मुझे इस मुद्दे को दोहराने के लिए आधे घंटे इंतजार करना होगा
znat

1
यह सुनकर खुशी हुई कि यह हार्डवेयर या सर्वर कॉन्फ़िगरेशन समस्या नहीं है। कृपया अपने निष्कर्ष वापस भेजें।
एमिल ओरोल

1

डबल चेक करें कि आपने किसी मॉड्यूल को अनइंस्टॉल किए बिना डिलीट नहीं किया है। यह देरी का कारण बनता है क्योंकि द्रुपाल फाइलों को खोजने की कोशिश करते हैं लेकिन वे अब वहां नहीं हैं।

चर तालिका में संदर्भ हटाएं यदि मॉड्यूल अब मौजूद नहीं हैं।


1

प्रदर्शन के मुद्दों पर नज़र रखने के लिए एक वेब APM जैसे कि newrelic सबसे अच्छा उपकरण है। मेरे पास कोड की एक या दो पंक्तियों को कॉल करने वाली साइटें हैं जो कि अजीब चीजें करती हैं, अजीब समय पर अनावश्यक सरणियों को लोड करती हैं, और अन्य चीजों को किया है जो तब तक अदृश्य थे जब तक कि हम उन्हें एपीएम के साथ ट्रैक नहीं करते।


1

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

उदाहरण के लिए, पैगोडाबॉक्स में पहले बाइट के लिए 3-4 सेकंड होते हैं, जब तक कि सर्वर खुशी से जाग नहीं जाता। पैगोडाबॉक्स ने वास्तव में सर्वर को जागृत रखने के लिए मुद्रीकृत किया है, और इसलिए आप अपनी साइट को 'कैफ़िनेट' करने के लिए अतिरिक्त भुगतान कर सकते हैं।

साथ ही, एक CDN आपकी सहायता कर सकता है। आपका वेब / db विच्छेदित कैश्ड पृष्ठों या चित्रों की सेवा के साथ लोड नहीं होगा। यहाँ एक अच्छा ट्यूटोरियल: http://wimleers.com/article/easy-drupal-cdn-integration-for-fun-and-profit

और ... WebPageTest मुझे खुश करता है। http://www.webpagetest.org/ ग्रह के चारों ओर लोड समय की तुलना करें और मुफ्त में विभिन्न वेब ब्राउज़रों के साथ। जो भी परिवर्तन आप कर रहे हैं उसके लिए वास्तविक दुनिया परिणाम प्राप्त करने के लिए इसका उपयोग करें।


इस के लिए अच्छा जानकारी है, लेकिन समस्या अभी भी, मेरे स्थानीय मशीन पर साइटों पर होता लेने वाली केवल स्थानीय संसाधनों
क्लाइव

0

समस्या कहीं भी हो सकती है।

  1. सुनिश्चित करें कि आपने किसी थीम या मॉड्यूल पर डिबग मोड चालू नहीं किया है। उदाहरण के लिए, कई थीमों में थीम रजिस्ट्री को फिर से बनाने का विकल्प है।
  2. यदि आप गोडैडी जैसी साझा होस्टिंग पर चल रहे हैं, तो पहली बार अनुरोध के लिए 15 सेकंड सामान्य है।
  3. Drush CTools Export मॉड्यूल का उपयोग करके अपनी साइट या फ्रंट पेज को कोडबेस में बदलें । यह किसी भी डेटाबेस कॉल को समाप्त कर देगा और आपकी साइट पूरी तरह से php से चलेगी।
  4. यदि आपको अभी भी समस्या हो रही है, तो चालू query logऔर page timerविकल्पों को चालू करके Devel सेटिंग्स का उपयोग करें admin/config/development/devel। देखें कि दोनों में से किसको पूरा पृष्ठ बनाने में अधिक समय लगता है।
  5. अपने सर्वर को पुनरारंभ करें यदि कुछ भी काम नहीं करता है।
  6. सबसे खराब मामला यह देखने के लिए XHProf स्थापित करें जहां चीजें गलत हो रही हैं।

1
आप # 2 समझा सकते हैं?
जॉनाथन एलमोर

0

तो यह है कि मैंने अपने स्थापित करने के लिए समस्या कैसे तय की। यह एक वास्तविक समाधान नहीं है क्योंकि मैं समस्या के सटीक स्रोत को नाखून नहीं दे सकता था (यदि एक है), लेकिन यह एक अच्छा समाधान है

1) एग्रिगेट सीएसएस (कैश सेटिंग्स)। इससे विलंबता आधी हो गई

2) क्रोन को कभी भी सेट न करें (और इसे बाहरी रूप से चलाएं) - नोट: मेरे पास "क्रोन शुरू करने का प्रयास है जबकि यह पहले से ही चल रहा है" त्रुटियां। मुझे लगता है कि यह हर लॉन्च में क्रोन शुरू करने की कोशिश कर रहा था, लेकिन चूंकि यह विफल हो गया, क्रोन पेज नवीनतम प्रयास का उल्लेख नहीं कर रहा था, बल्कि नवीनतम सफलता।

3) एक क्रॉन जॉब सेट करें जो हर 30 मिनट में होम पेज को लिंक्स के साथ कॉल करता है

एक साझा होस्टिंग सर्वर पर यह सब। यह इष्टतम नहीं है, लेकिन यह काम करता है


0

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.