WordPress-ல் Redis object cache அமைப்பது எப்படி?

WordPress-க்கு Redis object cache என்ன செய்கிறது

WordPress-க்கான Redis object cache, database query-களின் முடிவுகளை memory-ல் சேமித்து வைக்கிறது. இதனால் அடுத்தடுத்த கோரிக்கைகள் (requests) MySQL-ஐ மீண்டும் அணுகுவதற்குப் பதிலாக, Redis-லிருந்து தகவல்களைப் பெற்றுக்கொள்கின்றன. WordPress-ன் core-ல் ஏற்கனவே ஒரு object cache உள்ளது, WP_Object_Cache, ஆனால் அது PHP memory-ல் மட்டுமே இயங்குகிறது மற்றும் கோரிக்கை முடிந்தவுடன் அந்தத் தரவு நீக்கப்பட்டுவிடும். ஒரு drop-in file-ஐப் பயன்படுத்துவதன் மூலம், அந்த cache-ஐ Redis-உடன் தொடர்பு கொள்ளும் வகையில் மாற்றலாம்; இதனால் ஒரு கோரிக்கையிலிருந்து அடுத்த கோரிக்கைக்குத் தரவு நிலைத்திருக்கும்.

Object caching என்பது page caching அல்ல. இந்த வேறுபாட்டைப் புரிந்துகொள்வது, இந்த வழிகாட்டி உங்களுக்குத் தேவையா என்பதைத் தீர்மானிக்க உதவும். Page cache என்பது ஒரு URL-ன் முழுமையான HTML-ஐச் சேமித்து வைத்து, PHP-ஐ இயக்காமலேயே அதை மீண்டும் வழங்கும். இது Redis செய்யக்கூடிய எதையும் விட வேகமானது, மேலும் இது உள்நுழையாத (logged-in) பார்வையாளர்களுக்குச் சிறப்பாகச் செயல்படும். ஒருவர் உள்நுழைந்தவுடன், வண்டியில் (cart) ஒரு பொருளைச் சேர்த்தவுடன் அல்லது admin பக்கத்தைத் திறந்தவுடன், page cache விலகிவிடும்; அப்போது WordPress முழு கோரிக்கையையும் (bootstrap, plugins, queries) இயக்கும். Object cache அந்த கோரிக்கையைச் செலவு குறைந்ததாக மாற்றுகிறது. Page cache-ஆல் கையாள முடியாத traffic-க்கு இதுவே சிறந்த கருவி: உள்நுழைந்த sessions, carts, checkout, மற்றும் wp-admin. ஒரு WooCommerce கடையில், அதிக செலவு பிடிக்கும் traffic-ல் பெரும்பகுதி இதுவே.

இவை இரண்டையும் ஒன்றாகப் பயன்படுத்தலாம், அதிக traffic உள்ள தளங்களில் இவை இரண்டும் அவசியம். நீங்கள் எந்தப் பிரச்சினையைத் தீர்க்கிறீர்கள் என்பதில் தெளிவாக இருங்கள். அநாமதேய வாசகர்களைக் கொண்ட ஒரு brochure தளம், page cache மூலமே அதன் வேகத்தில் பெரும்பகுதியைப் பெறுகிறது; அதில் Redis-ஐச் சேர்ப்பதால் பெரிய மாற்றம் இருக்காது.

தொடங்குவதற்கு முன் ஒரு முக்கியமான உண்மை. Object cache ஒரு மெதுவான query-ஐ வேகமாக்காது. ஏற்கனவே இயங்கிய ஒரு query மீண்டும் மீண்டும் இயங்குவதைத் தான் இது தவிர்க்கிறது. Cache-ல் இல்லாத ஒரு தரவை முதல்முறை கோரும்போது முழு நேரமும் எடுக்கும், எனவே index செய்யப்படாத query-ஐ இயக்கும் ஒரு plugin, ஒவ்வொரு cache காலத்திலும் ஒருமுறை அந்த 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 இருந்தால் அதன் பயன் கிடைக்காது.

கீழே உள்ள கட்டளைகள் PHP 8.3 மற்றும் www-data web user கொண்ட Ubuntu 24.04-க்காக எழுதப்பட்டுள்ளன. உங்கள் கணினிக்கு ஏற்ப PHP பதிப்பையும் user-ஐயும் மாற்றிக்கொள்ளவும். wp கட்டளைகளை உங்கள் WordPress directory-ல் இருந்து இயக்கவும், அதாவது wp-config.php கோப்பு இருக்கும் இடத்தில் இயக்கவும்.

