VPS वरील WordPress साठी Redis object cache सेटअप

WordPress साठी Redis object cache काय करते

WordPress साठी Redis object cache database queries चे निकाल memory मध्ये साठवते. त्यामुळे पुढील request वेळी MySQL कडे पुन्हा विचारण्याऐवजी Redis मधून ते निकाल वाचले जातात. WordPress मध्ये core मध्येच object cache उपलब्ध आहे, WP_Object_Cache, पण तो PHP memory मध्ये असतो आणि request संपताच नष्ट होतो. Drop-in file त्या cache ची जागा घेते आणि Redis शी संवाद साधणारी cache उपलब्ध करते. त्यामुळे एका request नंतरही cache पुढील request साठी टिकून राहते.

Object caching आणि page caching एकसारखे नाहीत. हा फरक समजल्यावर हे मार्गदर्शक तुमच्यासाठी उपयुक्त आहे की नाही ते ठरते. Page cache एखाद्या URL चे तयार HTML साठवते आणि PHP अजिबात चालविल्याशिवाय ते पुन्हा देते. Redis करू शकणाऱ्या कोणत्याही प्रक्रियेपेक्षा हे जलद असते. Login न केलेल्या visitors साठीही ते कार्य करते. एखादी व्यक्ती login करते, cart मध्ये item ठेवते किंवा admin उघडते, त्या क्षणी page cache बाजूला होते आणि WordPress पूर्ण request चालवते: bootstrap, plugins, queries. Object cache त्या request चा खर्च कमी करते. Page cache ज्या traffic ला हाताळू शकत नाही, त्यासाठी हे साधन आहे: logged-in sessions, carts, checkout, wp-admin. WooCommerce shop मध्ये महागड्या traffic चा बहुतांश भाग हाच असतो.

दोन्ही एकत्र वापरता येतात आणि व्यस्त site वर दोन्ही आवश्यक असतात. तुम्ही कोणती समस्या सोडवत आहात हे स्पष्ट ठेवा. Anonymous readers असलेल्या brochure site ला जवळजवळ पूर्ण speed page cache मुळे मिळते. त्यात Redis जोडल्याने फारसा फरक पडत नाही.

सुरुवात करण्यापूर्वी एक मर्यादा स्पष्टपणे समजून घ्या. Object cache मुळे slow query fast होत नाही. आधी चालवलेल्या query ची पुन्हा होणारी execution ते टाळते. Cache miss झाल्यानंतरची पहिली request पूर्ण खर्च देते. त्यामुळे unindexed query चालवणारा plugin प्रत्येक cache lifetime मध्ये ती query एकदा तरी चालवतो.

तुम्हाला प्रथम काय आवश्यक आहे

• shell आणि sudo असलेला Linux VPS. कोणतेही 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 मधून चालवा. त्या 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 आहे. ते pure PHP असलेल्या Predis पेक्षा जलद आहे. ते उपलब्ध असल्यास plugin ते आपोआप वापरतो. PHP-FPM extensions सुरू होताना लोड करतो. त्यामुळे नवीन extension pool restart करेपर्यंत उपलब्ध होत नाही.

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

शेवटची तपासणी करताना काळजी घ्या: php -m command line PHP चे modules दाखवते. FPM वेगळे modules लोड करू शकते. अंतिम महत्त्वाची तपासणी plugin च्या स्वतःच्या diagnostics मध्ये होते. ती पुढे दिली आहे.

August 2026 पर्यंत Ubuntu 24.04 मध्ये Redis 7.0.15 उपलब्ध आहे. Object cache साठी ही आवृत्ती पुरेशी आहे. त्याऐवजी current release हवी असल्यास, Redis चे स्वतःचे APT repository उपलब्ध आहे.

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

तुमच्या distribution मध्ये Valkey उपलब्ध असल्यास, 2024 मधील licence change नंतर सुरू झालेला हा fork आहे. तो समान protocol वापरतो. त्यामुळे खालील सर्व प्रक्रिया कोणताही बदल न करता लागू होतात.

Redis ला bind करा, जेणेकरून इतर कोणालाही त्याच्यापर्यंत पोहोचता येणार नाही

Redis मध्ये default ने password नसतो. Port 6379 वर connection उघडू शकणारी कोणतीही गोष्ट प्रत्येक cached value वाचू शकते आणि FLUSHALL चालवू शकते. इंटरनेटवर उघड्या असलेल्या instances scanners ना काही तासांत सापडतात. त्यामुळे tuning करण्यापूर्वी network setting सुरक्षित करा.

