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 त्याची जागा Redis शी संवाद साधणाऱ्या cache ने घेते. त्यामुळे एक request संपल्यानंतरही cache पुढील request साठी उपलब्ध राहतो.

Object caching आणि page caching एकसारखे नाहीत. हा फरक समजल्यावर हे मार्गदर्शक तुमच्यासाठी उपयुक्त आहे का ते ठरते. Page cache एखाद्या URL चे तयार HTML साठवते आणि PHP अजिबात चालविल्याशिवाय ते पुन्हा serve करते. 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 याचाच मोठा भाग असतो.

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

सुरुवात करण्यापूर्वी एक मर्यादा लक्षात घ्या. Object cache slow query जलद करत नाही. आधी चालविलेल्या query ची repeat प्रक्रिया तो टाळतो. 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 आहे. शुद्ध 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 वेगळा module संच लोड करू शकतो. plugin च्या स्वतःच्या diagnostics मधील तपासणीच ग्राह्य धरावी; ती पुढे दिली आहे.

August 2026 पर्यंत Ubuntu 24.04 मध्ये Redis 7.0.15 उपलब्ध आहे. object cache साठी ही आवृत्ती पुरेशी आहे. त्याऐवजी नवीन 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 बदलानंतर सुरू झालेले fork आहे. ते समान protocol वापरते आणि खालील सर्व सूचना कोणताही बदल न करता लागू होतात.

Redis ला असे bind करा की इतर कोणत्याही ठिकाणाहून त्याच्यापर्यंत पोहोचता येणार नाही

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

/etc/redis/redis.conf उघडा आणि या ओळी तपासा:

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 वर उत्तर देत आहे. bind ओळ दुरुस्त करा आणि 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 चा मालक 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 या यादीत आहे. Socket योग्य असल्याचे सिद्ध होईपर्यंत TCP enabled ठेवा. अन्यथा एखाद्या typo मुळे दोन्ही मार्ग एकाच वेळी बंद होऊ शकतात.

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

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

एकूण RAM पासून वजाबाकी सुरू करा. MySQL किंवा MariaDB innodb_buffer_pool_size तसेच प्रत्येक connection साठीचे buffers राखून ठेवते. PHP-FPM साठी pm.max_children ला एका worker च्या प्रत्यक्ष resident size ने गुणा करा. Plugin जास्त असलेल्या साइटवर हा आकार सामान्यतः 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 तुमच्या limit पेक्षा बरेच कमी राहात असेल, तर limit कमी करा आणि RAM MySQL ला परत द्या. MySQL तिचा अधिक चांगला उपयोग करेल. used_memory_human limit वर स्थिर राहत असेल आणि evicted_keys दिवसभर वाढत असेल, तर limit वाढवा. ही 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 चुकीच्या configuration मुळे Redis ने संपूर्ण सर्व्हर बंद पडण्यापासून रोखते. ही मर्यादा maxmemory पेक्षा जास्त ठेवा. ती maxmemory इतकीच ठेवू नका. cgroup limit key evict करण्याऐवजी process बंद करते. Redis WordPress च्या शेजारी container मध्ये चालत असेल, तर हीच value तुमच्या Compose file मधील memory limits मध्ये द्या. तसेच database Docker मध्ये चालवायचा की host वर याची निवडही याच तर्कावर आधारित असते.

हेतुपूर्वक eviction policy निवडा

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

redis-cli config get maxmemory-policy

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

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

