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

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

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

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

இவை இரண்டையும் ஒன்றாகப் பயன்படுத்தலாம்; அதிக traffic உள்ள தளங்களுக்கு இரண்டுமே அவசியம். நீங்கள் எந்தப் பிரச்சினையைத் தீர்க்கிறீர்கள் என்பதில் தெளிவாக இருங்கள். சாதாரண வாசகர்களைக் கொண்ட ஒரு தளத்திற்கு 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.
• அந்த server-ல் WP-CLI. இங்கே கொடுக்கப்பட்டுள்ள ஒவ்வொரு படிநிலைக்கும் admin-screen-ல் மாற்று வழி உள்ளது, ஆனால் shell பதிப்பு வேகமானது.
• PHP இயங்கும் அதே machine-ல் Redis. Latency-ஐக் குறைப்பதே இதன் நோக்கம், network hop இருந்தால் அதன் பயன் இல்லாமல் போய்விடும்.

கீழே உள்ள கட்டளைகள் PHP 8.3 மற்றும் www-data web user கொண்ட Ubuntu 24.04-க்காக எழுதப்பட்டுள்ளன. உங்கள் server-க்கு ஏற்ப PHP version மற்றும் 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 தொடங்கும்போதே extensions-ஐ ஏற்றிவிடும், எனவே புதிய 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-க்கு போதுமானது. உங்களுக்கு தற்போதைய புதிய பதிப்பு தேவைப்பட்டால், 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-க்கு இணைப்பு ஏற்படுத்தக்கூடிய எவரும் அனைத்து cached மதிப்புகளையும் படிக்க முடியும், மேலும் FLUSHALL-ஐ இயக்க முடியும். இணையத்தில் வெளிப்படையாக இருக்கும் Instances சில மணிநேரங்களிலேயே ஸ்கேனர்களால் கண்டறியப்படும், எனவே tuning செய்வதற்கு முன்பே network அமைப்புகளைச் சரிபார்க்க வேண்டும்.

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

bind 127.0.0.1 -::1
protected-mode yes

பிறகு, உண்மையில் எந்த port-ல் service இயங்குகிறது என்பதைச் சரிபார்க்கவும், ஏனெனில் config கோப்பு ஒரு கோரிக்கை மட்டுமே, ss தான் உண்மையான ஆதாரமாகும்.

sudo ss -lntp | grep 6379

127.0.0.1:6379 என்பது நீங்கள் எதிர்பார்க்கும் வெளியீடு. 0.0.0.0:6379 என்பது Redis பொதுவான interface-ல் பதிலளிக்கிறது என்று பொருள்: bind வரியைச் சரிசெய்து, service-ஐ restart செய்யவும்.

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

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

இந்த socket redis பயனர் மற்றும் குழுவிற்குச் சொந்தமானது, எனவே web பயனர் அந்த குழுவில் சேர வேண்டும்.

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 என்றால் குழு மாற்றம் நடைமுறைக்கு வரவில்லை என்று பொருள். id www-data-ஐச் சரிபார்க்கவும்; இயங்கிக்கொண்டிருக்கும் PHP-FPM அது தொடங்கப்பட்டபோது இருந்த குழு அனுமதிகளைத் தக்கவைத்துக் கொள்ளும் என்பதை நினைவில் கொள்க, அதனால்தான் restart செய்வது அவசியமாகிறது. socket சரியாக வேலை செய்கிறது என்று உறுதிப்படுத்தும் வரை TCP-ஐ அப்படியே வைத்திருக்கவும், இல்லையெனில் தட்டச்சுப் பிழையினால் இரண்டு வழிகளும் துண்டிக்கப்படலாம்.

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

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

மொத்த RAM-லிருந்து மற்றவற்றைக் கழித்து கணக்கிடத் தொடங்குங்கள். MySQL அல்லது MariaDB-க்கு innodb_buffer_pool_size மற்றும் ஒவ்வொரு connection-க்கும் தேவைப்படும் buffer-களை ஒதுக்க வேண்டும். PHP-FPM-க்கு pm.max_children மற்றும் ஒரு worker-ன் உண்மையான resident size-ஐப் பெருக்க வேண்டும்; plugin-கள் அதிகம் உள்ள தளங்களில் இது பொதுவாக 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 cap அமைப்பது, தவறாக 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) ஆகும். நினைவகம் குறையும் போது, நீண்ட காலமாகப் பயன்படுத்தப்படாத key-ஐ Redis நீக்கிவிடும்; object cache-க்கு இதுவே தேவை, ஏனெனில் அதில் உள்ள ஒவ்வொரு மதிப்பும் MySQL-ல் ஏற்கனவே இருக்கும் தரவின் நகலாகும். ஒரு key-ஐ இழப்பது ஒரு query-க்கு மட்டுமே செலவாகும். ஆனால், தரவை எழுத மறுப்பது ஒவ்வொரு கோரிக்கையின் போதும், யாராவது கவனிக்கும் வரை அனைத்து query-களையும் பாதிக்கும்.

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

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