/etc/redis/redis.conf उघडा आणि या lines ची खात्री करा:

bind 127.0.0.1 -::1
protected-mode yes

यानंतर प्रत्यक्षात काय listening आहे ते तपासा. कारण configuration file मध्ये केलेला दावा वेगळा असू शकतो, तर ss हा प्रत्यक्ष पुरावा देते.

sudo ss -lntp | grep 6379

127.0.0.1:6379 हे अपेक्षित आहे. 0.0.0.0:6379 याचा अर्थ Redis public interface वर responses देत आहे. bind line दुरुस्त करा आणि restart करा.

PHP आणि Redis एकाच box वर असतील, तर loopback TCP पेक्षा Unix socket अधिक योग्य आहे. या मार्गात TCP stack नसतो. तसेच access firewall rule ऐवजी file permissions ठरवतात; firewall rule नंतर बदलला जाऊ शकतो.

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

Socket चा owner आणि group redis user आहे. त्यामुळे 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 देखील print झाले पाहिजे. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied याचा अर्थ group लागू झालेला नाही. id www-data तपासा. तसेच चालू PHP-FPM process सुरू होताना असलेले groups कायम ठेवतो, म्हणून list मध्ये restart दिले आहे हे लक्षात ठेवा. Socket कार्यरत असल्याची खात्री होईपर्यंत TCP enabled ठेवा. अन्यथा एका typo मुळे दोन्ही मार्ग एकाच वेळी बंद होऊ शकतात.

Redis ला किती memory द्यावी?

ही संख्या तुमच्या स्वतःच्या box वरून ठरवा. maxmemory नसल्यास Redis kernel ची memory संपेपर्यंत वाढत राहतो आणि OOM killer एखादी process बंद करतो. बहुतेक वेळा ती सर्वात मोठी process असते. WordPress server वर ती अनेकदा MySQL असते. journalctl -k | grep -i "out of memory" हा process बंद झाल्यानंतरचा पुरावा दाखवतो. तोपर्यंत site बंद झालेली असते.

एकूण RAM पासून आवश्यक memory वजा करून सुरुवात करा. MySQL किंवा MariaDB innodb_buffer_pool_size तसेच प्रत्येक connection साठीचे buffers राखून ठेवते. PHP-FPM साठी pm.max_children ला एका worker च्या प्रत्यक्ष resident size ने गुणा करा. Plugin जास्त असलेल्या site वर हा आकार सामान्यतः 64 MB ते 128 MB असतो. Kernel आणि web server साठी काहीशे megabytes आवश्यक असतात. उरलेली memory तुमची कमाल मर्यादा आहे. त्यातील काही भाग Redis ला द्या.

आता अंदाज न लावता मोजमाप करा. प्रत्यक्ष traffic च्या एका दिवसानंतर:

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

used_memory_human तुमच्या मर्यादेपेक्षा बरीच कमी असल्यास, मर्यादा कमी करा आणि RAM MySQL ला परत द्या. MySQL तिचा अधिक चांगला उपयोग करेल. मर्यादा गाठून स्थिर राहिल्यास आणि evicted_keys दिवसभर वाढत असल्यास, मर्यादा वाढवा. ही value /etc/redis/redis.conf मध्ये सेट करा.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb सध्या लागू होते, पण पुढील restart वेळी विसरले जाते. हा bare sysctl -w सारखाच धोका आहे. File संपादित करा, त्यानंतर sudo systemctl restart redis-server चालवा आणि value पुन्हा वाचा. दुसरी मर्यादा ठेवणे उपयुक्त आहे: systemd unit वर MemoryMax cap misconfigured Redis मुळे संपूर्ण box बंद होण्यापासून रोखते. ती maxmemory पेक्षा जास्त ठेवा; तिच्याइतकीच ठेवू नका. cgroup limit key evict करण्याऐवजी process बंद करते. Redis WordPress च्या शेजारी container मध्ये चालत असल्यास, हीच figure तुमच्या Compose file मधील memory limits मध्ये द्या. तसेच database Docker मध्ये चालवायचा की host वर हा निर्णयही याच कारणमीमांसेवर आधारित असतो.

निष्कासन धोरण जाणीवपूर्वक निवडा

नवीन Redis मध्ये default म्हणून noeviction असते. तुमची सेटिंग तपासा:

redis-cli config get maxmemory-policy

