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 నుంచి తదుపరి request వరకు cache నిలిచి ఉంటుంది.

Object caching అనేది page caching కాదు. ఈ తేడా ఈ guide మీ సమయానికి విలువైనదా కాదా అనేది నిర్ణయిస్తుంది. 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లో ఎక్కువ భాగం ఇదే.

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

ప్రారంభించే ముందు ఒక పరిమితిని స్పష్టంగా తెలుసుకోండి. Object cache slow queryను fast చేయదు. ఇప్పటికే అమలైన 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 ఉన్న అదే యంత్రంలో 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 ఎక్స్‌టెన్షన్‌ను ఇన్‌స్టాల్ చేయండి

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 చేస్తుంది. అందువల్ల pool ను restart చేసే వరకు కొత్త extension కనిపించదు.

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

ఆ చివరి తనిఖీ విషయంలో జాగ్రత్తగా ఉండండి. php -m command line PHP యొక్క modules ను చూపిస్తుంది. FPM వేరే modules ను load చేయవచ్చు. plugin యొక్క స్వంత diagnostics లో కనిపించే తనిఖీయే నిర్ణయాత్మకం. అది క్రింద ఉంది.

August 2026 నాటికి, Ubuntu 24.04 Redis 7.0.15 ను package గా అందిస్తుంది. 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 లో డిఫాల్ట్‌గా password ఉండదు. port 6379 కు connection తెరవగల ఏదైనా వ్యవస్థ ప్రతి 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 పై సమాధానం ఇస్తోందని అర్థం. 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 ను తనిఖీ చేయండి. నడుస్తున్న PHP-FPM ప్రారంభమైనప్పుడు కలిగి ఉన్న groups నే కొనసాగిస్తుందని గుర్తుంచుకోండి. అందుకే list లో restart ఉంది. Socket పనిచేస్తోందని నిర్ధారించే వరకు TCP ను enabled గా ఉంచండి. లేకపోతే ఒక typo వల్ల రెండు మార్గాలూ ఒకేసారి అందుబాటులో లేకుండా పోవచ్చు.

Redis కు ఎంత మెమరీ కేటాయించాలి?

మీ స్వంత server ఆధారంగా ఈ సంఖ్యను నిర్ణయించండి. Redis కు maxmemory లేకపోతే, kernel వద్ద మెమరీ అయిపోయే వరకు అది పెరుగుతుంది. తరువాత OOM killer ఒక process ను ముగిస్తుంది. సాధారణంగా అది అత్యధిక మెమరీ ఉపయోగిస్తున్న process అవుతుంది. WordPress server లో అది తరచుగా MySQL అవుతుంది. journalctl -k | grep -i "out of memory" ఆ process ముగిసిన విషయాన్ని తరువాత చూపిస్తుంది. అప్పటికి site అందుబాటులో ఉండదు.

