WordPress पर Redis Object Cache कैसे सेटअप करें

WordPress के लिए Redis object cache क्या करता है

WordPress के लिए Redis object cache डेटाबेस क्वेरी के परिणामों को मेमोरी में स्टोर करता है, ताकि अगली रिक्वेस्ट में उन्हें MySQL से दोबारा पूछने के बजाय Redis से पढ़ा जा सके। WordPress के कोर में पहले से ही एक object cache होता है, WP_Object_Cache, लेकिन यह PHP मेमोरी में रहता है और रिक्वेस्ट समाप्त होते ही हटा दिया जाता है। एक drop-in फाइल इसे Redis से बात करने वाले cache से बदल देती है, जिससे cache एक रिक्वेस्ट से दूसरी रिक्वेस्ट तक बना रहता है।

Object caching, page caching नहीं है, और यही अंतर तय करता है कि यह गाइड आपके लिए उपयोगी है या नहीं। Page cache किसी URL के तैयार HTML को स्टोर करता है और PHP को चलाए बिना उसे दोबारा सर्व करता है। यह Redis द्वारा किए जा सकने वाले किसी भी काम से तेज है, और यह उन विजिटर्स के लिए काम करता है जो लॉग इन नहीं हैं। जैसे ही कोई लॉग इन करता है, कार्ट में कोई आइटम डालता है, या एडमिन पैनल खोलता है, page cache हट जाता है और WordPress पूरी रिक्वेस्ट चलाता है: बूटस्ट्रैप, प्लगइन्स, क्वेरीज़। Object cache उस रिक्वेस्ट को सस्ता बनाता है। यह उस ट्रैफिक के लिए टूल है जिसे page cache छू नहीं सकता: लॉग-इन सेशन, कार्ट, चेकआउट, wp-admin। WooCommerce शॉप पर यह सबसे महंगा ट्रैफिक होता है।

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

शुरू करने से पहले एक ईमानदार सीमा। Object cache किसी धीमी क्वेरी को तेज नहीं बनाता है। यह उस क्वेरी के दोहराव को हटाता है जो पहले ही चल चुकी है। मिस होने के बाद पहली रिक्वेस्ट पूरी कीमत चुकाती है, इसलिए एक अनइंडेक्स्ड क्वेरी चलाने वाला प्लगइन इसे अभी भी प्रति cache लाइफटाइम एक बार चलाता है।

शुरुआत के लिए आवश्यक चीजें

• एक Linux VPS जिसमें shell और sudo का एक्सेस हो। किसी control panel की आवश्यकता नहीं है।
• PHP-FPM द्वारा संचालित WordPress, उदाहरण के लिए Ubuntu 24.04 पर LAMP stack पर।
• सर्वर पर WP-CLI। यहाँ दिए गए हर चरण का admin-screen विकल्प मौजूद है, लेकिन shell वर्ज़न अधिक तेज है।
• PHP के साथ उसी मशीन पर Redis। इसका मुख्य उद्देश्य latency कम करना है, और नेटवर्क हॉप (network hop) इसे निष्प्रभावी कर देता है।

नीचे दिए गए commands Ubuntu 24.04, PHP 8.3 और www-data वेब यूजर के लिए लिखे गए हैं। अपने सर्वर के अनुसार PHP वर्ज़न और यूजर को बदलें। wp commands को अपनी WordPress डायरेक्टरी से चलाएं, जिसमें wp-config.php मौजूद है।

Redis और PHP extension इंस्टॉल करें

sudo apt update
sudo apt install -y redis-server php-redis
sudo systemctl enable --now redis-server
redis-cli ping

redis-cli ping को PONG का उत्तर देना चाहिए। यदि यह Could not connect to Redis at 127.0.0.1:6379: Connection refused प्रिंट करता है, तो सर्वर नहीं चल रहा है, इसलिए आगे बढ़ने से पहले systemctl status redis-server पढ़ें।