noeviction अंतर्गत instance पूर्ण भरल्यावर write स्वीकारणे थांबवते आणि पुढील संदेश देते:

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

ही एक ओळ या मार्गदर्शकातील सर्वांत गंभीर failure mode दर्शवते, कारण साइट बंद पडत नाही. ती धीमी होते. प्रत्येक cache write अयशस्वी होते. त्यामुळे WordPress त्या value साठी पुन्हा database कडे जाते, पुढील request वर ती पुन्हा साठवण्याचा प्रयत्न करते आणि पुन्हा अपयशी ठरते. आता साइटला तिच्या मूळ database कामाचा संपूर्ण खर्च आणि प्रत्येक key साठी Redis पर्यंतचा एक round trip, दोन्ही सहन करावे लागतात. हे घडत आहे असे WordPress admin मध्ये कुठेही दिसत नाही. हा string PHP error log मध्ये दिसतो. त्यामुळे cache जोडल्यावर साइट धीमी झाल्यास OOM command not allowed साठी grep करा.

allkeys-lru ही येथे योग्य default सेटिंग आहे. Memory कमी पडल्यावर Redis सर्वांत अलीकडे वापरलेली नसलेली key काढून टाकते. Object cache साठी हेच योग्य आहे, कारण त्यातील प्रत्येक value ही MySQL मध्ये अजूनही उपलब्ध असलेल्या data ची copy असते. एक key गमावल्यास एक query चा खर्च होतो. Write नाकारणे म्हणजे कोणी लक्ष देईपर्यंत प्रत्येक request वरील प्रत्येक query चा खर्च वाढणे.

या कामासाठी volatile-* policies टाळा. त्या फक्त expiry असलेल्या keys विचारात घेतात. कोणत्याही key ला expiry नसल्यास त्या noeviction प्रमाणे काम करतात, असे Redis च्या documentation मध्ये नमूद आहे. WordPress बहुतेक object cache entries TTL शिवाय साठवते. त्यामुळे object cache वरील volatile-lru भरू शकते आणि writes नाकारू लागते. तुमच्या traffic मध्ये काही मोजक्या keys वारंवार वापरल्या जात असल्यास allkeys-lfu हा योग्य पर्याय ठरू शकतो, कारण तो recency ऐवजी frequency नुसार keys काढून टाकतो. एक धोरण जाणीवपूर्वक निवडा आणि ते का निवडले याची नोंद ठेवा.

Persistence: कारण नसल्यास बंद ठेवा

पॅकेजसोबत येणारे redis.conf, save 900 1 सारख्या ओळींद्वारे RDB snapshots सक्षम करते आणि append-only file बंद ठेवते. केवळ object cache साठी snapshots चा काहीही लाभ नाही. ही data मूलतः पुन्हा निर्माण करता येते. तसेच, वीस मिनिटे जुन्या file मधून restore केलेल्या cache मध्ये stale values असतात आणि WordPress त्यांच्यावर विश्वास ठेवेल.

Snapshots मुळे खर्चही होतो. BGSAVE process ला fork करते आणि child लिहित असताना copy-on-write मुळे memory usage झपाट्याने वाढू शकते. लहान VPS वर हे Redis log मध्ये दिसते:

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

तसेच startup वेळी पुढील warning अनेकदा दिसते. याचा अर्थ fork पुढे अपयशी ठरण्याची शक्यता Redis दर्शवत आहे:

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

Snapshots बंद करण्यासाठी /etc/redis/redis.conf मध्ये रिकामी save schedule सेट करा, restart करा आणि value पुन्हा रिकामी झाली आहे याची खात्री करा.

save ""

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

त्याच instance मध्ये rebuild करता न येणारी माहिती, जसे job queue किंवा rate-limit counters, साठवली असेल तरच persistence चालू ठेवा. अशा वेळी दोन्ही वेगळे करा. Cache मधील keys evict होणे आवश्यक असते, तर durable data मधील keys जतन करणे आवश्यक असते. maxmemory आणि eviction संपूर्ण instance वर लागू होतात; ते एखाद्या database index पुरते मर्यादित नसतात. दोन sockets वर दोन instances ठेवणे हा स्वच्छ उपाय आहे.

प्लगइन स्थापित करा आणि 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 आहे आणि प्रत्यक्ष काम drop-in करते. WordPress कोणत्याही plugin code च्या आधी, अगदी सुरुवातीलाच wp-content/object-cache.php लोड करते. त्यामुळे संपूर्ण request साठी cache उपलब्ध राहतो. drop-in नसलेला सक्रिय plugin कोणताही cache तयार करत नाही.