Redis மற்றும் PHP extension-ஐ நிறுவுதல்

sudo apt update
sudo apt install -y redis-server php-redis
sudo systemctl enable --now redis-server
redis-cli ping

redis-cli ping கட்டளை PONG என்று பதிலளிக்க வேண்டும். அது Could not connect to Redis at 127.0.0.1:6379: Connection refused என்று காட்டினால், server இயங்கவில்லை என்று பொருள்; எனவே மேலும் தொடரும் முன் systemctl status redis-server-ஐப் படிக்கவும்.

php-redis என்பது PECL-லிருந்து பெறப்பட்ட C extension ஆன PhpRedis ஆகும். இது pure PHP-ல் இயங்கும் Predis-ஐ விட வேகமானது; இது இருக்கும்போது plugin தானாகவே இதைப் பயன்படுத்திக்கொள்ளும். PHP-FPM தொடங்கும்போதே extension-களை ஏற்றும், எனவே புதிய extension-ஐச் சேர்த்த பிறகு pool-ஐ restart செய்யும் வரை அது தெரியாது.

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

கடைசி சோதனையின் போது கவனமாக இருக்கவும்: php -m கட்டளையானது command line PHP-ன் modules-களை மட்டுமே பட்டியலிடும், FPM வேறு தொகுப்பை ஏற்றக்கூடும். plugin-ன் சொந்த diagnostics பகுதியில் உள்ள சோதனையே இறுதியானது.

ஆகஸ்ட் 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 உரிம மாற்றத்திற்குப் பிறகு உருவான fork), அதுவும் அதே protocol-ஐப் பயன்படுத்துவதால் கீழே உள்ள அனைத்தும் அப்படியே பொருந்தும்.

Redis-ஐ மற்றவை அணுக முடியாதபடி கட்டுப்படுத்துதல்

Redis-ல் இயல்பாகவே கடவுச்சொல் இருக்காது. port 6379-ல் connection ஏற்படுத்தக்கூடிய எவரும் அனைத்து cached மதிப்புகளையும் படிக்க முடியும், மேலும் FLUSHALL-ஐ இயக்க முடியும். இணையத்தில் வெளிப்படையாக இருக்கும் instances சில மணிநேரங்களிலேயே scanners மூலம் கண்டறியப்படும், எனவே tuning செய்வதற்கு முன்பே network அமைப்புகளைச் சரிபார்க்க வேண்டும்.

/etc/redis/redis.conf-ஐத் திறந்து, பின்வரும் வரிகள் இருப்பதை உறுதிப்படுத்தவும்:

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 பொதுவான interface-ல் பதிலளிக்கிறது என்று பொருள்: bind வரியைச் சரிசெய்து, restart செய்யவும்.

PHP மற்றும் Redis ஒரே server-ல் இருக்கும்போது, loopback TCP-ஐ விட Unix socket சிறந்தது. இதில் TCP stack கிடையாது, மேலும் firewall விதியை விட file permissions மூலம் அணுகல் கட்டுப்படுத்தப்படுகிறது.

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

இந்த socket redis user மற்றும் group-க்கு சொந்தமானது, எனவே web user அந்த group-ல் இணைய வேண்டும்.

sudo systemctl restart redis-server
sudo usermod -aG redis www-data
sudo systemctl restart php8.3-fpm
redis-cli -s /run/redis/redis-server.sock ping

இது PONG என்று காட்ட வேண்டும். Could not connect to Redis at /run/redis/redis-server.sock: Permission denied என்றால் group மாற்றம் நடைமுறைக்கு வரவில்லை என்று பொருள். id www-data-ஐச் சரிபார்க்கவும்; இயங்கிக்கொண்டிருக்கும் PHP-FPM தான் தொடங்கியபோது இருந்த group-களையே வைத்திருக்கும் என்பதை நினைவில் கொள்க, அதனால்தான் restart செய்வது அவசியமாகிறது. Socket சரியாக வேலை செய்கிறது என்று உறுதிப்படுத்தும் வரை TCP-ஐ அப்படியே வைத்திருக்கவும், இல்லையெனில் ஒரு சிறிய பிழை இரண்டு வழிகளையும் துண்டித்துவிடும்.

Redis-க்கு எவ்வளவு memory ஒதுக்க வேண்டும்?