php-redis, PECL से प्राप्त C extension, PhpRedis है। यह Predis (जो शुद्ध PHP है) की तुलना में तेज़ है, और जब यह मौजूद होता है तो प्लगइन स्वचालित रूप से इसका उपयोग करता है। PHP-FPM शुरू होने पर extensions लोड करता है, इसलिए कोई भी नई extension तब तक दिखाई नहीं देती जब तक आप pool को रीस्टार्ट नहीं करते।

sudo systemctl restart php8.3-fpm
php -m | grep redis

उस अंतिम जाँच के साथ सावधान रहें: php -m कमांड लाइन PHP के मॉड्यूल्स की सूची देता है, और FPM एक अलग सेट लोड कर सकता है। जो जाँच मायने रखती है वह प्लगइन का अपना डायग्नोस्टिक्स है, जो आगे दिया गया है।

अगस्त 2026 तक, Ubuntu 24.04 में Redis 7.0.15 पैकेज उपलब्ध है, जो ऑब्जेक्ट कैश के लिए पर्याप्त है। यदि आप इसके बजाय वर्तमान रिलीज़ चाहते हैं, तो Redis अपना स्वयं का APT रिपॉजिटरी प्रकाशित करता है।

sudo apt install -y lsb-release curl gpg
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list
sudo apt update
sudo apt install -y redis

यदि आपका डिस्ट्रिब्यूशन Valkey प्रदान करता है (जो 2024 के लाइसेंस परिवर्तन के बाद शुरू हुआ एक फोर्क है), तो यह उसी प्रोटोकॉल का उपयोग करता है और नीचे दी गई सभी बातें बिना किसी बदलाव के लागू होती हैं।

Redis को bind करें ताकि कोई अन्य इसे access न कर सके

Redis में डिफ़ॉल्ट रूप से कोई पासवर्ड नहीं होता है। जो भी port 6379 पर connection खोल सकता है, वह हर cached value को पढ़ सकता है और FLUSHALL चला सकता है। इंटरनेट पर expose किए गए instances कुछ ही घंटों में scanners द्वारा खोज लिए जाते हैं, इसलिए network setting को tuning से पहले करना आवश्यक है।

/etc/redis/redis.conf खोलें और इन पंक्तियों की पुष्टि करें:

bind 127.0.0.1 -::1
protected-mode yes

इसके बाद जाँचें कि वास्तव में क्या listen कर रहा है, क्योंकि configuration file केवल एक दावा है और ss प्रमाण है।

sudo ss -lntp | grep 6379

आपको 127.0.0.1:6379 की आवश्यकता है। 0.0.0.0:6379 का अर्थ है कि Redis public interface पर जवाब दे रहा है: bind पंक्ति को ठीक करें और restart करें।

जब PHP और Redis एक ही box पर हों, तो loopback TCP की तुलना में Unix socket बेहतर होता है। इसमें path में कोई TCP stack नहीं होता है, और access का निर्णय firewall rule के बजाय file permissions द्वारा लिया जाता है, जिसे आप बाद में बदल सकते हैं।

unixsocket /run/redis/redis-server.sock
unixsocketperm 770

Socket का स्वामित्व redis user और group के पास होता है, इसलिए web user को उस group में शामिल होना होगा।

sudo systemctl restart redis-server
sudo usermod -aG redis www-data
sudo systemctl restart php8.3-fpm
redis-cli -s /run/redis/redis-server.sock ping

इसे PONG प्रिंट करना चाहिए। Could not connect to Redis at /run/redis/redis-server.sock: Permission denied का अर्थ है कि group प्रभावी नहीं हुआ है। id www-data की जाँच करें, और याद रखें कि एक चल रहा PHP-FPM उन groups को बनाए रखता है जो start के समय थे, इसीलिए सूची में restart शामिल है। TCP को तब तक enabled रहने दें जब तक socket सिद्ध न हो जाए, अन्यथा एक typo दोनों paths को एक साथ बंद कर सकता है।

Redis को कितनी मेमोरी मिलनी चाहिए?