अपयशाचे संदेश कोणता भाग अयशस्वी झाला ते सांगतात. Object cache could not be enabled. याचा अर्थ प्रत तयार करणे अयशस्वी झाले. त्यामुळे WP-CLI चालवणाऱ्या user ला wp-content मध्ये लिहिण्याची परवानगी नाही. A foreign object cache drop-in was found. याचा अर्थ दुसऱ्या caching plugin ने तो filename आधीच वापरला आहे. यासाठी wp redis update-dropin करा. Redis server is unreachable: ने समाप्त होणारा संदेश आणि त्यानंतर दिसणारी client error connection settings चुकीच्या असल्याचे दर्शवतात. त्यामुळे redis-cli ping कडे परत जा.

Permissions मुळे प्रत तयार करणे अयशस्वी झाल्यास, ती प्रत manually ठेवा आणि तिची मालकी web user कडे द्या.

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 जुना cache code चालवत राहते; मात्र तो update करण्यासाठी plugin उपलब्ध राहत नाही.

wp-config.php मधील connection settings

/* That's all, stop editing! */ असलेल्या ओळीच्या वर हे जोडा. त्या ओळीनंतर define केलेले 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 साठी seconds मध्ये expiry लागू करते. allkeys-lru वापरत असल्यास याची आवश्यकता नाही. Cached value किती stale असू शकते याची कमाल मर्यादा निश्चित करायची असल्यास हे उपयुक्त ठरते.

एक Redis, अनेक साइट्स: prefix आणि database

Redis डिफॉल्टनुसार सोळा क्रमांकित database देते आणि प्रत्येकामध्ये एकच flat keyspace असतो. prefix न वापरता database 0 कडे निर्देश करणारी दोन WordPress installations समान key names त्याच keyspace मध्ये लिहितात. त्यामुळे एक साइट दुसऱ्या साइटचे options वाचून ते वापरू शकते. प्रत्येक साइटसाठी स्वतंत्र prefix द्या.

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

prefix मुळे key names वेगळे होतात. database index मुळे keyspaces वेगळे होतात. Flush करताना याला महत्त्व असते: एक index रिकामा केल्यावर इतर index वर परिणाम होत नाही. Plugin मध्ये WP_REDIS_SELECTIVE_FLUSH याचेही दस्तऐवजीकरण आहे. हे संपूर्ण database रिकामे करण्याऐवजी तुमच्या prefix शी जुळणाऱ्या keysच हटवते. मात्र त्यासाठी त्या keys शोधण्यासाठी scanning करावी लागते.

prefix आणि index memory वेगळी करत नाहीत. maxmemory आणि eviction policy संपूर्ण instance वर लागू होतात. त्यामुळे व्यस्त साइट quiet साइटच्या keys बाहेर काढू शकते आणि कोणतीही साइट हे नोंदवत नाही. ज्या साइट्सनी एकमेकांवर परिणाम करू नये त्यांच्यासाठी स्वतंत्र Redis instances वापरा. प्रत्येक instance साठी स्वतंत्र socket आणि स्वतंत्र limit ठेवा.

Production च्या cache मध्ये staging मिसळू नका

Staging site ही सहसा production files आणि database ची प्रत असते. त्यामुळे ती wp-config.php ची प्रत असते आणि त्यात तोच prefix तसेच तोच database index असतो. तिला त्याच Redis कडे निर्देशित केल्यास staging values सह production keys लिहिल्या जातात. चाचणीसाठी बदललेली किंमत किंवा बदललेला option live site वर कोणत्याही deploy शिवाय आणि कोणताही मागमूस न ठेवता दिसू शकतो.

प्रत्येक 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 वापरण्याचे नमूद केले आहे. त्यामुळे नवीन नाव वापरा.

त्यावर विश्वास ठेवण्याऐवजी पडताळा

सुरुवात plugin च्या स्वतःच्या diagnostics पासून करा.

wp redis status

सर्वात महत्त्वाची ओळ Drop-in आहे. Drop-in: Valid याचा अर्थ WordPress हा plugin चा file load करत आहे. Drop-in: Not installed याचा अर्थ copy कधीच झाली नाही आणि site कडे persistent cache नाही, admin screen वर सर्व काही योग्य दिसत असले तरी. Status connection ची माहिती देते आणि Client वापरात असलेले extension सांगते. येथे Predis ऐवजी PhpRedis असल्याची खात्री करा.