మొత్తం RAM నుండి అవసరమైన భాగాలను తీసివేయడం ద్వారా ప్రారంభించండి. MySQL లేదా MariaDB innodb_buffer_pool_size ను, అదనంగా ప్రతి connection కోసం buffers ను కేటాయిస్తుంది. PHP-FPM కు pm.max_children అవసరం. దీన్ని ఒక worker ఉపయోగించే వాస్తవ resident size తో గుణించాలి. Plugins ఎక్కువగా ఉన్న 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 మీ పరిమితికి చాలా దిగువన ఉంటే, ఆ పరిమితిని తగ్గించి RAM ను MySQL కు తిరిగి కేటాయించండి. MySQL దాన్ని మరింత సమర్థంగా ఉపయోగిస్తుంది. అది పరిమితి వద్దే ఉంటే, అలాగే evicted_keys రోజంతా పెరుగుతూ ఉంటే, పరిమితిని పెంచండి. విలువను /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 అమలు చేయండి. ఆపై విలువను మళ్లీ చదవండి. అదనపు రక్షణగా మరో పరిమితి ఉపయోగకరంగా ఉంటుంది: systemd unit పై MemoryMax cap ను సెట్ చేస్తే, తప్పుగా configure చేసిన Redis మొత్తం server ను నిలిపివేయకుండా ఆపవచ్చు. దీన్ని maxmemory కంటే ఎక్కువగా సెట్ చేయండి; దానికి సమానంగా ఎప్పుడూ సెట్ చేయవద్దు. ఎందుకంటే cgroup limit process ను ముగిస్తుంది; key ను evict చేయదు. WordPress పక్కన Redis 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లో అదే విలువను మళ్లీ నిల్వ చేయడానికి ప్రయత్నిస్తుంది, కానీ మళ్లీ విఫలమవుతుంది. ఇప్పుడు 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కు ఇది ఖచ్చితంగా సరిపోతుంది, ఎందుకంటే అందులోని ప్రతి విలువ 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ను చాలా తరచుగా access చేస్తే allkeys-lfu సరైన ప్రత్యామ్నాయం. ఇది recencyకు బదులుగా frequency ఆధారంగా eviction చేస్తుంది. ఒక విధానాన్ని ఉద్దేశపూర్వకంగా ఎంచుకుని, దానికి కారణాన్ని నమోదు చేయండి.

Persistence: కారణం ఉంటే తప్ప దీన్ని నిలిపి ఉంచండి

ప్యాకేజీతో వచ్చే redis.conf, save 900 1 వంటి లైన్లతో RDB snapshots ను enable చేస్తుంది. అయితే append-only file ను off లో ఉంచుతుంది. పూర్తిగా 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 తరువాత విఫలమయ్యే అవకాశం ఉందని Redis దీనితో తెలియజేస్తుంది:

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

Snapshots ను off చేయడానికి /etc/redis/redis.conf లో empty save schedule ను సెట్ చేసి, restart చేయండి. తరువాత value మళ్లీ empty గానే ఉందని నిర్ధారించండి.

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 ఏ ప్లగిన్ కోడ్‌ అయినా అమలు కావడానికి ముందే, చాలా ప్రారంభంలో 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 కు అప్పగించండి.

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

ప్లగిన్‌ను తొలగించినా 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, అనేక సైట్‌లు: prefixes మరియు databases

Redis డిఫాల్ట్‌గా పదహారు numbered databases ను అందిస్తుంది. ప్రతి database లో ఒకే flat keyspace ఉంటుంది. prefix లేకుండా database 0 కు అనుసంధానించిన రెండు WordPress installations ఒకే key names ను ఒకే space లో రాస్తాయి. అందువల్ల ఒక site, మరొక site యొక్క options ను చదివి వాటినే అందించవచ్చు. ప్రతి site కు ప్రత్యేక 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 ను కూడా document చేస్తుంది. ఇది మొత్తం database ను తొలగించకుండా, మీ prefix కు సరిపోలే keys ను మాత్రమే తొలగిస్తుంది. అయితే వాటిని కనుగొనడానికి scan చేయాల్సి ఉంటుంది.

prefixలు మరియు indexes వేరు చేయనిది memory. maxmemory మరియు eviction policy మొత్తం instance కు వర్తిస్తాయి. అందువల్ల busy site, quiet site యొక్క keys ను తొలగించబడేలా చేయవచ్చు. ఈ పరిస్థితిని ఏ site కూడా report చేయదు. ఒకదానిపై మరొకటి ప్రభావం చూపకూడని sites కు ప్రత్యేక Redis instances అవసరం. ప్రతి instance కు ప్రత్యేక socket మరియు ప్రత్యేక limit ఉండాలి.

ఉత్పత్తి cache నుండి staging ను వేరు చేయండి