अपने सर्वर के आधार पर यह संख्या निर्धारित करें। बिना maxmemory वाला Redis तब तक बढ़ता रहता है जब तक kernel की मेमोरी खत्म न हो जाए और OOM killer किसी process को बंद न कर दे। आमतौर पर यह सबसे बड़ी process होती है, जो WordPress सर्वर पर अक्सर MySQL होती है। journalctl -k | grep -i "out of memory" इस प्रक्रिया के बाद उस termination को दिखाता है, और तब तक साइट डाउन हो चुकी होती है।

कुल RAM से शुरुआत करें और बाकी चीजों को घटाएं। MySQL या MariaDB innodb_buffer_pool_size और प्रति-connection buffers आरक्षित करता है। PHP-FPM की लागत pm.max_children होती है, जिसे एक worker के वास्तविक resident size (आमतौर पर एक भारी plugin वाली साइट पर 64 MB से 128 MB) से गुणा किया जाता है। Kernel और वेब सर्वर को कुछ सौ मेगाबाइट की आवश्यकता होती है। जो बचता है वह आपकी सीमा है, और Redis को उसका एक हिस्सा मिलता है।

अब अनुमान लगाने के बजाय मापें। एक दिन के वास्तविक traffic के बाद:

redis-cli info memory | grep -E 'used_memory_human|maxmemory_human|maxmemory_policy'
redis-cli dbsize

यदि used_memory_human आपकी सीमा से काफी नीचे रहता है, तो सीमा को कम करें और वह RAM MySQL को वापस दे दें, जो इसका बेहतर उपयोग करेगा। यदि यह सीमा पर स्थिर रहता है और evicted_keys पूरे दिन बढ़ता रहता है, तो इसे बढ़ाएं। मान को /etc/redis/redis.conf में सेट करें।

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb अभी लागू होता है और अगले restart पर भूल दिया जाता है, जो एक साधारण sysctl -w की तरह ही एक जाल है। फाइल को edit करें, फिर sudo systemctl restart redis-server करें, और फिर मान को वापस पढ़ें। दूसरी सुरक्षा दीवार रखना फायदेमंद है: systemd unit पर MemoryMax cap एक गलत कॉन्फ़िगर किए गए Redis को सर्वर डाउन करने से रोकता है। इसे maxmemory से ऊपर सेट करें, कभी भी इसके बराबर न रखें, क्योंकि cgroup सीमा किसी key को हटाने के बजाय process को ही मार देती है। यदि Redis WordPress के साथ container में चलता है, तो वही आंकड़ा आपके Compose file में memory limits में होना चाहिए, और वही तर्क डेटाबेस को Docker में या host पर चलाने के निर्णय को निर्धारित करता है।

इविक्शन पॉलिसी का चयन सोच-समझकर करें

एक नए Redis में डिफ़ॉल्ट रूप से noeviction सेट होता है। अपनी सेटिंग की जाँच करें:

redis-cli config get maxmemory-policy

noeviction के तहत, एक फुल इंस्टेंस राइट्स (writes) स्वीकार करना बंद कर देता है और यह उत्तर देता है:

(error) OOM command not allowed when used memory > 'maxmemory'.

यह एक लाइन इस गाइड का सबसे खराब फेलियर मोड है, क्योंकि साइट पूरी तरह डाउन नहीं होती। यह धीमी हो जाती है। हर कैश राइट विफल हो जाता है, इसलिए WordPress वैल्यू के लिए वापस डेटाबेस पर जाता है, फिर अगली रिक्वेस्ट पर इसे स्टोर करने की कोशिश करता है और फिर विफल हो जाता है। अब साइट को अपने मूल डेटाबेस के सभी काम के साथ-साथ हर की (key) के लिए Redis तक एक राउंड ट्रिप का खर्च भी उठाना पड़ता है। WordPress एडमिन में कहीं भी यह नहीं दिखता कि ऐसा हो रहा है। यह स्ट्रिंग PHP एरर लॉग में दिखाई देती है, इसलिए जब कैश जोड़ने के बाद साइट धीमी हो जाए, तो OOM command not allowed के लिए grep करें।