உங்கள் server-ன் அளவை வைத்து இந்த எண்ணிக்கையைத் தீர்மானிக்கவும். maxmemory இல்லாத நிலையில், kernel-ன் memory தீரும் வரை Redis வளர்ந்துகொண்டே இருக்கும். இறுதியில் OOM killer ஒரு process-ஐ முடித்துவிடும்; பொதுவாக அதிக memory பயன்படுத்தும் process-ஐ அது தேர்ந்தெடுக்கும், WordPress server-களில் இது பெரும்பாலும் MySQL ஆக இருக்கும். journalctl -k | grep -i "out of memory" இந்தத் தடையை நிகழ்ந்த பிறகு காட்டும், ஆனால் அதற்குள் தளம் முடங்கியிருக்கும்.

மொத்த RAM-லிருந்து மற்றவற்றைக் கழித்து கணக்கிடத் தொடங்குங்கள். MySQL அல்லது MariaDB-க்கு innodb_buffer_pool_size மற்றும் ஒவ்வொரு connection-க்கும் தேவையான buffer தேவைப்படும். PHP-FPM-க்கு pm.max_children மற்றும் ஒரு worker-ன் உண்மையான resident size-ஐப் பெருக்க வேண்டும்; அதிக plugins கொண்ட தளங்களில் இது பொதுவாக 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-க்குக் கொடுங்கள், அது அதைச் சிறப்பாகப் பயன்படுத்தும். அது வரம்பைத் தொட்டு, evicted_keys நாள் முழுவதும் உயர்ந்துகொண்டே இருந்தால், வரம்பை உயர்த்துங்கள். /etc/redis/redis.conf-ல் மதிப்பை அமைக்கவும்.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb உடனடியாகச் செயல்படும், ஆனால் restart செய்தவுடன் மறந்துவிடும்; இது ஒரு வெறும் sysctl -w-ஐப் பயன்படுத்துவது போன்ற அதே சிக்கலாகும். கோப்பைத் திருத்தி, பின் sudo systemctl restart redis-server செய்து, மதிப்பை மீண்டும் சரிபார்க்கவும். இரண்டாவது பாதுகாப்பு அரண் இருப்பது நல்லது: systemd unit-ல் ஒரு MemoryMax வரம்பு தவறாக configure செய்யப்பட்ட Redis உங்கள் server-ஐ முடக்குவதைத் தடுக்கும். இதை maxmemory-க்கு மேல் அமைக்கவும், ஒருபோதும் சமமாக அமைக்க வேண்டாம்; ஏனெனில் cgroup வரம்பு ஒரு key-ஐ நீக்குவதற்குப் பதிலாக process-ஐயே முடித்துவிடும். Redis ஒரு container-ல் WordPress-க்கு அருகில் இயங்கினால், அதே எண் உங்கள் Compose கோப்பில் உள்ள memory வரம்புகளிலும் இருக்க வேண்டும், மேலும் database-ஐ Docker-ல் அல்லது host-ல் இயக்குவது குறித்த முடிவும் அதே காரணத்தையே அடிப்படையாகக் கொண்டது.

eviction policy-ஐ கவனமாகத் தேர்வு செய்யவும்

புதிதாக நிறுவப்பட்ட Redis-ல் இயல்பாக noeviction இருக்கும். உங்களுடையதைச் சரிபார்க்கவும்:

redis-cli config get maxmemory-policy

noeviction நிலையில் இருக்கும்போது, ஒரு முழு instance-ம் தரவுகளை எழுதுவதை நிறுத்திவிட்டு, பின்வரும் பதிலை அளிக்கும்:

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

இந்த வழிகாட்டியில் உள்ள தோல்விகளில் இதுவே மிக மோசமானது, ஏனெனில் தளம் முழுமையாக முடங்காது. மாறாக, தளம் மெதுவாகும். ஒவ்வொரு cache write-ம் தோல்வியடைவதால், WordPress அந்த மதிப்பைத் தேடி மீண்டும் database-க்குச் செல்லும், பின்னர் அடுத்த கோரிக்கையின்போது மீண்டும் சேமிக்க முயன்று தோல்வியடையும். இப்போது தளம் தனது வழக்கமான database வேலைகளுடன், ஒவ்வொரு key-க்கும் Redis-க்குச் சென்று வரும் கூடுதல் சுமையையும் சுமக்க வேண்டியிருக்கும். WordPress admin பகுதியில் இது நடப்பது குறித்து எந்தத் தகவலும் இருக்காது. இந்தச் செய்தி PHP error log-ல் பதிவாகும், எனவே cache சேர்த்த பிறகு தளம் மெதுவாக இருந்தால் OOM command not allowed என்பதை grep செய்து பார்க்கவும்.