Staging site సాధారణంగా production files మరియు database యొక్క కాపీగా ఉంటుంది. అందువల్ల అదే prefix మరియు అదే database index తో wp-config.php యొక్క కాపీ కూడా అవుతుంది. దాన్ని అదే Redis కు అనుసంధానిస్తే, staging విలువలతో production keys రాయబడతాయి. పరీక్ష కోసం ఇచ్చిన ధర లేదా మార్చిన option ఎటువంటి deploy లేకుండానే, ఎలాంటి trace లేకుండానే 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 అనే line. Drop-in: Valid అంటే WordPress ఈ plugin file ను load చేస్తోంది. Drop-in: Not installed అంటే copy ఎప్పుడూ జరగలేదు. Admin screen ఎంత సరిగ్గా కనిపించినా, site వద్ద persistent cache లేదు. Status connection వివరాలను చూపుతుంది. Client ఉపయోగంలో ఉన్న extension పేరును చూపుతుంది. ఇక్కడ PhpRedis కాకుండా Predis ఉపయోగించబడటం లేదని నిర్ధారించాలి.

తర్వాత 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 కాకుండా వేరే 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 పై, ముందు మరియు తర్వాత కొలిచిన సంఖ్యే ఉపయోగకరం.

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తో పూర్తిగా నిండిన instance ప్రధాన కారణం. ఇది పైన వివరించాం: logలో OOM command not allowed when used memory > 'maxmemory'. కనిపిస్తుంది, అలాగే site 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 మూడో కారణం. పాత 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 చేర్చారు. అందువల్ల modern installలో 'yes' మాత్రమే సరిపోల్చే పాత query తక్కువ విలువను చూపుతుంది. ఒక megabyte దాటితే సమస్య options tableలో పరిష్కరించాలి, Redisలో కాదు.

Restart చేసినప్పుడు మొత్తం cache ఖాళీ అవుతుంది. అందువల్ల systemctl restart redis-server తర్వాతి నిమిషాల్లో అన్ని requests misses అవుతాయి, databaseపై మొత్తం పని పడుతుంది. Traffic తక్కువగా ఉన్నప్పుడు restart చేయండి. Visitor page loads సమయంలో wp-cron.php అమలు కావడాన్ని object cache ఆపదు. అది 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 తో ఉపయోగించడం వల్ల వింత ప్రవర్తన ఏర్పడవచ్చు. 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 తప్పుకోవాల్సిన requests ను object cache నిర్వహిస్తుంది: logged-in users, carts, checkout, మరియు wp-admin. Shop లేదా membership site లో రెండింటినీ నడపడం ప్రయోజనకరం. సందర్శకులు ఎప్పుడూ login చేయని site లో దాదాపు మొత్తం పనిని page cache నిర్వహిస్తుంది.

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

ఇతరుల సంఖ్యను నకలు చేయకుండా మీ స్వంత server ఆధారంగా నిర్ణయించండి. మొత్తం RAM నుంచి MySQL buffer pool మరియు ప్రతి connection కు సంబంధించిన buffers ను తీసివేయండి. తరువాత resident size of one PHP-FPM worker ను pm.max_children తో గుణించి వచ్చిన మొత్తాన్ని తీసివేయండి. 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 సమయంలో connection ద్వారా పంపబడే multi-megabyte autoloaded options value. Remote Redis server విషయంలో ప్రతి request కు వందల round trips కలసి గణనీయమైన ఆలస్యాన్ని కలిగిస్తాయి.

అనేక WordPress sites ఒకే Redis server ను పంచుకోగలవా?

జాగ్రత్తగా నిర్వహిస్తే పంచుకోగలవు. ప్రతి site కు ప్రత్యేకమైన WP_REDIS_PREFIX ఇవ్వండి. అప్పుడు key names పరస్పరం ఢీకొనవు. అలాగే ప్రతి site కు ప్రత్యేకమైన WP_REDIS_DATABASE index ఇవ్వండి. దీంతో ఒక site ను flush చేసినప్పుడు మరొక site ఖాళీ కాదు. అయితే memory మాత్రం పంచుకుంటాయి. 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. ను report చేస్తుంది. Redis పనిచేయకపోతే లేదా తప్పుగా పనిచేస్తే, admin ను చేరుకోలేని emergency పరిస్థితిలో చేతితో file ను తొలగించడం సరైన చర్య.