allkeys-lru यहाँ सही डिफ़ॉल्ट है। जब मेमोरी कम होती है, तो Redis सबसे कम उपयोग की गई की (least recently used key) को हटा देता है, जो कि एक ऑब्जेक्ट कैश के लिए बिल्कुल सही है, क्योंकि इसमें मौजूद हर वैल्यू उस डेटा की एक कॉपी है जो MySQL में पहले से मौजूद है। एक की खोने का मतलब है एक अतिरिक्त क्वेरी। राइट को अस्वीकार करने का मतलब है हर रिक्वेस्ट पर, हर क्वेरी का विफल होना, जब तक कि कोई इस पर ध्यान न दे।

इस काम के लिए volatile-* नीतियों से बचें। वे केवल उन कीज़ पर विचार करती हैं जिनमें एक्सपायरी होती है, और Redis के दस्तावेज़ों के अनुसार जब किसी की में एक्सपायरी नहीं होती, तो वे noeviction की तरह व्यवहार करती हैं। WordPress अधिकांश ऑब्जेक्ट कैश प्रविष्टियों को बिना TTL के स्टोर करता है, इसलिए ऑब्जेक्ट कैश पर volatile-lru का उपयोग करने से मेमोरी भर सकती है और यह राइट्स को अस्वीकार करना शुरू कर सकता है। यदि आपका ट्रैफिक अक्सर कीज़ के एक छोटे सेट को हिट करता है, तो allkeys-lfu एक उचित विकल्प है, क्योंकि यह हालिया उपयोग के बजाय आवृत्ति (frequency) के आधार पर कीज़ को हटाता है। एक पॉलिसी को सोच-समझकर चुनें और उसका कारण कहीं लिख लें।

Persistence: इसे बंद रखें जब तक आपके पास कोई ठोस कारण न हो

पैकेज्ड redis.conf में save 900 1 जैसी लाइनों के साथ RDB स्नैपशॉट सक्षम होते हैं, और append-only फ़ाइल बंद रहती है। एक शुद्ध ऑब्जेक्ट कैश के लिए, स्नैपशॉट से कोई लाभ नहीं होता है। डेटा परिभाषा के अनुसार पुन: उत्पन्न करने योग्य (regenerable) होता है, और बीस मिनट पुरानी फ़ाइल से रिस्टोर किया गया कैश पुराने मानों का एक सेट होता है जिस पर WordPress भरोसा करेगा।

स्नैपशॉट की एक कीमत भी होती है। BGSAVE प्रक्रिया को fork करता है, और copy-on-write का मतलब है कि जब child प्रक्रिया लिख रही होती है, तो मेमोरी का उपयोग तेजी से बढ़ सकता है। एक छोटे VPS पर यह Redis लॉग में इस तरह दिखाई देता है:

Can't save in background: fork: Cannot allocate memory

और स्टार्टअप पर अक्सर यह चेतावनी दिखाई देती है, जो यह बताती है कि Redis के अनुसार भविष्य में fork विफल होने की संभावना है:

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition.

स्नैपशॉट बंद करने के लिए, /etc/redis/redis.conf में एक खाली save शेड्यूल सेट करें, रीस्टार्ट करें, और पुष्टि करें कि मान खाली हो गया है।

save ""

sudo systemctl restart redis-server
redis-cli config get save

Persistence केवल तभी रखें यदि उसी इंस्टेंस में कुछ ऐसा हो जिसे आप दोबारा नहीं बना सकते, जैसे कि जॉब क्यू (job queue) या रेट-लिमिट काउंटर। उस स्थिति में दोनों को अलग कर दें। कैश चाहता है कि कीज़ (keys) को हटा दिया जाए (evicted) और टिकाऊ डेटा चाहता है कि कीज़ बनी रहें, और maxmemory के साथ eviction पूरे इंस्टेंस पर लागू होता है, न कि किसी एक डेटाबेस इंडेक्स पर। दो सॉकेट्स पर दो इंस्टेंस चलाना ही इसका सही समाधान है।