இதற்கு allkeys-lru என்பதே சரியான இயல்புநிலை (default) ஆகும். நினைவகம் குறையும்போது, மிக நீண்ட காலமாகப் பயன்படுத்தப்படாத (least recently used) key-ஐ Redis நீக்கிவிடும். இதுவே object cache-க்குத் தேவையானது, ஏனெனில் அதில் உள்ள ஒவ்வொரு மதிப்பும் MySQL-ல் ஏற்கனவே இருக்கும் தரவின் நகலாகும். ஒரு key-ஐ இழப்பதால் ஒரு query மட்டுமே கூடுதல் சுமையாகும். ஆனால், எழுதுவதை மறுப்பதன் மூலம், யாராவது கவனிக்கும் வரை ஒவ்வொரு கோரிக்கையும் (request) தோல்வியடையும்.

இந்த வேலைக்கு volatile-* கொள்கைகளைத் தவிர்க்கவும். இவை காலாவதி தேதி (expiry) கொண்ட key-களை மட்டுமே கருத்தில் கொள்ளும். எந்தக் key-க்கும் காலாவதி தேதி இல்லாதபோது இவை noeviction போலவே செயல்படும் என்று Redis ஆவணங்கள் கூறுகின்றன. WordPress தனது பெரும்பாலான object cache பதிவுகளை TTL இல்லாமலேயே சேமிக்கிறது, எனவே object cache-ல் volatile-lru-ஐப் பயன்படுத்தினால், நினைவகம் நிரம்பி தரவுகளை எழுத மறுக்கக்கூடும். உங்கள் traffic ஒரு குறிப்பிட்ட சில key-களை அடிக்கடி அணுகினால், allkeys-lfu ஒரு நல்ல மாற்றாகும், ஏனெனில் இது காலத்திற்குப் பதிலாக அடிக்கடி பயன்படுத்தப்படும் அடிப்படையில் key-களை நீக்கும். ஏதேனும் ஒன்றை கவனமாகத் தேர்வு செய்து, அதற்கான காரணத்தைப் பதிவு செய்து வைக்கவும்.

Persistence: உங்களுக்குத் தேவை இல்லையென்றால் இதைத் தவிர்க்கவும்

தொகுக்கப்பட்ட redis.conf, save 900 1 போன்ற வரிகள் மூலம் RDB snapshots-ஐ செயல்படுத்துகிறது, மேலும் append-only file-ஐ முடக்கி வைக்கிறது. ஒரு தூய object cache-க்கு, snapshots-ஆல் எந்தப் பயனும் இல்லை. தரவுகளை மீண்டும் உருவாக்க முடியும் என்பதால், இருபது நிமிடங்களுக்கு முந்தைய கோப்பிலிருந்து மீட்டெடுக்கப்படும் cache, WordPress நம்பக்கூடிய பழைய (stale) மதிப்புகளை மட்டுமே கொண்டிருக்கும்.

Snapshots-க்கு சில செலவுகளும் உண்டு. BGSAVE process-ஐ fork செய்கிறது; copy-on-write நுட்பத்தால், child process எழுதும் போது நினைவகப் பயன்பாடு (memory use) திடீரென அதிகரிக்கலாம். சிறிய VPS-களில் இது Redis log-ல் இவ்வாறு தெரியும்:

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

மேலும், தொடக்கத்தின் போது பெரும்பாலும் இந்த எச்சரிக்கை வரும். 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 செய்யவும். அந்த மதிப்பு காலியாக இருப்பதை உறுதிப்படுத்தவும்.

save ""

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

job queue அல்லது rate-limit counters போன்ற மீண்டும் உருவாக்க முடியாத தரவுகளை ஒரே instance-ல் வைத்திருந்தால் மட்டுமே persistence-ஐப் பயன்படுத்தவும். அவ்வாறு இருந்தால், இரண்டையும் தனித்தனியாகப் பிரிக்கவும். Cache-க்கு keys நீக்கப்பட வேண்டும் (evicted), ஆனால் நீடித்திருக்க வேண்டிய தரவுகளுக்கு 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 கோப்பாகும், இதுவே முக்கிய செயல்பாட்டைச் செய்கிறது. WordPress ஆனது wp-content/object-cache.php கோப்பை மிக ஆரம்பத்திலேயே ஏற்றுகிறது; எந்தவொரு plugin குறியீடும் இயங்குவதற்கு முன்பே இது நடப்பதால், முழு request-க்கும் cache வசதி கிடைக்கிறது. drop-in கோப்பு இல்லாத நிலையில், ஒரு plugin-ஐ active செய்தாலும் அது எதையும் cache செய்யாது.