தொகுக்கப்பட்ட redis.conf, save 900 1 போன்ற வரிகள் மூலம் RDB snapshots-ஐ செயல்படுத்துகிறது, மேலும் append-only கோப்பை முடக்கி வைக்கிறது. ஒரு தூய 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 கால அட்டவணையை காலியாக அமைக்கவும், restart செய்யவும், அதன் மதிப்பு காலியாக இருப்பதை உறுதிப்படுத்தவும்.

save ""

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

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

தோல்விச் செய்திகள் எந்தப் பகுதி பாதிக்கப்பட்டது என்பதை உங்களுக்குத் தெரிவிக்கும். Object cache could not be enabled. என்பது நகலெடுக்கும் செயல் தோல்வியடைந்தது என்று பொருள், எனவே WP-CLI-ஐ இயக்கும் பயனரால் wp-content-ல் எழுத முடியவில்லை. 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 பயனருக்கு அதன் உரிமையை வழங்கவும்.

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 directory-ஐ மட்டும் நீக்கினால், plugin-ன் அப்டேட் இன்றி தளம் பழைய cache code-ஐயே தொடர்ந்து இயக்கும்.

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

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

Redis இயல்பாகவே பதினாறு எண்ணிடப்பட்ட databases-ஐ வழங்குகிறது, ஒவ்வொன்றிலும் ஒரு flat keyspace உள்ளது. இரண்டு WordPress தளங்களை prefix இல்லாமல் database 0-க்கு மாற்றினால், அவை ஒரே keyspace-ல் ஒரே மாதிரியான 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-களைத் தேடி ஸ்கேன் செய்ய வேண்டியிருக்கும்.

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

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

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

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

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

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

wp redis status

மிக முக்கியமான வரி Drop-in ஆகும். Drop-in: Valid என்பது WordPress இந்த plugin-ன் கோப்பை ஏற்றுகிறது என்று பொருள். Drop-in: Not installed என்பது கோப்பு நகலெடுக்கப்படவில்லை என்றும், admin திரை பச்சை நிறத்தில் தெரிந்தாலும் தளத்தில் persistent cache இல்லை என்றும் பொருள். 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 அப்போதுதான் நிரம்பத் தொடங்கும். ஒரு சாதாரண போக்குவரத்து நாளில் இதை இயங்க விடவும்.

உங்கள் எண்ணிக்கையை ஒரு 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-ல் வைத்திருங்கள். அதே server-ல் இருக்கும்போது kernel-லிருந்து எவ்வளவு லாபம் கிடைக்கிறது என்பது தனி கேள்வி: Linux 7.2-ல் சேர்க்கப்பட்ட cache aware scheduling, PHP-FPM மற்றும் Redis போன்ற அதிகத் தொடர்புகொள்ளும் process-களை ஒரே cache-ஐப் பகிரும் cores-ல் வைத்திருக்க முயல்கிறது, ஆனால் bare metal-ஐ விட VPS guest-ல் இதன் தாக்கம் குறைவாகவே இருக்கும்.

மிகப்பெரிய autoloaded options table மூன்றாவது காரணம், இது பழைய தளங்களில் பொதுவாகக் காணப்படும். WordPress அனைத்து autoloaded options-களையும் ஒரே key-ஆக cache செய்கிறது, எனவே ஒவ்வொரு request-ன் போதும் ஒரு மெகாபைட் தரவு 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-ல் குறைவான தரவையே காட்டும். ஒரு மெகாபைட்டைத் தாண்டும் எதையும் options table-ல் சரிசெய்ய வேண்டும், Redis-ல் அல்ல.

Restart செய்யும்போது அனைத்தும் காலியாகிவிடும், எனவே systemctl restart redis-server-க்கு பிந்தைய நிமிடங்கள் அனைத்தும் misses மற்றும் database வேலைகளாகவே இருக்கும். traffic குறைவாக இருக்கும்போது restart செய்யவும். மேலும், object cache visitor page loads-ன் போது wp-cron.php தூண்டப்படுவதைத் தடுக்காது, இதுவே மெதுவான request-களுக்குக் காரணமாகிறது: நீங்கள் இங்கே இருக்கும்போதே 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-உடன் இணையும்போது விசித்திரமான செயல்பாடுகளை உருவாக்கக்கூடும். redis-cli --stat மூலம் live server-ஐக் கண்காணிக்கவும்; இது வினாடிக்கு ஒரு வரியை அச்சிடும். redis-cli monitor ஒவ்வொரு கட்டளையையும் அச்சிடும், இது அதிக சுமையுள்ள instance-ல் CPU-வை அதிகம் பயன்படுத்தும். எனவே, ஒரு சிக்கலைச் சரிபார்க்கும் போது சில நொடிகள் மட்டும் இதைப் பயன்படுத்திவிட்டு, பின் நிறுத்திவிடவும்.

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

FAQ

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

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

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

மற்றவர்களின் அளவைப் பின்பற்றாமல், உங்கள் 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 உள்ள தளத்தின் keys-ஐ நீக்கிவிடலாம். ஒன்றையொன்று பாதிக்கக்கூடாத தளங்களுக்குத் தனித்தனி வரம்புகளைக் கொண்ட தனித்தனி Redis instances தேவை.

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

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