त्यानंतर WordPress core ला थेट विचारा, कारण plugin ला काय वाटते याची त्याला पर्वा नसते.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) याचा अर्थ core external object cache शी संवाद साधत आहे.

तुम्ही configured केलेल्या prefix सह keys येत आहेत हे आता सिद्ध करा.

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

तुम्ही site वर विविध ठिकाणी click करताना dbsize वाढत असेल, तर तोच पुरावा आहे. वैध drop-in असूनही keys ची संख्या शून्य असेल, तर connection शांतपणे fail होत आहे किंवा prefix तुम्हाला वाटतो तो नाही.

शेवटी, Redis तुमच्यासाठी काय मोजते ते पाहा.

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

Hit ratio keyspace_hits / (keyspace_hits + keyspace_misses) आहे आणि Redis च्या documentation मध्ये त्याचे formula दिले आहे. ते दोन सूचनांसह समजून घ्या. Counters शेवटच्या restart पासून संपूर्ण instance साठी असतात. त्यामुळे त्यात तोच instance share करणाऱ्या प्रत्येक site आणि application चे आकडे मिसळलेले असतात. तसेच flush किंवा restart नंतर लगेचचा ratio अर्थपूर्ण नसतो, कारण cache अजून भरत असतो. त्याला traffic च्या एका सामान्य दिवसातून चालू द्या.

Hosting company ने प्रकाशित केलेल्या hit rate किंवा query count शी तुमच्या आकड्याची तुलना करू नका. ते त्यांच्या sites आणि त्यांच्या plugin set चे वर्णन करतात. महत्त्वाचा आकडा तुमचा स्वतःचा आहे. तो page cache serve करू शकत नाही अशा page वर आधी आणि नंतर मोजा.

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

हे logged-in cookie jar सह अनेक वेळा चालवा. प्रथम cache बंद ठेवून (WP_REDIS_DISABLED) आणि नंतर सुरू ठेवून चालवा. त्या दोन्हीमधील फरक हाच तुमचा परिणाम आहे.

Redis मुळे WordPress धीमे होते तेव्हा

चुकीचे eviction policy असलेले पूर्ण instance हे सर्वात मोठे कारण आहे. वर याचा उल्लेख केला आहे: log मध्ये OOM command not allowed when used memory > 'maxmemory'. दिसते आणि साइट database तसेच cache या दोन्हींसाठी पैसे खर्च करते.

दुसऱ्या host वर असलेले Redis हे दुसरे कारण आहे. एका request मध्ये WordPress 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 ना समान cache share करणाऱ्या cores वर ठेवण्याचा प्रयत्न करते. VPS guest ला bare metal पेक्षा याचा कमी फायदा होतो.

मोठा autoloaded options table हे तिसरे कारण आहे आणि जुन्या sites वर ते सामान्य आहे. 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 जोडली. त्यामुळे आधुनिक install वर केवळ 'yes' शी जुळणारी जुनी query प्रत्यक्ष प्रमाणापेक्षा कमी आकडा दाखवते. एक megabyte पेक्षा जास्त आकार असल्यास options table मध्ये सुधारणा करणे आवश्यक आहे; Redis मध्ये नाही.

Restart केल्यावर सर्व cache entries रिकाम्या होतात. त्यामुळे systemctl restart redis-server नंतरची काही मिनिटे सर्व requests misses असतात आणि सर्व database work पुन्हा होते. Traffic कमी असताना restart करा. Object cache मुळे visitor page loads दरम्यान wp-cron.php चालणे थांबत नाही. हे slow requests चे स्वतंत्र कारण आहे: येथे असताना WP-Cron ला प्रत्यक्ष system cron job वर हलवा.

हाऊसकीपिंग

पर्याय किंवा theme code बदलणारे deploy केल्यानंतर wp cache flush वापरून cache flush करा. Plugin update नंतर drop-in आपोआप update झाला नसेल, तर wp redis update-dropin चालवा. जुन्या plugin version मधील drop-in नवीन plugin विरुद्ध वापरल्यास अनपेक्षित वर्तन होऊ शकते. redis-cli --stat वापरून live server चे निरीक्षण करा. ते दर सेकंदाला एक ओळ दाखवते. redis-cli monitor प्रत्येक command दाखवते आणि busy instance वर CPU चा लक्षणीय वापर करते. त्यामुळे एखादी समस्या पुन्हा निर्माण करताना ते काही सेकंदांसाठी वापरा आणि नंतर थांबवा.