தோல்விக்கான செய்திகள் எந்தப் பகுதி பாதிக்கப்பட்டுள்ளது என்பதைத் தெரிவிக்கும். Object cache could not be enabled. என்பது நகலெடுக்கும் செயல் தோல்வியடைந்ததைக் குறிக்கிறது; அதாவது WP-CLI இயங்கும் பயனருக்கு wp-content கோப்பகத்தில் எழுதும் அனுமதி (writable) இல்லை. A foreign object cache drop-in was found. என்பது ஏற்கனவே வேறொரு caching plugin அந்த கோப்பின் பெயரைப் பயன்படுத்துகிறது என்று பொருள்; இதற்கு wp redis update-dropin கட்டளையைப் பயன்படுத்தி சரிசெய்யலாம். Redis server is unreachable: என்று முடிவடையும் செய்தியுடன் client error ஏற்பட்டால், connection அமைப்புகள் தவறாக உள்ளன என்று பொருள்; எனவே redis-cli ping பகுதிக்குச் சென்று சரிபார்க்கவும்.

அனுமதி (permissions) காரணமாக நகலெடுக்கும் செயல் தோல்வியடைந்தால், கோப்பை நீங்களே கைமுறையாக நகலெடுத்து, web பயனருக்கு அதன் உரிமையை (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. என்பதை வெளியிட்டு, அந்த கோப்பை நீக்கிவிடும். Drop-in கோப்பு இருக்கும்போது plugin கோப்பகத்தை மட்டும் நீக்கினால், தளம் பழைய cache குறியீட்டையே தொடர்ந்து இயக்கும், ஆனால் அதை மேம்படுத்த எந்த 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-க்கும் ஒரு காலாவதி நேரத்தை வினாடிகளில் கட்டாயமாக்குகிறது. allkeys-lru பயன்படுத்தும் போது இது தேவையில்லை. cache செய்யப்பட்ட மதிப்பு எவ்வளவு பழையதாக இருக்கலாம் என்பதற்கு ஒரு உச்சவரம்பை (hard upper bound) நிர்ணயிக்க விரும்பினால், இது பயனுள்ளதாக இருக்கும்.

ஒரே Redis, பல தளங்கள்: prefixes மற்றும் databases

Redis இயல்பாகவே பதினாறு எண்ணிடப்பட்ட databases-ஐ வழங்குகிறது, ஒவ்வொன்றிலும் ஒரு flat keyspace உள்ளது. இரண்டு WordPress தளங்கள் prefix இல்லாமல் database 0-ஐ பயன்படுத்தினால், அவை ஒரே key பெயர்களை ஒரே இடத்தில் எழுதும். இதனால் ஒரு தளம் மற்றொன்றின் options-ஐ வாசித்து, தவறான தரவை வழங்கக்கூடும். எனவே, ஒவ்வொரு தளத்திற்கும் தனித்தனி prefix-ஐ வழங்கவும்.

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

Prefix என்பது key பெயர்களைப் பிரிக்கிறது. Database index என்பது keyspaces-ஐப் பிரிக்கிறது; இது flush செய்யும்போது முக்கியமானது: ஒரு index-ஐ காலி செய்வது மற்றவற்றை பாதிக்காது. இந்த plugin WP_REDIS_SELECTIVE_FLUSH பற்றியும் குறிப்பிடுகிறது; இது முழு database-ஐயும் அழிப்பதற்குப் பதிலாக, உங்கள் prefix-க்கு பொருந்தும் key-களை மட்டும் நீக்கும். ஆனால், இதற்கு key-களை scan செய்ய வேண்டியிருக்கும்.

Prefix மற்றும் indexes எவற்றைப் பிரிக்காது என்றால், அது memory ஆகும். maxmemory மற்றும் eviction policy ஆகியவை ஒட்டுமொத்த instance-க்கும் பொருந்தும். எனவே, அதிக traffic உள்ள ஒரு தளம், குறைவான பயன்பாடுள்ள தளத்தின் key-களை வெளியேற்றக்கூடும்; இது குறித்து எந்தத் தளமும் எச்சரிக்கை தராது. ஒன்றுக்கொன்று பாதிப்பை ஏற்படுத்தக்கூடாது எனில், ஒவ்வொரு தளத்திற்கும் தனித்தனி Redis instance-களைப் பயன்படுத்த வேண்டும். ஒவ்வொன்றிற்கும் தனித்தனி socket மற்றும் memory limit-ஐ அமைக்கவும்.

Staging-ஐ production cache-லிருந்து தனித்து வைத்தல்

Staging தளம் என்பது பொதுவாக production கோப்புகள் மற்றும் database-ன் நகலாகும். அதாவது, இது wp-config.php-ன் நகலாக இருப்பதால், அதே prefix மற்றும் database index-ஐக் கொண்டிருக்கும். இதை அதே Redis-உடன் இணைத்தால், அது production-ன் keys-களை staging மதிப்புகளைக் கொண்டு மேலெழுதிவிடும் (overwrite). இதனால், deploy செய்யாமலேயே ஒரு சோதனை விலை அல்லது மாற்றப்பட்ட விருப்பத்தேர்வு (option) நேரடித் தளத்தில் (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-ஆல் ஏற்படுகிறதா இல்லையா என்பதை உறுதிப்படுத்த இதுவே வேகமான வழியாகும்.

பழைய tutorial-கள் இதற்கு WP_CACHE_KEY_SALT-ஐப் பயன்படுத்தின. அந்த plugin-ன் readme-ல் இந்த constant நீக்கப்பட்டு (deprecated), அதற்குப் பதிலாக WP_REDIS_PREFIX பயன்படுத்தப்படுவதாகக் குறிப்பிடப்பட்டுள்ளது. எனவே, புதிய பெயரையே பயன்படுத்தவும்.

நம்புவதற்குப் பதிலாக சரிபார்க்கவும்

Plugin-ன் சொந்த diagnostics-ல் இருந்து தொடங்கவும்.

wp redis status

மிகவும் முக்கியமான வரி Drop-in ஆகும். Drop-in: Valid என்பது WordPress இந்த plugin-ன் கோப்பை ஏற்றுகிறது என்று பொருள். Drop-in: Not installed என்பது கோப்பு நகலெடுக்கப்படவில்லை மற்றும் தளத்தில் persistent cache இல்லை என்று பொருள்; admin திரை பச்சை நிறத்தில் தெரிந்தாலும் இதுவே உண்மை. Status இணைப்பைப் பற்றிய தகவலைத் தருகிறது, மேலும் Client பயன்படுத்தப்படும் extension-ன் பெயரைத் தெரிவிக்கிறது; Predis-க்கு பதிலாக PhpRedis பயன்படுத்தப்படுகிறதா என்பதை இங்கே உறுதிப்படுத்தலாம்.

பிறகு, WordPress core-இடம் நேரடியாகக் கேட்கவும், ஏனெனில் plugin என்ன நினைக்கிறது என்பதில் அதற்கு அக்கறையில்லை.

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

நீங்கள் தளத்தில் கிளிக் செய்யும்போது dbsize அதிகரிப்பதுதான் அதற்கான ஆதாரம். சரியான drop-in இருந்தும் keys எண்ணிக்கை பூஜ்ஜியமாக இருந்தால், இணைப்பு அமைதியாகத் தோல்வியடைகிறது அல்லது நீங்கள் நினைக்கும் 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-ன் ஆவணங்கள் அதற்கான சூத்திரத்தை வழங்குகின்றன. அதை இரண்டு எச்சரிக்கைகளுடன் கவனிக்கவும். Counters அதன் கடைசி restart-லிருந்து முழு instance-ஐயும் உள்ளடக்கும், எனவே அது பகிரப்படும் அனைத்து தளங்களையும் பயன்பாடுகளையும் ஒன்றாகக் கணக்கிடும். மேலும், flush அல்லது restart செய்த உடனேயே கிடைக்கும் விகிதத்திற்கு எந்த அர்த்தமும் இல்லை, ஏனெனில் cache இன்னும் நிரம்பிக்கொண்டிருக்கிறது. ஒரு சாதாரண traffic நாள் முழுவதும் அதை இயங்க விடவும்.

உங்கள் எண்ணை ஒரு hosting நிறுவனம் வெளியிடும் hit rate அல்லது query count-உடன் ஒப்பிட வேண்டாம். அவை அந்த நிறுவனத்தின் தளங்களையும் அவற்றின் plugin தொகுப்பையும் விவரிக்கின்றன. உங்களுக்கு முக்கியமான எண், page 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 இரண்டாவது காரணம். WordPress ஒரு request-ல் நூற்றுக்கணக்கான object cache அழைப்புகளைச் செய்கிறது. ஒரு request 500 அழைப்புகளைச் செய்து, ஒவ்வொரு round trip-க்கும் 1 ms எடுத்தால், அது அரை வினாடி காத்திருப்பாகும்; இது local socket-ல் இருக்காது. Redis-ஐ அதே server-ல் அல்லது 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 மதிப்புகளைச் சேர்த்துள்ளது, எனவே 'yes'-ஐ மட்டும் பொருத்தும் பழைய query நவீன install-களில் குறைவான தரவையே காட்டும். ஒரு megabyte-க்கு மேல் உள்ள எதையும் options table-ல் சரிசெய்ய வேண்டும், Redis-ல் அல்ல.

Restart செய்யும்போது அனைத்தும் காலியாகிவிடும், எனவே systemctl restart redis-server-க்கு பிந்தைய நிமிடங்கள் அனைத்தும் misses மற்றும் database வேலைகளாகவே இருக்கும். traffic குறைவாக இருக்கும்போது restart செய்யுங்கள். மேலும், object cache visitor page load-களின் போது wp-cron.php தூண்டப்படுவதைத் தடுக்காது, இதுவே மெதுவான request-களுக்குத் தனி ஆதாரமாகும்: நீங்கள் இங்கே இருக்கும்போதே WP-Cron-ஐ உண்மையான system cron job-க்கு மாற்றவும்.

பராமரிப்பு

விருப்பத்தேர்வுகள் அல்லது தீம் குறியீட்டை மாற்றும் ஒரு deploy-க்கு பிறகு wp cache flush மூலம் cache-ஐ நீக்கவும். ஒரு plugin-ஐ மேம்படுத்திய பிறகு, அந்த drop-in தானாகவே மேம்படுத்தப்படவில்லை என்றால் wp redis update-dropin-ஐ இயக்கவும். ஏனெனில், பழைய plugin பதிப்பின் drop-in புதிய plugin-உடன் இணையும்போது அது விசித்திரமான செயல்பாடுகளுக்கு வழிவகுக்கும். redis-cli --stat மூலம் நேரடி server-ஐ கவனிக்கவும்; இது வினாடிக்கு ஒரு வரியை அச்சிடும். redis-cli monitor ஒவ்வொரு கட்டளையையும் அச்சிடும், மேலும் இது அதிக வேலைப்பளு கொண்ட instance-ல் கணிசமான CPU-ஐப் பயன்படுத்தும். எனவே, ஏதேனும் சிக்கலை மீண்டும் உருவாக்கும்போது சில வினாடிகளுக்கு மட்டும் இதைப் பயன்படுத்திவிட்டு, பின்னர் நிறுத்திவிடவும்.

தெரிந்துகொள்ள வேண்டிய கடைசி எண்: redis-cli info clients என்பது connected_clients-ஐத் தெரிவிக்கிறது. PHP-FPM ஒவ்வொரு worker-க்கும் ஒரு இணைப்பை வைத்திருக்கும், எனவே அந்த எண்ணிக்கை உங்கள் pm.max_children-ஐப் பின்பற்றி இருக்க வேண்டுமே தவிர, அதைவிட பல மடங்கு அதிகமாக இருக்கக்கூடாது. அப்படி அதிகமாக இருந்தால், ஏதோ ஒன்று இணைப்புகளைத் திறந்துவிட்டு அவற்றை மூடாமல் வைத்திருக்கிறது என்று அர்த்தம்.

FAQ

Redis object cache-ஐ பயன்படுத்தினாலும் page cache தேவையா?

ஆம், anonymous traffic-க்கு இது தேவை. Page cache என்பது PHP-ஐ இயக்காமல் சேமிக்கப்பட்ட HTML-ஐ வழங்குகிறது; இது warm object cache-உடன் WordPress-ஐ இயக்குவதை விட எப்போதும் குறைவான வளங்களையே பயன்படுத்தும். Page cache தவிர்க்க வேண்டிய கோரிக்கைகளை (logged-in users, carts, checkout, மற்றும் wp-admin) object cache கையாள்கிறது. ஒரு shop அல்லது membership தளத்தில் இவை இரண்டையும் இயக்குவது பயனுள்ளது. பார்வையாளர்கள் யாரும் login செய்யாத தளங்களில், page cache-ஏ பெரும்பாலான வேலைகளைச் செய்துவிடும்.

WordPress-க்கு Redis-க்கு எவ்வளவு memory ஒதுக்க வேண்டும்?

மற்றவர்களின் அளவைப் பின்பற்றாமல், உங்கள் server-ன் நிலையைப் பொறுத்து முடிவு செய்யுங்கள். மொத்த RAM-லிருந்து, MySQL buffer pool மற்றும் per-connection buffers-ஐக் கழிக்கவும். பிறகு pm.max_children-ஐ ஒரு PHP-FPM worker-ன் resident size-ஆல் பெருக்கி அதைக் கழிக்கவும். Kernel மற்றும் web server-க்காகச் சில நூறு megabytes-ஐக் கழிக்கவும். மீதமுள்ளதில் ஒரு பகுதியை Redis-க்கு ஒதுக்கிவிட்டு, ஒரு நாள் traffic-க்குப் பிறகு redis-cli info memory-ல் used_memory_human-ஐச் சரிபார்த்து மாற்றங்களைச் செய்யவும். ஒரு WordPress தளம் பொதுவாகச் சில பத்து megabytes-லேயே இயங்கும், எனவே 4 GB server-ல் 256 MB maxmemory என்பது தாராளமான தொடக்கமாகும்.

Redis object cache-ஐ இயக்கிய பிறகு ஏன் தளம் மெதுவாகிறது?

பொதுவாக, noeviction policy-ல் இயங்கும் instance நிரம்பிவிடுவதே இதற்குக் காரணம். Redis புதிய பதிவுகளை ஏற்க மறுத்து OOM command not allowed when used memory > 'maxmemory'.-ஐத் தரும்போது, WordPress ஒவ்வொரு மதிப்பிற்கும் database-ஐ நாட வேண்டியிருக்கும், அத்துடன் வீணான Redis round trip-ம் சேரும். redis-cli config get maxmemory-policy-ஐச் சரிபார்த்து, allkeys-lru-ஐ அமைத்து, maxmemory மிகச்சிறியதாக இல்லை என்பதை உறுதிப்படுத்தவும். மற்ற பொதுவான காரணங்கள்: remote host-ல் உள்ள Redis server (ஒவ்வொரு கோரிக்கைக்கும் நூற்றுக்கணக்கான round trips சேரும்), மற்றும் ஒவ்வொரு கோரிக்கையிலும் connection வழியாகச் செல்லும் பல megabytes அளவுள்ள autoloaded options.

பல WordPress தளங்கள் ஒரே Redis server-ஐப் பகிர முடியுமா?

கவனத்துடன் பகிரலாம். ஒவ்வொரு தளத்திற்கும் தனித்துவமான WP_REDIS_PREFIX-ஐ வழங்கவும், அப்போதுதான் key பெயர்கள் ஒன்றோடொன்று மோதாது. மேலும், தனித்தனி WP_REDIS_DATABASE index-ஐப் பயன்படுத்தவும், அப்போதுதான் ஒரு தளத்தின் cache-ஐ அழிக்கும்போது மற்றொன்று பாதிக்கப்படாது. ஆனால் அவை memory-ஐப் பகிர்கின்றன: maxmemory மற்றும் eviction ஆகியவை முழு instance-க்கும் பொருந்தும், எனவே அதிக traffic உள்ள தளம், குறைந்த traffic உள்ள தளத்தின் key-களை நீக்கிவிடலாம். ஒன்றையொன்று பாதிக்கக்கூடாத தளங்களுக்குத் தனித்தனி Redis instances மற்றும் அவற்றுக்கெனத் தனித்தனி வரம்புகள் தேவை.

wp-content/object-cache.php-ஐ நீக்குவது பாதுகாப்பானதா?

ஆம். இது ஒரு drop-in கோப்பு, WordPress core-ன் பகுதி அல்ல. இதை நீக்கினால் WordPress அதன் built-in per-request cache-க்குத் திரும்பிவிடும். தளம் தொடர்ந்து இயங்கும், ஆனால் database queries அதிகமாகும். wp redis disable-ஐப் பயன்படுத்த முன்னுரிமை கொடுங்கள், இது கோப்பைச் சரியாக நீக்கி Object cache disabled.-ஐத் தெரிவிக்கும். Redis செயலிழந்தாலோ அல்லது சரியாகச் செயல்படாவிட்டாலோ, உங்களால் admin பகுதியை அணுக முடியாவிட்டால், கைமுறையாக நீக்குவது சரியான அவசரக்கால நடவடிக்கையாகும்.