प्लगइन इंस्टॉल करें और ड्रॉप-इन को समझें

wp plugin install redis-cache --activate
wp redis enable
wp redis status

wp redis enable सफल होने पर Object cache enabled. प्रिंट करता है। यह वास्तव में wp-content/plugins/redis-cache/includes/object-cache.php को wp-content/object-cache.php पर कॉपी करता है। वह कॉपी ही ड्रॉप-इन है, और ड्रॉप-इन ही वह हिस्सा है जो काम करता है। WordPress wp-content/object-cache.php को बहुत जल्दी लोड करता है, किसी भी प्लगइन कोड के चलने से पहले, यही कारण है कि कैश पूरे रिक्वेस्ट के लिए उपलब्ध रहता है। बिना ड्रॉप-इन वाला सक्रिय प्लगइन कुछ भी कैश नहीं करता है।

विफलता के संदेश आपको बताते हैं कि कौन सा हिस्सा टूटा है। Object cache could not be enabled. का मतलब है कि कॉपी विफल रही, इसलिए wp-content उस यूजर के लिए राइटेबल नहीं है जो WP-CLI चला रहा है। A foreign object cache drop-in was found. का मतलब है कि कोई अन्य कैशिंग प्लगइन पहले से ही उस फाइलनाम का उपयोग कर रहा है, और इसका समाधान wp redis update-dropin है। Redis server is unreachable: पर समाप्त होने वाला संदेश और उसके बाद क्लाइंट एरर का मतलब है कि कनेक्शन सेटिंग्स गलत हैं, इसलिए redis-cli ping पर वापस जाएं।

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

cp wp-content/plugins/redis-cache/includes/object-cache.php wp-content/object-cache.php
sudo chown www-data:www-data wp-content/object-cache.php

प्लगइन को हटाने से ड्रॉप-इन नहीं हटता है। पहले wp redis disable चलाएं, जो Object cache disabled. प्रिंट करता है और फाइल को डिलीट कर देता है। यदि आप प्लगइन डायरेक्टरी को डिलीट कर देते हैं जबकि ड्रॉप-इन वहीं रह जाता है, तो साइट बिना किसी प्लगइन अपडेट के पुराने कैश कोड को चलाती रहेगी।

wp-config.php में कनेक्शन सेटिंग्स

इन्हें उस लाइन के ऊपर जोड़ें जो /* That's all, stop editing! */ पढ़ती है, क्योंकि उसके बाद परिभाषित constants बहुत देर से लोड होते हैं।

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

Unix socket के लिए, scheme और path सेट करें। इसके बाद host और port को अनदेखा कर दिया जाता है।

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/run/redis/redis-server.sock' );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

WP_REDIS_MAXTTL हर key पर एक expiry लागू करता है, जिसे seconds में मापा जाता है। आपको allkeys-lru के साथ इसकी आवश्यकता नहीं है, और यह तब उपयोगी होता है जब आप यह सुनिश्चित करना चाहते हैं कि cached value अधिक से अधिक कितनी पुरानी हो सकती है।

एक Redis, कई साइटें: prefixes और databases

Redis डिफ़ॉल्ट रूप से सोलह क्रमांकित databases प्रदान करता है, और प्रत्येक के भीतर एक flat keyspace होती है। यदि दो WordPress इंस्टॉलेशन बिना किसी prefix के database 0 पर पॉइंट किए गए हैं, तो वे एक ही space में समान key names लिखते हैं। इससे एक साइट दूसरी साइट के options को पढ़ सकती है और उन्हें सर्व कर सकती है। प्रत्येक साइट को अपना एक अलग prefix दें।

define( 'WP_REDIS_PREFIX', 'shopA_prod:' );
define( 'WP_REDIS_DATABASE', 1 );

