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తో మాట్లాడే object cacheను అమర్చుతుంది. అందువల్ల ఒక request నుంచి తదుపరి request వరకు cache నిల్వ ఉంటుంది.

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లో ఎక్కువ భాగం ఇదే.

ఈ రెండింటినీ కలిపి ఉపయోగించవచ్చు. Busy siteలో రెండూ అవసరం. మీరు ఏ సమస్యను పరిష్కరిస్తున్నారో స్పష్టంగా తెలుసుకోండి. Anonymous readers ఉన్న brochure site తన వేగంలో దాదాపు మొత్తం page cache వల్లే పొందుతుంది. దానికి Redis జోడించినా మార్పు చాలా తక్కువగా ఉంటుంది.

ప్రారంభించే ముందు ఒక పరిమితిని స్పష్టంగా తెలుసుకోండి. Object cache slow queryను fast queryగా మార్చదు. ఇప్పటికే అమలైన queryను మళ్లీ అమలు చేయాల్సిన అవసరాన్ని మాత్రమే తొలగిస్తుంది. 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 నడుస్తున్న అదే machineలో Redis. తక్కువ latency ఈ విధానం యొక్క ప్రధాన ఉద్దేశ్యం. Network hop వల్ల ఆ ప్రయోజనం తగ్గిపోతుంది.

