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 web user के लिए लिखे गए हैं। अपनी मशीन के अनुसार PHP version और user को समायोजित करें। wp commands को अपनी WordPress directory से चलाएँ, जिसमें 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 से तेज़ है, जो कि pure 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 पैकेज है, जो object cache के लिए उपयुक्त है। यदि आप इसके बजाय वर्तमान release चाहते हैं, तो 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 के लाइसेंस परिवर्तन के बाद शुरू किया गया fork है, तो यह उसी प्रोटोकॉल का उपयोग करता है और नीचे दी गई सभी बातें बिना किसी बदलाव के लागू होती हैं।

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

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

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

bind 127.0.0.1 -::1
protected-mode yes

फिर जाँचें कि वास्तव में क्या listen कर रहा है, क्योंकि कॉन्फ़िगरेशन फ़ाइल केवल एक दावा है और ss प्रमाण है।

sudo ss -lntp | grep 6379

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

जब PHP और Redis एक ही सर्वर पर हों, तो loopback TCP की तुलना में Unix socket बेहतर होता है। इसमें पाथ में कोई TCP stack नहीं होता है, और एक्सेस का निर्णय 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 को बनाए रखता है जो उसके शुरू होने के समय थे, इसीलिए restart सूची में है। TCP को तब तक enabled रहने दें जब तक socket सिद्ध न हो जाए, अन्यथा एक टाइपो दोनों रास्तों को एक साथ बंद कर सकता है।

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

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

कुल RAM से शुरुआत करें और बाकी सेवाओं की खपत घटाएं। MySQL या MariaDB innodb_buffer_pool_size और प्रति-कनेक्शन बफ़र्स आरक्षित करते हैं। PHP-FPM की लागत pm.max_children को एक वर्कर के वास्तविक resident size से गुणा करने पर निकलती है, जो प्लगइन-युक्त साइटों पर आमतौर पर 64 MB से 128 MB होती है। Kernel और वेब सर्वर को कुछ सौ मेगाबाइट की आवश्यकता होती है। जो बचता है वह आपकी अधिकतम सीमा है, और Redis को उसका एक हिस्सा मिलता है।

अब अनुमान लगाने के बजाय मापें। एक दिन के वास्तविक ट्रैफ़िक के बाद:

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 तुरंत लागू होता है और अगले रीस्टार्ट पर हट जाता है, जो कि एक साधारण sysctl -w के समान ही एक जाल है। फ़ाइल को एडिट करें, फिर sudo systemctl restart redis-server करें, और फिर मान को दोबारा पढ़ें। एक दूसरी सुरक्षा दीवार रखना फायदेमंद है: systemd यूनिट पर MemoryMax कैप गलत कॉन्फ़िगर किए गए Redis को सर्वर डाउन करने से रोकता है। इसे maxmemory से ऊपर सेट करें, कभी भी इसके बराबर न रखें, क्योंकि cgroup सीमा किसी की (key) को हटाने के बजाय प्रक्रिया को ही खत्म कर देती है। यदि Redis WordPress के साथ एक कंटेनर में चलता है, तो यही आंकड़ा आपके Compose फ़ाइल में मेमोरी लिमिट में होना चाहिए, और यही तर्क डेटाबेस को Docker में या होस्ट पर चलाने के निर्णय को निर्धारित करता है।

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

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

redis-cli config get maxmemory-policy

noeviction के तहत, एक पूर्ण instance writes स्वीकार करना बंद कर देता है और यह उत्तर देता है:

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

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

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

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

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

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

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

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

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

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

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

save ""

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

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

Plugin install करें और drop-in को समझें

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 पर कॉपी करता है। वह कॉपी ही drop-in है, और यही वह हिस्सा है जो काम करता है। WordPress, wp-content/object-cache.php को बहुत जल्दी लोड कर लेता है, किसी भी plugin code के चलने से पहले, और इसी तरह cache पूरे request के लिए उपलब्ध रहता है। यदि कोई active plugin है लेकिन drop-in मौजूद नहीं है, तो कुछ भी cache नहीं होगा।

Failure messages आपको बताते हैं कि कौन सा हिस्सा टूटा है। Object cache could not be enabled. का मतलब है कि copy विफल रही, क्योंकि WP-CLI चलाने वाले user के पास wp-content पर लिखने की अनुमति (write permission) नहीं है। A foreign object cache drop-in was found. का मतलब है कि कोई अन्य caching plugin पहले से ही उस filename का उपयोग कर रहा है, और इसका समाधान wp redis update-dropin है। यदि कोई message Redis server is unreachable: पर समाप्त होता है और उसके बाद client error आता है, तो इसका मतलब है कि connection settings गलत हैं, इसलिए redis-cli ping पर वापस जाएँ।

यदि permissions के कारण copy विफल रही है, तो इसे मैन्युअल रूप से रखें और web user को इसका स्वामित्व (ownership) दें।

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