Prefix key names को अलग करता है। Database index keyspaces को अलग करता है, जो flush करते समय महत्वपूर्ण होता है: एक index को खाली करने से अन्य प्रभावित नहीं होते हैं। प्लगइन WP_REDIS_SELECTIVE_FLUSH का भी उल्लेख करता है, जो पूरे database को खाली करने के बजाय केवल आपके prefix से मेल खाने वाली keys को हटाता है, हालांकि इसके लिए keys को स्कैन करना पड़ता है।

Prefixes और indexes जो अलग नहीं करते, वह है memory। maxmemory और eviction policy पूरे instance पर लागू होते हैं। इसलिए, एक व्यस्त साइट एक शांत साइट की keys को बाहर (evict) कर सकती है और किसी को भी इसकी सूचना नहीं मिलती है। जिन साइटों का एक-दूसरे पर प्रभाव पड़ना वर्जित है, उन्हें अलग Redis instances की आवश्यकता होती है, जिनमें से प्रत्येक का अपना socket और अपनी limit होनी चाहिए।

Staging को production के cache से अलग रखें

Staging साइट आमतौर पर production की फाइलों और database की एक प्रति होती है, जिसका अर्थ है कि यह wp-config.php की एक प्रति है जिसमें वही prefix और वही database index होता है। यदि आप इसे उसी Redis की ओर point करते हैं, तो यह staging values के साथ production की keys को overwrite कर देता है। इसके परिणामस्वरूप, बिना किसी deploy या trace के live site पर test price या बदला हुआ option दिखाई देने लगता है।

प्रत्येक environment के लिए मैन्युअल रूप से salt सेट करें। Staging की wp-config.php में यह करें:

define( 'WP_REDIS_PREFIX', 'shop_staging:' );
define( 'WP_REDIS_DATABASE', 5 );

इससे भी बेहतर यह है कि staging को उसका अपना Redis instance दें, या object cache का उपयोग न करें। define( 'WP_REDIS_DISABLED', true ); runtime पर cache को बंद कर देता है और drop-in को अपनी जगह रहने देता है, जो यह साबित करने का सबसे तेज़ तरीका है कि कोई bug cache के कारण है या नहीं।

पुराने tutorials इसके लिए WP_CACHE_KEY_SALT सेट करने का सुझाव देते हैं। Plugin के readme में उस constant को deprecated बताया गया है और उसे WP_REDIS_PREFIX से बदल दिया गया है, इसलिए नए नाम का ही उपयोग करें।

विश्वास करने के बजाय इसकी पुष्टि करें

प्लगइन के अपने डायग्नोस्टिक्स से शुरुआत करें।

wp redis status

सबसे महत्वपूर्ण लाइन Drop-in है। Drop-in: Valid का अर्थ है कि WordPress इस प्लगइन की फाइल को लोड कर रहा है। Drop-in: Not installed का अर्थ है कि कॉपी कभी नहीं हुई और साइट में कोई persistent cache नहीं है, भले ही एडमिन स्क्रीन कितनी भी हरी (green) क्यों न दिखे। Status कनेक्शन की रिपोर्ट देता है, और Client उपयोग में आने वाले एक्सटेंशन का नाम बताता है, जहाँ से आप यह पुष्टि करते हैं कि यह Predis के बजाय PhpRedis है।

फिर सीधे WordPress कोर से पूछें, क्योंकि उसे इस बात से कोई फर्क नहीं पड़ता कि प्लगइन क्या सोचता है।

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) का अर्थ है कि कोर एक बाहरी ऑब्जेक्ट कैश (external object cache) से बात कर रहा है।

फिर साबित करें कि आपके द्वारा कॉन्फ़िगर किए गए प्रीफ़िक्स के साथ कीज़ (keys) आ रही हैं।

redis-cli -n 0 dbsize
redis-cli -n 0 --scan --pattern 'shop_prod:*' | head

जब आप साइट पर क्लिक करते हैं, तो dbsize का बढ़ना ही इसका प्रमाण है। एक वैध ड्रॉप-इन के साथ शून्य कीज़ का मतलब है कि कनेक्शन चुपचाप विफल हो रहा है, या प्रीफ़िक्स वह नहीं है जो आप सोच रहे हैं।