క్రింది commands Ubuntu 24.04, PHP 8.3 మరియు www-data web user కోసం రాయబడ్డాయి. మీ సర్వర్‌కు సరిపోయే PHP version మరియు user కు మార్చండి. WordPress directory నుంచి wp commands ను అమలు చేయండి. ఈ 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ను ప్రింట్ చేస్తే, server నడుస్తున్నది కాదు. కాబట్టి ముందుకు వెళ్లే ముందు systemctl status redis-server`ను చదవండి.

php-redis అనేది PECL నుంచి వచ్చే C extension అయిన PhpRedis. Pure PHPలో ఉండే Predis కంటే ఇది వేగంగా ఉంటుంది. ఇది అందుబాటులో ఉంటే plugin స్వయంచాలకంగా దానిని ఉపయోగిస్తుంది. PHP-FPM ప్రారంభమైనప్పుడు extensions ను load చేస్తుంది. కాబట్టి కొత్త extension అందుబాటులోకి రావాలంటే pool ను restart చేయాలి.

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

చివరి check విషయంలో జాగ్రత్తగా ఉండండి. `php -m` command line PHP లోని modules ను చూపిస్తుంది. FPM వేరే modules సమితిని load చేయవచ్చు. నిర్ణయాత్మకమైన check 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 ఉండదు. 6379 portకు connection తెరవగలిగిన ఏదైనా process ప్రతి cached valueను చదవగలదు మరియు FLUSHALL ను అమలు చేయగలదు. Internetకు బహిర్గతమైన instancesను scanners కొన్ని గంటల్లోనే గుర్తిస్తాయి. అందువల్ల tuningకు ముందు network settingను సరిచేయాలి.

/etc/redis/redis.conf ను తెరిచి, ఈ lines ఉన్నాయో నిర్ధారించండి:

bind 127.0.0.1 -::1
protected-mode yes

తర్వాత నిజంగా ఏది listeningలో ఉందో పరిశీలించండి. Config 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 నిర్ణయిస్తాయి.

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 ను print చేయాలి. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied అంటే group అమలులోకి రాలేదని అర్థం. id www-data ను పరిశీలించండి. Running PHP-FPM ప్రారంభమైనప్పుడు ఉన్న groupsనే కొనసాగిస్తుందని గుర్తుంచుకోండి. అందుకే restart జాబితాలో ఉంది. Socket పనిచేస్తోందని నిర్ధారించే వరకు TCPను enabledగా ఉంచండి. లేకపోతే ఒక typo వల్ల రెండు మార్గాలూ ఒకేసారి అందుబాటులో లేకుండా పోవచ్చు.

Redis కు ఎంత memory కేటాయించాలి?

ఈ సంఖ్యను మీ స్వంత server ఆధారంగా నిర్ణయించండి. maxmemory లేకపోతే Redis kernel memory పూర్తయ్యే వరకు పెరుగుతుంది. తరువాత OOM killer ఒక process ను ముగిస్తుంది. సాధారణంగా అది ఎక్కువ memory ఉపయోగిస్తున్న 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 అవసరం. మిగిలినది మీ గరిష్ఠ పరిమితి. అందులో కొంత భాగాన్ని 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 దాన్ని మెరుగ్గా ఉపయోగిస్తుంది. అది limit వద్దే నిలిచి, evicted_keys రోజంతా పెరుగుతూ ఉంటే limit పెంచండి. విలువను /etc/redis/redis.conf లో సెట్ చేయండి.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb ప్రస్తుతం అమలవుతుంది. తదుపరి restart సమయంలో అది మరిచిపోతుంది. Bare sysctl -w కూడా ఇదే సమస్యను కలిగిస్తుంది. File ను edit చేసిన తరువాత sudo systemctl restart redis-server అమలు చేసి, తరువాత విలువను మళ్లీ చదవండి. అదనపు memory boundary ఉంచడం మంచిది: systemd unit పై MemoryMax cap తప్పుగా configure చేసిన Redis మొత్తం server ను నిలిపివేయకుండా ఆపుతుంది. దాన్ని maxmemory కంటే ఎక్కువగా సెట్ చేయండి. దానికి సమానంగా ఎప్పుడూ సెట్ చేయకండి. ఎందుకంటే cgroup limit key ను evict చేయదు; process ను ముగిస్తుంది. Redis WordPress పక్కన container లో నడుస్తుంటే, అదే సంఖ్యను మీ Compose file లోని memory limits లో ఉంచాలి. database ను Docker లో లేదా host పై నడపడం గురించి నిర్ణయాన్ని కూడా ఇదే ఆలోచన ఆధారపడి ఉంటుంది.

Eviction policyని ఉద్దేశపూర్వకంగా ఎంచుకోండి

కొత్త Redisలో డిఫాల్ట్‌గా noeviction ఉంటుంది. మీ instanceలో ఉన్న విలువను పరిశీలించండి:

redis-cli config get maxmemory-policy

noeviction కింద, పూర్తిగా నిండిన instance writesను స్వీకరించడం ఆపి, ఈ సమాధానాన్ని ఇస్తుంది:

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

ఈ guideలో ఇది అత్యంత తీవ్రమైన failure mode. కారణం site పూర్తిగా down కాకపోవడమే. అది నెమ్మదిస్తుంది. ప్రతి cache write విఫలమవుతుంది. అందువల్ల WordPress ఆ విలువ కోసం databaseను మళ్లీ ఆశ్రయిస్తుంది. తరువాతి requestలో దాన్ని మళ్లీ store చేయడానికి ప్రయత్నించి, మళ్లీ విఫలమవుతుంది. ఇప్పుడు site తన అసలు database పనితో పాటు ప్రతి key కోసం 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 లేకుండా store చేస్తుంది. అందువల్ల 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 లో పాత values ఉంటాయి. WordPress వాటిని నమ్ముతుంది.

Snapshots కు వనరుల ఖర్చు కూడా ఉంటుంది. BGSAVE process ను fork చేస్తుంది. Child process లో writes జరుగుతున్నప్పుడు copy-on-write కారణంగా memory వినియోగం వేగంగా పెరగవచ్చు. చిన్న 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 లో మళ్లీ సృష్టించలేని data ఉంటే మాత్రమే persistence ను ఉంచండి. ఉదాహరణకు job queue లేదా rate-limit counters. అలాంటి సందర్భంలో రెండింటినీ విడిగా ఉంచండి. Cache లో keys ను evict చేయాలి. Durable data లో keys ను ఉంచాలి. maxmemory మరియు eviction మొత్తం instance కు వర్తిస్తాయి; ఒక database index కు మాత్రమే వర్తించవు. రెండు sockets పై రెండు instances నడపడం సరైన పరిష్కారం.

Plugin‌ను ఇన్‌స్టాల్ చేసి, 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 లేకపోతే active 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 కారణంగా కాపీ విఫలమైతే, దాన్ని చేతితో ఉంచి 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‌ను తొలగిస్తుంది. Drop-in అలాగే ఉండగా plugin directory‌ను తొలగిస్తే site పాత cache code‌తోనే నడుస్తుంది. దాన్ని update చేయడానికి plugin లేకపోతుంది.

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 కి seconds లో expiry ను తప్పనిసరిగా అమలు చేస్తుంది. allkeys-lru తో ఇది అవసరం లేదు. Cached value ఎంత పాతదిగా ఉండవచ్చో కఠినమైన గరిష్ఠ పరిమితి కావాలంటే ఇది ఉపయోగకరంగా ఉంటుంది.

ఒకే Redis, అనేక సైట్లు: prefixలు మరియు databaseలు

Redis డిఫాల్ట్‌గా పదహారు సంఖ్యీకరించిన databaseలను అందిస్తుంది. ప్రతి databaseలో ఒకే flat keyspace ఉంటుంది. prefix లేకుండా database 0ను ఉపయోగించే రెండు WordPress installations ఒకే keyspaceలో ఒకే key పేర్లను రాస్తాయి. అందువల్ల ఒక site మరొక site యొక్క optionsను చదివి వాటినే అందించవచ్చు. ప్రతి siteకు ప్రత్యేక prefix ఇవ్వండి.

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

prefix key పేర్లను వేరు చేస్తుంది. database indexలు keyspaceలను వేరు చేస్తాయి. Flush సమయంలో ఇది ముఖ్యమైనది. ఒక indexను ఖాళీ చేస్తే మిగిలిన indexలు ప్రభావితం కావు. Plugin WP_REDIS_SELECTIVE_FLUSH ను కూడా document చేస్తుంది. ఇది మొత్తం databaseను తొలగించకుండా, మీ prefixకు సరిపోలే keysను మాత్రమే తొలగిస్తుంది. అయితే వాటిని కనుగొనడానికి scan చేయాలి.

prefixలు మరియు indexలు వేరు చేయనిది memory. maxmemory మరియు eviction policy మొత్తం instanceకు వర్తిస్తాయి. అందువల్ల ఎక్కువగా ఉపయోగించే site, తక్కువగా ఉపయోగించే site యొక్క keysను తొలగింపుకు గురిచేయవచ్చు. ఏ site కూడా ఈ పరిస్థితిని తెలియజేయదు. Sites ఒకదానిపై మరొకటి ప్రభావం చూపకూడదంటే ప్రత్యేక Redis instances అవసరం. ప్రతి instanceకు ప్రత్యేక socket మరియు ప్రత్యేక limit ఉండాలి.

staging ను production cache కు దూరంగా ఉంచండి

సాధారణంగా staging site అనేది production files మరియు database యొక్క ప్రతిరూపం. అందువల్ల అదే prefix మరియు అదే database index కలిగిన wp-config.php యొక్క ప్రతిరూపం కూడా అవుతుంది. దాన్ని అదే Redis కు అనుసంధానిస్తే, staging values తో production keys ను రాస్తుంది. పరీక్షా ధర లేదా మార్చిన option live site లో deploy లేకుండానే, ఎటువంటి trace లేకుండానే కనిపించవచ్చు.

ప్రతి 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 ను అలాగే ఉంచుతుంది. Cache వల్ల bug వస్తుందా లేదా అని నిర్ధారించడానికి ఇది వేగవంతమైన మార్గం కూడా.

పాత tutorials దీనికోసం WP_CACHE_KEY_SALT ను సెట్ చేసేవి. Plugin యొక్క readme లో ఆ constant deprecated అని, దాని స్థానంలో WP_REDIS_PREFIX ఉపయోగించాలని పేర్కొన్నారు. కాబట్టి కొత్త పేరునే ఉపయోగించండి.

నమ్మకుండా నిర్ధారించండి

ముందుగా plugin అందించే స్వంత diagnostics ను పరిశీలించండి.

wp redis status

అత్యంత ముఖ్యమైన line 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 లో వివిధ భాగాలను click చేస్తుండగా dbsize పెరుగుతుండటం నిర్ధారణకు ఆధారం. Valid drop-in ఉన్నప్పటికీ keys సంఖ్య zero గా ఉంటే connection నిశ్శబ్దంగా విఫలమవుతోంది లేదా మీరు అనుకున్న 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 మొత్తం instance కు వర్తిస్తాయి. అవి చివరి restart తర్వాతి విలువలను చూపిస్తాయి. అందువల్ల వాటిలో ఆ instance ను పంచుకునే ప్రతి site మరియు ప్రతి application గణాంకాలు కలిసిపోతాయి. Flush లేదా restart చేసిన వెంటనే కనిపించే ratio కు అర్థం ఉండదు, ఎందుకంటే cache ఇంకా నిండి ఉండదు. సాధారణ network traffic ఉన్న ఒక పూర్తి రోజువరకు దాన్ని అమలులో ఉంచండి.

Hosting company ప్రచురించిన hit rate లేదా query count తో మీ సంఖ్యను పోల్చవద్దు. అవి వారి sites మరియు వారి plugin set ను వివరిస్తాయి. ముఖ్యమైనది మీ స్వంత సంఖ్య. Page cache అందించలేని ఒక page పై, cache ముందు మరియు తర్వాత దాన్ని కొలవాలి.

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

దీన్ని logged-in cookie jar తో అనేకసార్లు run చేయండి. ముందుగా cache off (WP_REDIS_DISABLED) లో, తరువాత on లో run చేయండి. ఆ రెండు ఫలితాల మధ్య తేడానే మీ result.

Redis WordPress ను నెమ్మదిగా చేసే సందర్భాలు

తప్పు policy తో నడుస్తున్న full instance ప్రధాన కారణం. ఇది పైభాగంలో వివరించాం: log లో OOM command not allowed when used memory > 'maxmemory'. కనిపిస్తుంది. ఆ site database మరియు cache రెండింటికీ చెల్లిస్తుంది.

మరొక host లో ఉన్న Redis రెండో కారణం. WordPress ఒక request లో object cache ను వందల సార్లు పిలుస్తుంది. ఒక request 500 calls చేస్తే, ప్రతి round trip కు 1 ms పడుతుంది. అప్పుడు local socket తో పోలిస్తే అదనంగా అర సెకను వేచి ఉండాలి. Redis ను అదే server లో ఉంచండి. లేదా sub-millisecond latency ఉన్న private network పై ఉంచండి. అదే server లో ఉండటం వల్ల kernel నుంచి లభించే ప్రయోజనం ఎంత అనేది వేరే విషయం: Linux 7.2లో చేర్చిన cache-aware scheduling PHP-FPM మరియు Redis వంటి తరచుగా పరస్పరం సమాచార మార్పిడి చేసే processes ను ఒకే cache పంచుకునే cores పై ఉంచడానికి ప్రయత్నిస్తుంది. Bare metal కంటే VPS guest లో ఈ ప్రయోజనం తక్కువగా ఉంటుంది.

చాలా పెద్ద 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 దాటితే సమస్యను Redis లో కాదు, options table లో పరిష్కరించాలి.

Restart చేస్తే మొత్తం cache ఖాళీ అవుతుంది. అందువల్ల 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 ను flush చేయండి. Plugin update తర్వాత drop-in స్వయంగా update కాకపోతే wp redis update-dropin ను అమలు చేయండి. పాత plugin version కు చెందిన drop-in ను కొత్త plugin తో ఉపయోగించడం odd behaviour కు నిజమైన కారణం కావచ్చు. Live server ను redis-cli --stat తో monitor చేయండి. ఇది ప్రతి సెకనుకు ఒక line ను ప్రింట్ చేస్తుంది. redis-cli monitor ప్రతి command ను ప్రింట్ చేస్తుంది. Busy instance పై దీనికి గణనీయమైన CPU వినియోగం ఉంటుంది. అందువల్ల ఏదైనా సమస్యను పునరుత్పత్తి చేస్తున్నప్పుడు కొన్ని seconds మాత్రమే ఉపయోగించి, తరువాత దీన్ని ఆపండి.

చివరిగా తెలుసుకోవాల్సిన మరో సంఖ్య: redis-cli info clients, connected_clients ను report చేస్తుంది. PHP-FPM ప్రతి worker కోసం ఒక connection ను ఉంచుతుంది. కాబట్టి ఆ సంఖ్య మీ pm.max_children కు అనుగుణంగా ఉండాలి. అది దానికంటే order of magnitude మేర ఎక్కువగా ఉండకూడదు. ఎక్కువగా ఉంటే, ఏదో ఒకటి connections ను తెరిచి వాటిని close చేయడం లేదని అర్థం.

FAQ

Redis object cache నడుపుతున్నప్పుడు page cache ఇంకా అవసరమా?

అవును, anonymous traffic కోసం అవసరం. Page cache PHP ను నడపకుండా నిల్వ చేసిన HTML ను అందిస్తుంది. Warm object cache ఉన్న WordPress ను నడపడం కంటే ఇది ఎల్లప్పుడూ తక్కువ వనరులు ఉపయోగిస్తుంది. Page cache skip చేయాల్సిన requests ను object cache నిర్వహిస్తుంది: logged-in users, carts, checkout, మరియు wp-admin. Shop లేదా membership site లో రెండింటినీ నడపడం ప్రయోజనకరం. Visitors ఎప్పుడూ login చేయని site లో దాదాపు మొత్తం పనిని 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 ద్వారా పంపబడే multi-megabyte autoloaded options value కూడా మరో కారణం.

అనేక WordPress sites ఒకే Redis server ను share చేయవచ్చా?

జాగ్రత్తగా అమలు చేస్తే చేయవచ్చు. ప్రతి site కు ప్రత్యేకమైన WP_REDIS_PREFIX ఇవ్వండి. అప్పుడు key names పరస్పరం collide కావు. అలాగే ప్రతి site కు ప్రత్యేకమైన WP_REDIS_DATABASE index ఇవ్వండి. దీంతో ఒక site ను flush చేసినప్పుడు మరో site ఖాళీ కాదు. అయితే memory మాత్రం అందరూ share చేస్తారు. maxmemory మరియు eviction మొత్తం instance కు వర్తిస్తాయి. అందువల్ల busy site, quiet site యొక్క keys ను evict చేయవచ్చు. ఒకదానిపై మరొకటి ప్రభావం చూపకూడని sites కు స్వంత limits తో ప్రత్యేక Redis instances అవసరం.

wp-content/object-cache.php ను తొలగించడం సురక్షితమేనా?

అవును. ఇది drop-in మాత్రమే; WordPress core లో భాగం కాదు. దీన్ని తొలగిస్తే WordPress తన built-in per-request cache కు తిరిగి వస్తుంది. Site పనిచేస్తూనే ఉంటుంది, కానీ database queries ఎక్కువగా చేస్తుంది. wp redis disable ను ఉపయోగించడం మంచిది. ఇది file ను సక్రమంగా తొలగించి Object cache disabled. ను నివేదిస్తుంది. Redis పనిచేయకపోయినా లేదా తప్పుగా ప్రవర్తిస్తున్నా, admin కు చేరుకోలేని అత్యవసర పరిస్థితిలో చేతితో తొలగించడం సరైన చర్య.