Plugin को हटाने से drop-in नहीं हटता है। पहले wp redis disable चलाएँ, जो Object cache disabled. प्रिंट करता है और file को delete कर देता है। यदि आप drop-in को पीछे छोड़कर plugin directory को delete कर देते हैं, तो site बिना किसी update mechanism के पुराने cache code को ही चलाती रहेगी।

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 लागू करता है। आपको allkeys-lru के साथ इसकी आवश्यकता नहीं है, और यह तब उपयोगी होता है जब आप यह सुनिश्चित करना चाहते हैं कि cached value कितनी पुरानी हो सकती है, इसकी एक अधिकतम सीमा तय हो।

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

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

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

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

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

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

Staging site आमतौर पर production की फाइलों और database की एक प्रति होती है, जिसका अर्थ है कि यह wp-config.php की एक प्रति है जिसमें समान prefix और समान database index का उपयोग होता है। यदि आप इसे उसी Redis से जोड़ते हैं, तो यह 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 नहीं है, भले ही एडमिन स्क्रीन कितनी भी हरी-भरी क्यों न दिखे। Status कनेक्शन की रिपोर्ट देता है, और Client उपयोग किए जा रहे एक्सटेंशन का नाम बताता है, जहाँ आप Predis के बजाय PhpRedis की पुष्टि करते हैं।

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

wp eval 'var_dump( wp_using_ext_object_cache() );'

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

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

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

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

अंत में, देखें कि 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 सबसे बड़ी समस्या है, जिसका उल्लेख ऊपर किया गया है: लॉग में OOM command not allowed when used memory > 'maxmemory'., और एक ऐसी साइट जो डेटाबेस और कैश दोनों के लिए भुगतान कर रही है।

किसी अन्य host पर Redis का होना दूसरी समस्या है। WordPress एक request में सैकड़ों object cache calls करता है। यदि एक request 500 calls करती है और प्रत्येक round trip में 1 ms का समय लगता है, तो यह आधा सेकंड का इंतजार है जो local socket के साथ नहीं होता। Redis को उसी box पर रखें, या sub-millisecond latency वाले private network पर रखें। same-box स्थिति में kernel से कितना लाभ मिलता है, यह एक अलग प्रश्न है: Linux 7.2 में जोड़ा गया cache aware scheduling PHP-FPM और Redis जैसी अधिक बातचीत करने वाली processes को उन cores पर रखने का प्रयास करता है जो cache साझा करते हैं, और एक VPS guest को bare metal की तुलना में इसका लाभ कम मिलता है।

एक विशाल autoloaded options table तीसरी समस्या है, और यह पुरानी साइटों पर आम है। WordPress सभी autoloaded options को एक key के रूप में cache करता है, इसलिए हर single 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 और डेटाबेस के काम के होते हैं। जब traffic कम हो, तब restart करें। और एक object cache visitor page loads पर wp-cron.php को चलने से नहीं रोकता, जो स्वयं धीमी requests का एक स्रोत है: जब आप यहाँ हों, तो WP-Cron को एक वास्तविक system cron job पर ले जाएँ।

Housekeeping

जब आप कोई ऐसा deploy करें जिससे options या theme code बदलता हो, तो wp cache flush के साथ cache flush करें। यदि plugin update के बाद drop-in खुद update न हो, तो wp redis update-dropin चलाएं, क्योंकि पुराने plugin version का drop-in नए plugin के साथ चलने पर अजीब व्यवहार (odd behaviour) पैदा कर सकता है। redis-cli --stat के साथ live server को monitor करें, जो प्रति सेकंड एक line print करता है। redis-cli monitor हर command को print करता है और busy 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 प्रदान करता है, जो कि 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 देनी चाहिए?

किसी अन्य के आँकड़ों की नकल करने के बजाय अपने सर्वर के अनुसार निर्णय लें। कुल 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 की जाँच करें और तदनुसार बदलाव करें। एक सामान्य WordPress site आमतौर पर कुछ दसियों megabytes में काम कर लेती है, इसलिए 4 GB के सर्वर पर 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 सेट करें, और सुनिश्चित करें कि maxmemory बहुत छोटा न हो। अन्य सामान्य कारणों में remote host पर स्थित Redis server शामिल है, जहाँ प्रति request सैकड़ों round trips का समय जुड़ जाता है, या फिर multi-megabyte की autoloaded options value जो हर request पर connection के माध्यम से transfer होती है।

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

हाँ, सावधानी के साथ। प्रत्येक site को एक unique WP_REDIS_PREFIX दें ताकि key names आपस में न टकराएं, और एक अलग WP_REDIS_DATABASE index दें ताकि एक site को flush करने पर दूसरी खाली न हो जाए। वे अभी भी memory साझा करती हैं: maxmemory और eviction पूरी instance पर लागू होते हैं, इसलिए एक busy site किसी शांत 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 panel तक नहीं पहुँच पा रहे हैं, तो इसे हाथ से delete करना एक सही emergency कदम है।