अंत में, देखें कि Redis आपके लिए क्या मापता है।

redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses|evicted_keys|expired_keys'

हिट रेशियो keyspace_hits / (keyspace_hits + keyspace_misses) है, और Redis का डॉक्यूमेंटेशन वह फॉर्मूला देता है। इसे दो सावधानियों के साथ पढ़ें। काउंटर अंतिम रीस्टार्ट के बाद से पूरे इंस्टेंस को कवर करते हैं, इसलिए वे इसे साझा करने वाली हर साइट और हर एप्लिकेशन को मिला देते हैं। और फ्लश या रीस्टार्ट के ठीक बाद का रेशियो कोई मायने नहीं रखता, क्योंकि कैश अभी भी भर रहा होता है। इसे सामान्य ट्रैफ़िक वाले दिन चलने दें।

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

curl -o /dev/null -s -w '%{time_starttransfer}\n' -b cookies.txt https://example.com/my-account/

इसे लॉग-इन कुकी जार के साथ, कई बार, कैश बंद (WP_REDIS_DISABLED) करके और फिर चालू करके चलाएं। वह अंतर ही आपका परिणाम है।

जब Redis, WordPress को धीमा कर देता है

गलत policy वाला एक पूर्ण instance इसका मुख्य कारण है, जिसे ऊपर कवर किया गया है: log में OOM command not allowed when used memory > 'maxmemory'., और एक ऐसी साइट जो database और cache दोनों के लिए भुगतान कर रही है।

दूसरे host पर Redis का होना दूसरा कारण है। WordPress एक request में सैकड़ों object cache calls करता है। यदि एक request 500 calls करती है और प्रत्येक round trip में 1 ms का समय लगता है, तो यह आधा सेकंड का इंतजार है जो local socket के साथ नहीं होता। Redis को उसी box पर रखें, या sub-millisecond latency वाले private network पर रखें।

एक विशाल autoloaded options table तीसरा कारण है, और यह पुरानी साइटों पर आम है। WordPress सभी autoloaded options को एक ही key के रूप में cache करता है, इसलिए हर एक request पर इनका एक megabyte डेटा connection से होकर गुजरता है। इसे मापें:

wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024) AS kb FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');"

WordPress 6.6 ने नए autoload values जोड़े हैं, इसलिए केवल 'yes' से मेल खाने वाली पुरानी query आधुनिक install पर कम रिपोर्ट करती है। एक megabyte से अधिक का कोई भी डेटा options table में ठीक करने की समस्या है, न कि Redis में।

Restart करने से सब कुछ खाली हो जाता है, इसलिए systemctl restart redis-server के बाद के मिनटों में सभी misses होते हैं और सारा काम database पर होता है। जब traffic कम हो तब restart करें। और एक object cache visitor page loads पर wp-cron.php को चलने से नहीं रोकता है, जो स्वयं धीमी requests का एक स्रोत है: WP-Cron को एक वास्तविक system cron job पर ले जाएं जब आप यहाँ हों।

Housekeeping

जब भी आप options या theme code बदलते हैं, तो deploy के बाद wp cache flush का उपयोग करके cache को flush करें। यदि plugin update के बाद drop-in खुद update नहीं हुआ है, तो wp redis update-dropin चलाएं, क्योंकि पुराने plugin version का drop-in नए version के साथ काम करने पर अजीब व्यवहार (odd behaviour) पैदा कर सकता है। redis-cli --stat के साथ live server पर नज़र रखें, जो प्रति सेकंड एक line print करता है। redis-cli monitor हर command को print करता है और व्यस्त instance पर काफी CPU consume करता है, इसलिए इसे केवल कुछ सेकंड के लिए ही चलाएं जब आप किसी समस्या को reproduce कर रहे हों, उसके बाद इसे बंद कर दें।

