संपादित करें: मैंने मूल पोस्ट को गलत बताया है। 168 मॉड्यूल एक बहुत है, और 300 से 700ms SQL क्वेरी बहुत बड़ी है । जितने अधिक मॉड्यूल आप उपयोग करेंगे, उतने ही अधिक प्रश्न होंगे जैसे ही मॉड्यूल कुछ करता है।
आक्रामक कैशिंग का उपयोग करें जब आप सब कुछ कर सकते हैं, अगर यह पर्याप्त नहीं है, तो रिवर्स प्रॉक्सी कैश का प्रयास करें। फ़ाइलों के लिए CDN का उपयोग करना पूरी चीज़ को बेहतर बना सकता है। पृष्ठों को मारते समय कुछ प्रॉपर्टी कुकीज़ को हटाकर रिवर्स प्रॉक्सी कैश भी आपकी मदद कर सकता है, जिन्हें इसकी आवश्यकता नहीं है (तब कोर को लगता है कि उपयोगकर्ता उन लोगों के लिए गुमनाम है और कैशिंग को अधिकतम करेगा)।
जैसे ही आपके पास बहुत सारे मॉड्यूल एक ही समय में इंटरैक्ट होते हैं, ड्रुपल कोर डायनामिज्म पूरे भोर को धीमा कर देता है।
मैं कहता हूं, उदाहरण के लिए, यदि आप फ़ील्ड का उपयोग करने के बजाय हुक_नोड_लोड () समय पर डेटा लोड करने वाले बहुत सारे मॉड्यूल का उपयोग करते हैं, तो यह बहुत सारे प्रश्न करेगा जबकि फ़ील्ड उपयोग कैशिंग दक्षता सुनिश्चित करेगा।
रेंडर करने में बहुत अधिक समय लग सकता है, drupal_render () (प्रतिपादन एपीआई कुछ समय कहा जा रहा है) एपीआई का एक अच्छा टुकड़ा है (वास्तव में उपयोगी) लेकिन थोड़ा धीमा भी। PDO (D7) और पूर्ण DBTNG (जो रास्ते में महान है) पर स्विच करना भी गैर-नकारात्मक विलंबता को जोड़ता है।
उस ने कहा, अपने आप में कोर काफी तेज है (लेकिन यह बहुत अधिक SQL क्वेरी करता है, यहां तक कि लगभग कुछ भी स्थापित नहीं है), खराब कोडित मॉड्यूल अक्सर अड़चन होते हैं।
APC रन कोड के आधार पर निष्पादन समय को 2 या 3 प्रति विभाजित कर सकता है। यदि आप इसे अच्छी तरह से कॉन्फ़िगर करते हैं (सभी APC अनुकूलन सक्षम करें, तो आधिकारिक APC मैनुअल अच्छी तरह से लिखा गया है और आपका मार्गदर्शन करेगा)।
यदि आप एक धीमी फ़ाइल प्रणाली (नेटवर्क फ़ाइल सिस्टम या धीमी गति से हार्ड ड्राइव) वाले बॉक्स पर हैं, तो यह निष्पादन समय पर एक दृश्य प्रभाव डाल सकता है। Drupal बहुत सारी छोटी फ़ाइलों से बना है , जो PHP को I / O को हर बार FS पर करने के लिए मजबूर करता है जब वह उनमें से किसी एक को लोड करता है (APC उस के लिए भी बहुत मदद करता है)।
यदि आप MySQL का उपयोग ठीक ट्यूनिंग करने के बारे में सोच रहे हैं तो एक गलत असंबद्ध DBMS भी काफी बदसूरत अड़चन हो सकता है। यदि आप एक साझा होस्टिंग पर हैं, अगर यह ड्रुपल विशिष्ट (या तैयार) DBMS और PHP स्टैक नहीं है तो संभवतः गलत तरीके से या गैर-ट्यून किया जाएगा, जो वास्तव में धीमी साइटों को जन्म दे सकता है।
सभी कैश को सक्रिय करने के लिए मत भूलना। यदि आपकी साइट उपयोगकर्ता उन्मुख प्रमाणित नहीं है, तो एग्रेसिव पेज कैशिंग (यह वास्तव में आश्चर्यजनक है) को सक्रिय करें।
जितने आपके पास ब्लॉक होंगे, उतने अधिक पूर्ण पृष्ठ धीमे होंगे, व्यूज़ मॉड्यूल ब्लॉक एक भोर की अड़चन होगी (आपके द्वारा उपयोग किए जाने वाले दृश्य प्लगइन्स के आधार पर, ओजी का ब्लॉक वास्तविक दर्द हो सकता है) यदि आप उनकी दृश्यता को सीमित नहीं करते हैं। प्रति-पृष्ठ के आधार पर, या कस्टम PHP कोड (किसी भी अन्य ब्लॉक के साथ, हमेशा अपने ब्लॉक दृश्यता को मैन्युअल रूप से सेट करें, खाली ब्लॉकों को प्रस्तुत करने का प्रयास करने से बचने से फ्रेमवर्क को बहुत मदद मिलती है)।
मॉड्यूल से बचें जो हुक_इनिट () का उपयोग करता है, हुक_इनिट () हर पृष्ठ पर चलाया जा रहा है, भले ही आपको 403 या 404 मिलता हो, जो सब कुछ धीमा कर देता है (यह इमेजकेस को धीमा भी करता है। स्टाइल पीढ़ी का समय, और फाइलों पर 40 त्रुटियां होगी) धीमी गति से बस आपको यह बताने के लिए कि फ़ाइल मौजूद नहीं है)।