आणखी एक महत्त्वाची संख्या लक्षात ठेवा: redis-cli info clients हे connected_clients दाखवते. PHP-FPM प्रत्येक worker साठी एक connection ठेवते. त्यामुळे ही संख्या तुमच्या pm.max_children शी साधारण जुळली पाहिजे. ती त्यापेक्षा अनेक पटींनी जास्त असल्यास, काहीतरी connections उघडत आहे आणि ते बंद करत नाही.

FAQ

Redis object cache चालवत असताना page cache ची अजूनही गरज आहे का?

होय, anonymous traffic साठी. Page cache साठवलेले HTML PHP चालविल्याशिवाय देते. Warm object cache असलेल्या WordPress चालवण्यापेक्षा हा खर्च नेहमीच कमी असतो. Page cache ने वगळावयाच्या विनंत्या object cache हाताळतो: logged-in users, carts, checkout आणि wp-admin. Shop किंवा membership site वर दोन्ही चालवणे फायदेशीर आहे. ज्या site वर अभ्यागत कधीही login करत नाहीत, तिथे जवळजवळ सर्व काम page cache करतो.

WordPress साठी Redis ला किती memory द्यावी?

कोणताही आकडा तसाच वापरण्याऐवजी आपल्या server वरून तो ठरवा. Total RAM मधून MySQL buffer pool आणि per-connection buffers वजा करा. त्यानंतर pm.max_children ला एका PHP-FPM worker च्या resident size ने गुणून मिळणारी रक्कम वजा करा. Kernel आणि web server साठी आणखी काहीशे megabytes वजा करा. उरलेल्या memory पैकी काही भाग Redis ला द्या. त्यानंतर एक दिवसाचा traffic झाल्यावर redis-cli info memory मधील used_memory_human तपासा आणि आवश्यकतेनुसार बदल करा. एका WordPress site ला सामान्यतः काही tens of megabytes पुरतात. त्यामुळे 4 GB server वर 256 MB maxmemory ही उदार सुरुवात आहे.

Redis object cache सुरू केल्यानंतर माझी site धीमी का झाली?

सामान्य कारण म्हणजे noeviction policy वापरणारी पूर्ण instance. Redis नवीन writes नाकारतो आणि OOM command not allowed when used memory > 'maxmemory'. परत करतो. त्यामुळे WordPress प्रत्येक value साठी database कडे fallback करतो आणि त्यावर वाया जाणारा Redis round trip देखील होतो. redis-cli config get maxmemory-policy तपासा, allkeys-lru सेट करा आणि maxmemory खूप लहान नाही याची खात्री करा. इतर सामान्य कारणांमध्ये remote host वरील Redis server येतो. अशा वेळी प्रत्येक request मधील शेकडो round trips एकत्रित होऊन विलंब वाढतो. तसेच प्रत्येक request वेळी connection मधून जाणारी अनेक megabytes आकाराची autoloaded options value देखील कारणीभूत ठरू शकते.

अनेक WordPress sites एकाच Redis server वर share करू शकतात का?

होय, परंतु काळजीपूर्वक. प्रत्येक site ला अद्वितीय WP_REDIS_PREFIX द्या, जेणेकरून key names मध्ये collision होणार नाही. प्रत्येक site साठी स्वतंत्र WP_REDIS_DATABASE index द्या, जेणेकरून एका site चे data flush केल्यावर दुसऱ्या site चे data रिकामे होणार नाही. तरीही memory share केली जाते. maxmemory आणि eviction संपूर्ण instance वर लागू होतात. त्यामुळे व्यस्त site शांत site च्या keys evict करू शकते. एकमेकांवर परिणाम होता कामा नये अशा sites साठी स्वतःच्या limits असलेल्या स्वतंत्र Redis instances आवश्यक आहेत.

wp-content/object-cache.php delete करणे सुरक्षित आहे का?

होय. ही drop-in file आहे; ती WordPress core चा भाग नाही. ती काढल्यावर WordPress आपल्या built-in per-request cache वर परत येतो. Site सुरू राहते आणि फक्त अधिक database queries करते. wp redis disable वापरणे अधिक योग्य आहे. ते file स्वच्छपणे delete करते आणि Object cache disabled. नोंदवते. Redis बंद असल्यास किंवा चुकीने काम करत असल्यास आणि admin पर्यंत पोहोचता येत नसल्यास, ती file हाताने delete करणे योग्य emergency उपाय आहे.