परत दर परत ऑप्टिमाइज़ करें — प्रत्येक परत अगली परत तक पहुंचने से पहले भार को अवशोषित करती है। लक्ष्य अधिकांश अनुरोधों को कैश से प्रदान करना और PHP और डेटाबेस को कम से कम काम करने देना है।
अपने RAM के अनुसार पूल का आकार बदलें, और सक्षम करें ताकि PHP एक बार संकलित हो, हर अनुरोध पर नहीं:
; php-fpm pool: cap workers so you don't exhaust RAM
; pm.max_children = (available RAM for PHP) / (avg process size, ~50MB)
pm = dynamic
pm.max_children = 40 ; hard ceiling on concurrent PHP workers
pm.start_servers = 10
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.max_requests = 500 ; recycle workers to avoid memory leaks
; OPcache: cache compiled bytecode in memory
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0 ; skip file-stat checks in prod (flush on deploy)
यदि max_children बहुत अधिक है तो आप स्वैप और क्रैश करते हैं; बहुत कम और अनुरोध कतार में लगते हैं (लोड के अंतर्गत 502)।
यह स्तरीकरण मतलब है कि एक होमपेज हिट किनारे या पेज कैश से PHP या DB को बिल्कुल छुए बिना लौट सकता है।
अपराधियों को खोजने के लिए slow query log सक्षम करें, कस्टम क्वेरीज के लिए indexes जोड़ें, और autoloaded options की जांच करें (wp_options autoload = yes के साथ हर अनुरोध पर लोड होते हैं — फूला हुआ autoload डेटा सब कुछ धीमा कर देता है)। अंत में, प्लगइन ब्लोट कम करें: प्रत्येक प्लगइन क्वेरीज और PHP कार्य जोड़ता है, इसलिए अप्रयुक्त लोगों को हटा दें।
एक WordPress अनुरोध डिफ़ॉल्ट रूप से PHP- और DB-भारी है, इसलिए ट्यूनिंग के बिना ट्रैफिक के अंतर्गत यह विफल हो जाता है। स्तरीय कैशिंग (OPcache → ऑब्जेक्ट कैश → पेज कैश → CDN) साथ ही सही आकार वाला PHP-FPM और एक दुबला डेटाबेस एक एकल सर्वर को ट्रैफिक के परिमाण के क्रम में अधिक हैंडल करने देता है — और स्पाइक्स के दौरान इसे चालू रखता है।