एक आखिरी संख्या जिसे जानना उपयोगी है: redis-cli info clients, connected_clients की रिपोर्ट देता है। PHP-FPM प्रति worker एक connection रखता है, इसलिए यह संख्या आपके pm.max_children के अनुरूप होनी चाहिए और उससे बहुत अधिक नहीं होनी चाहिए। यदि ऐसा है, तो इसका मतलब है कि कोई प्रक्रिया connections खोल रही है और उन्हें बंद नहीं कर रही है।

FAQ

क्या Redis object cache चलाने पर भी मुझे page cache की आवश्यकता है?

हाँ, anonymous traffic के लिए। Page cache PHP चलाए बिना ही stored HTML को serve करता है, जो कि warm object cache के साथ WordPress चलाने की तुलना में हमेशा सस्ता होता है। Object cache उन requests को संभालता है जिन्हें page cache को छोड़ना पड़ता है: जैसे logged-in users, carts, checkout, और wp-admin। Shop या membership site पर दोनों को चलाना फायदेमंद होता है। ऐसी साइट पर जहाँ visitors कभी login नहीं करते, page cache लगभग सारा काम कर देता है।

WordPress के लिए Redis को कितनी memory देनी चाहिए?

किसी आंकड़े की नकल करने के बजाय इसे अपने server के आधार पर तय करें। कुल RAM लें, उसमें से MySQL buffer pool और per-connection buffers को घटाएं, pm.max_children को एक PHP-FPM worker के resident size से गुणा करके घटाएं, और kernel व web server के लिए कुछ सौ megabytes अलग रखें। जो बचे, उसका एक हिस्सा Redis को दें, फिर एक दिन के traffic के बाद redis-cli info memory में used_memory_human की जाँच करें और उसे adjust करें। एक सामान्य WordPress site आमतौर पर कुछ tens of megabytes में ही काम कर लेती है, इसलिए 4 GB server पर 256 MB maxmemory एक अच्छी शुरुआत है।

Redis object cache enable करने के बाद मेरी साइट धीमी क्यों हो गई?

इसका सामान्य कारण यह है कि instance भर चुका है और noeviction policy लागू है। Redis नए writes को मना कर देता है और OOM command not allowed when used memory > 'maxmemory'. return करता है, इसलिए WordPress हर value के लिए database पर निर्भर हो जाता है और ऊपर से एक बेकार Redis round trip का समय भी खर्च होता है। redis-cli config get maxmemory-policy की जाँच करें, allkeys-lru set करें, और सुनिश्चित करें कि maxmemory बहुत छोटा न हो। अन्य सामान्य कारण हैं: remote host पर Redis server होना, जहाँ प्रति request सैकड़ों round trips का समय जुड़ जाता है, या multi-megabyte की autoloaded options value जो हर request पर connection से होकर गुजरती है।

क्या कई WordPress sites एक ही Redis server साझा कर सकती हैं?

वे ऐसा कर सकती हैं, लेकिन सावधानी के साथ। हर site को एक unique WP_REDIS_PREFIX दें ताकि key names आपस में न टकराएं, और एक अलग WP_REDIS_DATABASE index दें ताकि एक site को flush करने पर दूसरी खाली न हो जाए। जो वे अभी भी साझा करती हैं, वह है memory: maxmemory और eviction पूरे instance पर लागू होते हैं, इसलिए एक busy site, quiet site की keys को evict कर सकती है। जिन sites को एक-दूसरे को प्रभावित नहीं करना चाहिए, उन्हें अपने अलग limits वाले अलग Redis instances की आवश्यकता होती है।

क्या wp-content/object-cache.php को delete करना सुरक्षित है?

हाँ। यह एक drop-in है, WordPress core का हिस्सा नहीं है, और इसे हटाने पर WordPress अपने built-in per-request cache पर वापस आ जाता है। साइट काम करती रहती है और बस अधिक database queries करती है। wp redis disable का उपयोग करना बेहतर है, जो file को सफाई से हटाता है और Object cache disabled. report करता है। यदि Redis down है या ठीक से काम नहीं कर रहा है और आप admin तक नहीं पहुँच पा रहे हैं, तो इसे हाथ से delete करना एक सही emergency कदम है।