या मार्गदर्शकातील हा सर्वांत गंभीर failure mode आहे, कारण site बंद पडत नाही. ती फक्त मंद होते. प्रत्येक cache write अयशस्वी होते. त्यामुळे WordPress त्या value साठी पुन्हा database कडे जाते, पुढील request वेळी ती साठवण्याचा प्रयत्न करते आणि तो पुन्हा अयशस्वी होतो. आता प्रत्येक key साठी site ला मूळ database work सोबत Redis कडे एक round trip देखील करावा लागतो. हे घडत असल्याचे WordPress admin मध्ये कुठेही दिसत नाही. हा string PHP error log मध्ये दिसतो. त्यामुळे cache जोडल्यानंतर site मंद झाल्यास 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 च्या छोट्या संचावर वारंवार requests येत असल्यास allkeys-lfu हा योग्य पर्याय आहे, कारण तो recency ऐवजी frequency नुसार keys काढून टाकतो. एक policy जाणीवपूर्वक निवडा आणि त्यामागचे कारण नोंदवा.

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 वापर झपाट्याने वाढू शकतो. लहान VPS वर हे Redis log मध्ये दिसते:

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

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

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

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

save ""

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

त्याच instance मध्ये पुन्हा तयार करता न येणारा data, जसे 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 उपलब्ध राहतो. सक्रिय plugin असला, पण drop-in नसला, तर काहीही 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 कडे परत जा.

परवानगीच्या समस्येमुळे प्रत तयार झाली नाही, तर ती 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 वापरत सुरू राहते; मात्र तो अपडेट करण्यासाठी 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 किती जुनी असू शकते यावर कठोर कमाल मर्यादा हवी असल्यास हे उपयुक्त आहे.

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

Redis मध्ये defaultने सोळा क्रमांकित databases असतात आणि प्रत्येकामध्ये एक 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 याचेही documentation आहे. हे संपूर्ण database रिकामा करण्याऐवजी तुमच्या prefixशी जुळणाऱ्या keysच delete करते. मात्र त्यासाठी त्या keys शोधण्यासाठी scan करावा लागतो.

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

उत्पादनाच्या cache पासून staging वेगळे ठेवा

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

प्रत्येक 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 कधीच झाली नाही आणि admin screen वर सर्व काही योग्य दिसत असले तरी site कडे persistent cache नाही. Status connection ची माहिती देते आणि Client वापरात असलेला extension सांगते. येथे Predis ऐवजी PhpRedis वापरले जात आहे याची खात्री करा.

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

wp eval 'var_dump( wp_using_ext_object_cache() );'

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

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

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

तुम्ही site वर विविध पृष्ठांवर जात असताना 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 अजून भरत असतो. ते सामान्य network traffic असलेल्या एका पूर्ण दिवसासाठी चालू राहू द्या.

तुमच्या आकड्याची hosting company ने प्रकाशित केलेल्या hit rate किंवा query count शी तुलना करू नका. ते त्यांच्या sites आणि त्यांच्या plugin set चे वर्णन करतात. महत्त्वाचा आकडा तुमचा स्वतःचा आहे. तो page cache देऊ शकत नसलेल्या पृष्ठावर cache सुरू करण्यापूर्वी आणि नंतर मोजा.

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 धीमे झाल्यास

चुकीच्या 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 वर ठेवा.

मोठी 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 पेक्षा जास्त आकार असल्यास समस्या Redis मध्ये नाही, तर options table मध्ये आहे आणि ती तिथेच दुरुस्त करावी.

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

देखभाल

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

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

FAQ

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

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

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

इतरांचा आकडा कॉपी करण्याऐवजी आपल्या box च्या उपलब्ध संसाधनांवरून तो ठरवा. एकूण 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 enable केल्यानंतर माझी 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 मध्ये connection वरून जाणारी multi-megabyte autoloaded options value यांचा समावेश होतो. Remote Redis server मुळे प्रत्येक request मधील शेकडो round trips एकत्रित होऊन विलंब वाढतो.

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

होय, परंतु काळजीपूर्वक. प्रत्येक site साठी unique WP_REDIS_PREFIX द्या, जेणेकरून key names मध्ये collision होणार नाही. तसेच स्वतंत्र WP_REDIS_DATABASE index द्या, जेणेकरून एका site चे flushing केल्यावर दुसऱ्या site चा cache रिकामा होणार नाही. तरीही त्या memory share करतात. maxmemory आणि eviction संपूर्ण instance वर लागू होतात. त्यामुळे busy site quiet 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 manually delete करणे हा योग्य emergency उपाय आहे.