NGINX-ൽ എങ്ങനെ ഉള്ളടക്കം കാഷെ ചെയ്യാം
NGINX ഒരു ഏകീകൃത ഓപ്പൺ സോഴ്uസ്, ഉയർന്ന പ്രകടനമുള്ള വെബ് സെർവറാണ്, അത് ഉള്ളടക്കവും ആപ്ലിക്കേഷൻ ഡെലിവറിയും വേഗത്തിലാക്കുകയും സുരക്ഷ വർദ്ധിപ്പിക്കുകയും സ്കേലബിളിറ്റി മെച്ചപ്പെടുത്തുകയും ചെയ്യുന്നു. Nginx-ന്റെ ഏറ്റവും സാധാരണമായ ഉപയോഗ കേസുകളിൽ ഒന്ന് ഉള്ളടക്ക കാഷിംഗ് ആണ്, ഇത് ഒരു വെബ്uസൈറ്റിന്റെ പ്രകടനം വർദ്ധിപ്പിക്കുന്നതിനുള്ള ഏറ്റവും ഫലപ്രദമായ മാർഗമാണ്.
അപ്uസ്uട്രീം സെർവറുകളിൽ നിന്നുള്ള കാഷെ പ്രതികരണങ്ങളിലേക്ക് കോൺഫിഗർ ചെയ്uത് ലോക്കൽ ഒറിജിൻ സെർവറുകൾ ത്വരിതപ്പെടുത്തുന്നതിനും ഉള്ളടക്ക ഡെലിവറി നെറ്റ്uവർക്കുകൾക്കായി (സിഡിഎൻ) എഡ്ജ് സെർവറുകൾ സൃഷ്uടിക്കുന്നതിനും നിങ്ങൾക്ക് NGINX ഉപയോഗിക്കാം. NGINX ഏറ്റവും വലിയ ചില CDN-കൾക്ക് ശക്തി നൽകുന്നു.
ഒരു കാഷെ ആയി കോൺഫിഗർ ചെയ്യുമ്പോൾ, NGINX ഇനിപ്പറയുന്നവ ചെയ്യും:
- കാഷെ സ്റ്റാറ്റിക്, ഡൈനാമിക് ഉള്ളടക്കം.
- മൈക്രോ-കാഷിംഗ് ഉപയോഗിച്ച് ഡൈനാമിക് ഉള്ളടക്ക പ്രകടനം മെച്ചപ്പെടുത്തുക.
- മെച്ചപ്പെട്ട പ്രകടനത്തിനായി പശ്ചാത്തലത്തിൽ വീണ്ടും മൂല്യനിർണ്ണയം നടത്തുമ്പോൾ പഴകിയ ഉള്ളടക്കം നൽകുക.
- കാഷെ-നിയന്ത്രണ തലക്കെട്ടുകൾ അസാധുവാക്കുകയോ സജ്ജമാക്കുകയോ ചെയ്യുക.
ഈ ലേഖനത്തിൽ, നിങ്ങളുടെ വെബ് സെർവറുകൾ കഴിയുന്നത്ര കാര്യക്ഷമമായി പ്രവർത്തിപ്പിക്കുന്നതിന് ലിനക്സിലെ ഒരു ഉള്ളടക്ക കാഷിംഗ് ആയി NGINX എങ്ങനെ കോൺഫിഗർ ചെയ്യാമെന്ന് നിങ്ങൾ പഠിക്കും.
നിങ്ങളുടെ Linux സെർവറിൽ NGINX ഇൻസ്റ്റാൾ ചെയ്തിരിക്കണം, ഇല്ലെങ്കിൽ Nginx ഇൻസ്റ്റാൾ ചെയ്യാൻ ഈ ഗൈഡുകൾ പിന്തുടരുക:
- CentOS 8-ൽ Nginx എങ്ങനെ ഇൻസ്റ്റാൾ ചെയ്യാം
- CentOS 7-ൽ Nginx എങ്ങനെ ഇൻസ്റ്റാൾ ചെയ്യാം
Nginx-ൽ കാഷെ സ്റ്റാറ്റിക് ഉള്ളടക്കം
പേജുകളിൽ ഉടനീളം ഒരേപോലെയുള്ള (മാറ്റം വരുത്താത്ത) ഒരു വെബ്uസൈറ്റിന്റെ ഉള്ളടക്കമാണ് സ്റ്റാറ്റിക് ഉള്ളടക്കം. സ്റ്റാറ്റിക് ഉള്ളടക്കത്തിന്റെ ഉദാഹരണങ്ങളിൽ ചിത്രങ്ങൾ, വീഡിയോകൾ, പ്രമാണങ്ങൾ എന്നിവ പോലുള്ള ഫയലുകൾ ഉൾപ്പെടുന്നു; CSS ഫയലുകളും JavaScript ഫയലുകളും.
നിങ്ങളുടെ വെബ്uസൈറ്റ് ധാരാളം സ്റ്റാറ്റിക് ഉള്ളടക്കം ഉപയോഗിക്കുകയാണെങ്കിൽ, വേഗത്തിലുള്ള ആക്uസസിനായി ബ്രൗസർ സ്റ്റാറ്റിക് ഉള്ളടക്കത്തിന്റെ പകർപ്പുകൾ സംഭരിക്കുന്ന ക്ലയന്റ്-സൈഡ് കാഷിംഗ് പ്രവർത്തനക്ഷമമാക്കുന്നതിലൂടെ നിങ്ങൾക്ക് അതിന്റെ പ്രകടനം ഒപ്റ്റിമൈസ് ചെയ്യാൻ കഴിയും.
ഇനിപ്പറയുന്ന സാമ്പിൾ കോൺഫിഗറേഷൻ നല്ലതാണ്, www.example.com നിങ്ങളുടെ വെബ്uസൈറ്റ് പേരിന്റെ URL ഉപയോഗിച്ച് മാറ്റി പകരം മറ്റ് പാത്ത്uനാമങ്ങളിൽ ഉചിതമായ മാറ്റങ്ങൾ വരുത്തുക.
server {
# substitute your web server's URL for www.example.com
server_name www.example.com;
root /var/www/example.com/htdocs;
index index.php;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
try_files $uri =404;
include fastcgi_params;
# substitute the socket, or address and port, of your WordPress server
fastcgi_pass unix:/var/run/php5-fpm.sock;
#fastcgi_pass 127.0.0.1:9000;
}
location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg
|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid
|midi|wav|bmp|rtf)$ {
expires max;
log_not_found off;
access_log off;
}
}
Nginx-ൽ കാഷെ ഡൈനാമിക് ഉള്ളടക്കം
ലോക്കൽ ഫയൽ സിസ്റ്റത്തിൽ എവിടെയോ സ്ഥിതിചെയ്യുന്ന ഒരു സ്ഥിരമായ ഡിസ്ക് അധിഷ്ഠിത കാഷെ NGINX ഉപയോഗിക്കുന്നു. അതിനാൽ കാഷെ ചെയ്ത ഉള്ളടക്കം സംഭരിക്കുന്നതിന് ലോക്കൽ ഡിസ്ക് ഡയറക്ടറി സൃഷ്ടിച്ചുകൊണ്ട് ആരംഭിക്കുക.
# mkdir -p /var/cache/nginx
അടുത്തതായി, കാഷെ ഡയറക്ടറിയിൽ ഉചിതമായ ഉടമസ്ഥാവകാശം സജ്ജമാക്കുക. ഇത് ഇനിപ്പറയുന്ന രീതിയിൽ NGINX ഉപയോക്താവിന്റെയും (nginx) ഗ്രൂപ്പിന്റെയും (nginx) ഉടമസ്ഥതയിലായിരിക്കണം.
# chown nginx:nginx /var/cache/nginx
ചുവടെയുള്ള വിഭാഗത്തിൽ Nginx-ൽ ഡൈനാമിക് ഉള്ളടക്കം എങ്ങനെ പ്രവർത്തനക്ഷമമാക്കാം എന്നറിയാൻ ഇപ്പോൾ മുന്നോട്ട് പോകുക.
NGINX-ൽ FastCGI കാഷെ പ്രവർത്തനക്ഷമമാക്കുന്നു
FastCGI (അല്ലെങ്കിൽ FCGI) എന്നത് NGINX പോലുള്ള വെബ് സെർവറുകളുമായി PHP പോലുള്ള ഇന്ററാക്ടീവ് ആപ്ലിക്കേഷനുകൾ ഇന്റർഫേസ് ചെയ്യുന്നതിനായി വ്യാപകമായി ഉപയോഗിക്കുന്ന ഒരു പ്രോട്ടോക്കോൾ ആണ്. ഇത് CGI യുടെ (കോമൺ ഗേറ്റ്uവേ ഇന്റർഫേസ്) വിപുലീകരണമാണ്.
FCGI-യുടെ പ്രധാന നേട്ടം, അത് ഒരു പ്രക്രിയയിൽ ഒന്നിലധികം CGI അഭ്യർത്ഥനകൾ കൈകാര്യം ചെയ്യുന്നു എന്നതാണ്. ഇത് കൂടാതെ, ഒരു സേവനത്തിനായുള്ള ഓരോ ക്ലയന്റ് അഭ്യർത്ഥനയ്uക്കും വെബ്uസെർവർ ഒരു പുതിയ പ്രോസസ്സ് തുറക്കേണ്ടതുണ്ട് (അത് നിയന്ത്രിക്കുകയും ഒരു അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യുകയും അടയ്ക്കുകയും വേണം).
ഒരു LEMP സ്റ്റാക്ക് വിന്യാസത്തിൽ PHP സ്ക്രിപ്റ്റുകൾ പ്രോസസ്സ് ചെയ്യുന്നതിന്, NGINX FPM (FastCGI പ്രോസസ് മാനേജർ) അല്ലെങ്കിൽ PHP-FPM ഉപയോഗിക്കുന്നു, ഇത് ഒരു ജനപ്രിയ PHP FastCGI നടപ്പിലാക്കുന്നു. പിuഎച്ച്uപി-എഫ്uപിuഎം പ്രോസസ്സ് പ്രവർത്തിച്ചുകഴിഞ്ഞാൽ, പ്രോസസ്സിംഗിനായി പ്രോക്സി അഭ്യർത്ഥനകളിലേക്ക് NGINX കോൺഫിഗർ ചെയ്യപ്പെടുന്നു. അങ്ങനെ PHP-FPM ബാക്കെൻഡ് ആപ്ലിക്കേഷൻ സെർവറിൽ നിന്നുള്ള കാഷെ പ്രതികരണങ്ങളിലേക്കും NGINX കോൺഫിഗർ ചെയ്യാവുന്നതാണ്.
NGINX-ന് കീഴിൽ, NGINX കോൺഫിഗറേഷൻ ഘടനയ്ക്കുള്ളിൽ, ഉയർന്ന തലത്തിലുള്ള http{} സന്ദർഭത്തിൽ fastcgi_cache_path എന്ന നിർദ്ദേശം ഉപയോഗിച്ചാണ് FastCGI ഉള്ളടക്ക കാഷെ പ്രഖ്യാപിക്കുന്നത്. കാഷിംഗിനായി ഒരു കീ (അഭ്യർത്ഥന ഐഡന്റിഫയർ) നിർവ്വചിക്കുന്ന fastcgi_cache_key നിങ്ങൾക്ക് ചേർക്കാനും കഴിയും.
കൂടാതെ, അപ്uസ്uട്രീം കാഷെ സ്റ്റാറ്റസ് വായിക്കാൻ, http{} സന്ദർഭത്തിനുള്ളിൽ add_header X-Cache-Status നിർദ്ദേശം ചേർക്കുക – ഇത് ഡീബഗ്ഗിംഗ് ആവശ്യങ്ങൾക്ക് ഉപയോഗപ്രദമാണ്.
നിങ്ങളുടെ സൈറ്റിന്റെ സെർവർ ബ്ലോക്ക് കോൺഫിഗറേഷൻ ഫയൽ സ്ഥിതി ചെയ്യുന്നത് /etc/nginx/conf.d/testapp.conf അല്ലെങ്കിൽ /etc/nginx/sites-available/testapp.conf (ഉബുണ്ടുവിനും അതിന്റെ ഡെറിവേറ്റീവുകൾക്കും കീഴിൽ), എഡിറ്റിംഗ് ഫയൽ തുറന്ന് ചേർക്കുക ഫയലിന്റെ മുകളിൽ ഇനിപ്പറയുന്ന വരികൾ.
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=CACHEZONE:10m; inactive=60m max_size=40m; fastcgi_cache_key "$scheme$request_method$host$request_uri"; add_header X-Cache $upstream_cache_status;
fastcgi_cache_path നിർദ്ദേശം പരാമീറ്ററുകളുടെ എണ്ണം വ്യക്തമാക്കുന്നു:
- /var/cache/nginx – കാഷെയ്ക്കുള്ള ലോക്കൽ ഡിസ്ക് ഡയറക്ടറിയിലേക്കുള്ള പാത.
- ലെവലുകൾ - ഒരു കാഷെയുടെ ഹൈറാർക്കി ലെവലുകൾ നിർവചിക്കുന്നു, അത് /var/cache/nginx ന് കീഴിൽ രണ്ട്-ലെവൽ ഡയറക്uടറി ശ്രേണി സജ്ജീകരിക്കുന്നു.
- keys_zone (name:size) - എല്ലാ സജീവ കീകളും ഡാറ്റ (മെറ്റാ) സംബന്ധിച്ച വിവരങ്ങളും സംഭരിച്ചിരിക്കുന്ന ഒരു പങ്കിട്ട മെമ്മറി സോൺ സൃഷ്ടിക്കുന്നത് പ്രവർത്തനക്ഷമമാക്കുന്നു. മെമ്മറിയിൽ കീകൾ സംഭരിക്കുന്നത്, ഡിസ്കിലെ സ്റ്റാറ്റസ് പരിശോധിക്കാതെ തന്നെ, NGINX-ന് മിസ്സ് ആണോ HIT ആണോ എന്ന് നിർണ്ണയിക്കുന്നത് എളുപ്പമാക്കുന്നതിലൂടെ, പരിശോധനാ പ്രക്രിയയെ വേഗത്തിലാക്കുന്നു.
- നിഷ്uക്രിയം - കാഷെയിൽ നിന്ന് അവയുടെ പുതുമ കണക്കിലെടുക്കാതെ, വ്യക്തമാക്കിയ സമയത്ത് ആക്uസസ് ചെയ്യപ്പെടാത്ത കാഷെ ചെയ്uത ഡാറ്റ എത്ര സമയത്തിന് ശേഷം ഇല്ലാതാക്കപ്പെടും എന്ന് വ്യക്തമാക്കുന്നു. ഞങ്ങളുടെ ഉദാഹരണ കോൺഫിഗറേഷനിലെ 60m മൂല്യം അർത്ഥമാക്കുന്നത് 60-ന് ശേഷം ആക്uസസ് ചെയ്യാത്ത ഫയലുകൾ കാഷെയിൽ നിന്ന് നീക്കം ചെയ്യപ്പെടും എന്നാണ്.
- max_size – കാഷെയുടെ പരമാവധി വലുപ്പം വ്യക്തമാക്കുന്നു. നിങ്ങൾക്ക് ഇവിടെ ഉപയോഗിക്കാനാകുന്ന കൂടുതൽ പാരാമീറ്ററുകൾ ഉണ്ട് (കൂടുതൽ വിവരങ്ങൾക്ക് NGINX ഡോക്യുമെന്റേഷൻ വായിക്കുക).
fastcgi_cache_key നിർദ്ദേശത്തിലെ വേരിയബിളുകൾ ചുവടെ വിവരിച്ചിരിക്കുന്നു.
ഒരു അഭ്യർത്ഥനയുടെ കീ (ഐഡന്റിഫയർ) കണക്കാക്കുന്നതിൽ NGINX അവ ഉപയോഗിക്കുന്നു. പ്രധാനമായും, ക്ലയന്റിലേക്ക് ഒരു കാഷെ ചെയ്ത പ്രതികരണം അയയ്uക്കുന്നതിന്, അഭ്യർത്ഥനയ്uക്ക് കാഷെ ചെയ്uത പ്രതികരണത്തിന്റെ അതേ കീ ഉണ്ടായിരിക്കണം.
- $സ്കീം - അഭ്യർത്ഥന സ്കീം, HTTP അല്ലെങ്കിൽ HTTPS.
- $request_method – അഭ്യർത്ഥന രീതി, സാധാരണയായി \GET അല്ലെങ്കിൽ \POST.
- $host – ഇത് അഭ്യർത്ഥന ലൈനിൽ നിന്നുള്ള ഹോസ്റ്റ്നാമം ആകാം, അല്ലെങ്കിൽ \ഹോസ്റ്റ് അഭ്യർത്ഥന തലക്കെട്ട് ഫീൽഡിൽ നിന്നുള്ള ഹോസ്റ്റ്നാമം അല്ലെങ്കിൽ മുൻഗണനാ ക്രമത്തിൽ ഒരു അഭ്യർത്ഥനയുമായി പൊരുത്തപ്പെടുന്ന സെർവർ പേര്.
- $request_uri – അർത്ഥമാക്കുന്നത് പൂർണ്ണമായ യഥാർത്ഥ അഭ്യർത്ഥന URI (ആർഗ്യുമെന്റുകളോടെ) എന്നാണ്.
കൂടാതെ, add_header X-Cache-Status ഡയറക്uടീവിലെ $upstream_cache_status വേരിയബിൾ NGINX പ്രതികരിക്കുന്ന ഓരോ അഭ്യർത്ഥനയ്ക്കും കണക്കാക്കുന്നു, അത് ഒരു മിസ്സ് ആണെങ്കിലും (പ്രതികരണം കാഷെയിൽ കണ്ടെത്തിയില്ല, ആപ്ലിക്കേഷൻ സെർവറിൽ നിന്ന് ലഭിച്ചത്) അല്ലെങ്കിൽ ഒരു HIT (കാഷെയിൽ നിന്നുള്ള പ്രതികരണം) അല്ലെങ്കിൽ പിന്തുണയ്ക്കുന്ന മറ്റേതെങ്കിലും മൂല്യങ്ങൾ.
അടുത്തതായി, PHP-FPM-ലേക്ക് PHP അഭ്യർത്ഥനകൾ കൈമാറുന്ന ലൊക്കേഷൻ നിർദ്ദേശത്തിനുള്ളിൽ, നിങ്ങൾ മുകളിൽ നിർവചിച്ച കാഷെ സജീവമാക്കുന്നതിന് fastcgi_cache നിർദ്ദേശങ്ങൾ ഉപയോഗിക്കുന്നു.
കാണിച്ചിരിക്കുന്നതുപോലെ fastcgi_cache_valid നിർദ്ദേശം ഉപയോഗിച്ച് വ്യത്യസ്ത പ്രതികരണങ്ങൾക്കായി കാഷിംഗ് സമയവും സജ്ജമാക്കുക.
fastcgi_cache CACHEZONE; fastcgi_cache_valid 60m;
ഞങ്ങളുടെ കാര്യത്തിലെന്നപോലെ കാഷിംഗ് സമയം മാത്രമേ വ്യക്തമാക്കിയിട്ടുള്ളൂവെങ്കിൽ, 200, 301, 302 പ്രതികരണങ്ങൾ മാത്രമേ കാഷെ ചെയ്യുകയുള്ളൂ. എന്നാൽ നിങ്ങൾക്ക് പ്രതികരണങ്ങൾ വ്യക്തമായി വ്യക്തമാക്കാനും അല്ലെങ്കിൽ ഏതെങ്കിലും (ഏത് പ്രതികരണ കോഡിനും) ഉപയോഗിക്കാനും കഴിയും:
fastcgi_cache CACHEZONE; fastcgi_cache_valid 200 301 203 60m; fastcgi_cache_valid 404 10m; OR fastcgi_cache CACHEZONE; fastcgi_cache_valid any 10m;
Nginx-ൽ ഫൈൻ-ട്യൂണിംഗ് FastCGI കാഷിംഗ് പ്രകടനം
പ്രതികരണം കാഷെ ചെയ്യുന്നതിനുമുമ്പ് ഒരേ കീ ഉപയോഗിച്ച് ഒരു അഭ്യർത്ഥന നടത്തേണ്ട ഏറ്റവും കുറഞ്ഞ എണ്ണം സജ്ജീകരിക്കാൻ, fastcgi_cache_min_uses നിർദ്ദേശം ഉൾപ്പെടുത്തുക, ഒന്നുകിൽ http{} അല്ലെങ്കിൽ >സെർവർ{} അല്ലെങ്കിൽ ലൊക്കേഷൻ{} സന്ദർഭം.
fastcgi_cache_min_uses 3
\If-modified-Since, \If-None-Match എന്നീ ഹെഡർ ഫീൽഡുകൾ ഉപയോഗിച്ച് സോപാധികമായ അഭ്യർത്ഥനകൾ ഉപയോഗിച്ച് കാലഹരണപ്പെട്ട കാഷെ ഇനങ്ങളുടെ വീണ്ടും മൂല്യനിർണ്ണയം പ്രവർത്തനക്ഷമമാക്കാൻ, സെർവർ{} അല്ലെങ്കിൽ ലൊക്കേഷൻ{} സന്ദർഭം.
fastcgi_cache_revalidate on;
ഒറിജിൻ സെർവറോ FCGI സെർവറോ പ്രവർത്തനരഹിതമാകുമ്പോൾ, ലൊക്കേഷൻ നിർദ്ദേശത്തിനുള്ളിൽ proxy_cache_use_stale നിർദ്ദേശം ഉപയോഗിച്ച്, കാഷെ ചെയ്uത ഉള്ളടക്കം നൽകാൻ നിങ്ങൾക്ക് NGINX-ന് നിർദ്ദേശം നൽകാനും കഴിയും.
ഈ സാമ്പിൾ കോൺഫിഗറേഷൻ അർത്ഥമാക്കുന്നത്, അപ്uസ്uട്രീം സെർവറിൽ നിന്ന് NGINX-ന് ഒരു പിശക്, കാലഹരണപ്പെടൽ, കൂടാതെ ഏതെങ്കിലും നിർദ്ദിഷ്ട പിശകുകൾ എന്നിവ ലഭിക്കുകയും കാഷെ ചെയ്uത ഉള്ളടക്കത്തിൽ അഭ്യർത്ഥിച്ച ഫയലിന്റെ പഴകിയ പതിപ്പ് ഉണ്ടെങ്കിൽ, അത് പഴയ ഫയൽ ഡെലിവർ ചെയ്യുന്നു എന്നാണ്.
proxy_cache_use_stale error timeout http_500;
FCGI കാഷിംഗ് പ്രകടനം മികച്ചതാക്കുന്നതിനുള്ള മറ്റൊരു ഉപയോഗപ്രദമായ നിർദ്ദേശം fastcgi_cache_background_update ആണ്, ഇത് proxy_cache_use_stale നിർദ്ദേശവുമായി സംയോജിച്ച് പ്രവർത്തിക്കുന്നു. ഓണായി സജ്ജീകരിക്കുമ്പോൾ, കാലഹരണപ്പെട്ടതോ അപ്uസ്uട്രീം സെർവറിൽ നിന്ന് അപ്uഡേറ്റ് ചെയ്യുന്ന പ്രക്രിയയിലോ ആയ ഒരു ഫയലിനായി ക്ലയന്റ്uസ് അഭ്യർത്ഥിക്കുമ്പോൾ പഴകിയ ഉള്ളടക്കം നൽകാൻ ഇത് NGINX-നോട് നിർദ്ദേശിക്കുന്നു.
fastcgi_cache_background_update on;
fastcgi_cache_lock കാഷെ പെർഫോമൻസ് ഫൈൻ-ട്യൂണിംഗിനും ഉപയോഗപ്രദമാണ്, കാഷെയിൽ ഇല്ലാത്ത ഒരേ ഉള്ളടക്കത്തിനായി ഒന്നിലധികം ക്ലയന്റുകൾ അഭ്യർത്ഥിച്ചാൽ, NGINX ആദ്യ അഭ്യർത്ഥന മാത്രമേ അപ്uസ്ട്രീം സെർവറിലേക്ക് കൈമാറുകയുള്ളൂ, കാഷെ പ്രതികരണം തുടർന്ന് കാഷെയിൽ നിന്നുള്ള മറ്റ് ക്ലയന്റ് അഭ്യർത്ഥനകൾ നൽകുക.
fastcgi_cache_lock on;
NGINX കോൺഫിഗറേഷൻ ഫയലിൽ മുകളിലുള്ള എല്ലാ മാറ്റങ്ങളും വരുത്തിയ ശേഷം, അത് സംരക്ഷിച്ച് അടയ്ക്കുക. NGINX സേവനം പുനരാരംഭിക്കുന്നതിന് മുമ്പ് ഏതെങ്കിലും വാക്യഘടന പിശകുകൾക്കായി കോൺഫിഗറേഷൻ ഘടന പരിശോധിക്കുക.
# nginx -t # systemctl restart nginx
അടുത്തതായി, കാഷെ ശരിയായി പ്രവർത്തിക്കുന്നുണ്ടോയെന്ന് പരിശോധിക്കുക, ഇനിപ്പറയുന്ന curl കമാൻഡ് ഉപയോഗിച്ച് നിങ്ങളുടെ വെബ് ആപ്ലിക്കേഷനോ സൈറ്റോ ആക്സസ് ചെയ്യാൻ ശ്രമിക്കുക (ആദ്യ തവണ ഒരു MISS സൂചിപ്പിക്കണം, എന്നാൽ തുടർന്നുള്ള അഭ്യർത്ഥനകൾ സ്ക്രീൻഷോട്ടിൽ കാണിച്ചിരിക്കുന്നതുപോലെ ഒരു HIT സൂചിപ്പിക്കണം).
# curl -I http://testapp.linux-console.net
എൻuജിuഎൻuഎക്സ് പഴകിയ ഡാറ്റ നൽകുന്നതായി കാണിക്കുന്ന മറ്റൊരു സ്ക്രീൻഷോട്ട് ഇതാ.
ബൈപാസ് കാഷെയിലേക്ക് ഒഴിവാക്കലുകൾ ചേർക്കുന്നു
fastcgi_cache_bypass നിർദ്ദേശം ഉപയോഗിച്ച് NGINX ക്ലയന്റുകൾക്ക് കാഷെ ചെയ്ത പ്രതികരണങ്ങൾ അയയ്uക്കാൻ പാടില്ലാത്ത വ്യവസ്ഥകൾ സജ്ജമാക്കാൻ സാധിക്കും. അപ്uസ്ട്രീം സെർവറിൽ നിന്നുള്ള പ്രതികരണങ്ങൾ കാഷെ ചെയ്യരുതെന്ന് NGINX-ന് നിർദ്ദേശം നൽകുന്നതിന്, fastcgi_no_cache ഉപയോഗിക്കുക.
ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് POST അഭ്യർത്ഥനകളും URL-കളും ഒരു അന്വേഷണ സ്uട്രിംഗും വേണമെന്നുണ്ടെങ്കിൽ, എപ്പോഴും PHP-യിലേക്ക് പോകുക. ആദ്യം, കണ്ടീഷൻ ഇനിപ്പറയുന്ന രീതിയിൽ സജ്ജീകരിക്കുന്നതിന് if സ്റ്റേറ്റ്മെന്റ് പ്രഖ്യാപിക്കുക.
set $skip_cache 0;
if ($request_method = POST) {
set $skip_cache 1;
}
തുടർന്ന് fastcgi_cache_bypass, fastcgi_no_cache നിർദ്ദേശങ്ങൾ ഉപയോഗിച്ച് PHP-FPM-ലേക്ക് PHP അഭ്യർത്ഥനകൾ കൈമാറുന്ന location നിർദ്ദേശത്തിൽ മുകളിലുള്ള ഒഴിവാക്കൽ സജീവമാക്കുക.
fastcgi_cache_bypass $skip_cache; fastcgi_no_cache $skip_cache;
ഉള്ളടക്ക കാഷിംഗ് പ്രവർത്തനക്ഷമമാക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കാത്ത മറ്റ് നിരവധി ഭാഗങ്ങൾ നിങ്ങളുടെ സൈറ്റിലുണ്ട്. nginx.com ബ്ലോഗിൽ നൽകിയിരിക്കുന്ന ഒരു WordPress സൈറ്റിന്റെ പ്രകടനം മെച്ചപ്പെടുത്തുന്നതിനുള്ള NGINX കോൺഫിഗറേഷന്റെ ഒരു ഉദാഹരണമാണ് ഇനിപ്പറയുന്നത്.
ഇത് ഉപയോഗിക്കുന്നതിന്, നിങ്ങളുടെ പരിതസ്ഥിതിയിൽ എന്താണ് നിലനിൽക്കുന്നതെന്ന് പ്രതിഫലിപ്പിക്കുന്നതിന് മാറ്റങ്ങൾ വരുത്തുക (ഡൊമെയ്ൻ, പാതകൾ, ഫയൽനാമങ്ങൾ മുതലായവ).
fastcgi_cache_path /var/run/NGINX-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
server {
server_name example.com www.example.com;
root /var/www/example.com;
index index.php;
access_log /var/log/NGINX/example.com.access.log;
error_log /var/log/NGINX/example.com.error.log;
set $skip_cache 0;
# POST requests and URLs with a query string should always go to PHP
if ($request_method = POST) {
set $skip_cache 1;
}
if ($query_string != "") {
set $skip_cache 1;
}
# Don't cache URIs containing the following segments
if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php |sitemap(_index)?.xml") {
set $skip_cache 1;
}
# Don't use the cache for logged-in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass |wordpress_no_cache|wordpress_logged_in") {
set $skip_cache 1;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
try_files $uri /index.php;
include fastcgi_params;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 60m;
}
location ~ /purge(/.*) {
fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
}
location ~* ^.+.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg |gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi |wav|bmp|rtf)$ {
access_log off;
log_not_found off;
expires max;
}
location = /robots.txt {
access_log off;
log_not_found off;
}
location ~ /. {
deny all;
access_log off;
log_not_found off;
}
}
NGINX-ൽ പ്രോക്സി കാഷെ പ്രവർത്തനക്ഷമമാക്കുന്നു
മറ്റ് പ്രോക്സിഡ് സെർവറുകളിൽ നിന്നുള്ള പ്രതികരണങ്ങൾ കാഷെ ചെയ്യുന്നതിനെയും NGINX പിന്തുണയ്ക്കുന്നു (proxy_pass നിർദ്ദേശപ്രകാരം നിർവചിച്ചിരിക്കുന്നത്). ഈ ടെസ്റ്റ് കേസിൽ, ഞങ്ങൾ ഒരു Node.js വെബ് ആപ്ലിക്കേഷന്റെ റിവേഴ്സ് പ്രോക്സിയായി NGINX ഉപയോഗിക്കുന്നു, അതിനാൽ Node.js ആപ്ലിക്കേഷന്റെ കാഷെയായി ഞങ്ങൾ NGINX പ്രവർത്തനക്ഷമമാക്കും. ഇവിടെ ഉപയോഗിച്ചിരിക്കുന്ന എല്ലാ കോൺഫിഗറേഷൻ നിർദ്ദേശങ്ങൾക്കും മുമ്പത്തെ വിഭാഗത്തിലെ FastCGI നിർദ്ദേശങ്ങൾക്ക് സമാനമായ അർത്ഥങ്ങളുണ്ട്, അതിനാൽ ഞങ്ങൾ അവ വീണ്ടും വിശദീകരിക്കില്ല.
ഒരു പ്രോക്uസി ചെയ്uത സെർവറിൽ നിന്നുള്ള പ്രതികരണങ്ങളുടെ കാഷിംഗ് പ്രവർത്തനക്ഷമമാക്കുന്നതിന്, ഉയർന്ന തലത്തിലുള്ള http{} സന്ദർഭത്തിൽ proxy_cache_path നിർദ്ദേശം ഉൾപ്പെടുത്തുക. അഭ്യർത്ഥനകൾ കാഷെ ചെയ്യുന്നതെങ്ങനെയെന്ന് വ്യക്തമാക്കുന്നതിന്, നിങ്ങൾക്ക് ഇനിപ്പറയുന്ന രീതിയിൽ proxy_cache_key നിർദ്ദേശവും ചേർക്കാവുന്നതാണ്.
proxy_cache_path /var/cache/nginx app1 keys_zone=PROXYCACHE:100m inactive=60m max_size=500m; proxy_cache_key "$scheme$request_method$host$request_uri"; add_header X-Cache-Status $upstream_cache_status; proxy_cache_min_uses 3;
അടുത്തതായി, ലൊക്കേഷൻ നിർദ്ദേശത്തിൽ കാഷെ സജീവമാക്കുക.
location / {
proxy_pass http://127.0.0.1:3000;
proxy_cache PROXYCACHE;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
}
NGINX കാഷെ ചെയ്uത ഉള്ളടക്കം അയയ്uക്കാത്തതും അപ്uസ്ട്രീം സെർവറിൽ നിന്ന് ഒരു പ്രതികരണവും കാഷെ ചെയ്യാത്തതുമായ വ്യവസ്ഥകൾ നിർവചിക്കുന്നതിന്, proxy_cache_bypass, proxy_no_cache എന്നിവ ഉൾപ്പെടുത്തുക.
proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment; proxy_no_cache $http_pragma $http_authorization;
ഫൈൻ-ട്യൂണിംഗ് പ്രോക്സി കാഷെ പ്രകടനം
പ്രോക്uസി കാഷെയുടെ പ്രകടനം നന്നായി ക്രമീകരിക്കുന്നതിന് ഇനിപ്പറയുന്ന നിർദ്ദേശങ്ങൾ ഉപയോഗപ്രദമാണ്. FastCGI നിർദ്ദേശങ്ങളുടെ അതേ അർത്ഥങ്ങൾ അവയ്ക്കും ഉണ്ട്.
proxy_cache_min_uses 3; proxy_cache_revalidate on; proxy_cache_use_stale error timeout updating http_500; proxy_cache_background_update on; proxy_cache_lock on;
കൂടുതൽ വിവരങ്ങൾക്കും കാഷിംഗ് കോൺഫിഗറേഷൻ നിർദ്ദേശങ്ങൾക്കും, രണ്ട് പ്രധാന മൊഡ്യൂളുകൾക്കുള്ള ഡോക്യുമെന്റേഷൻ കാണുക ngx_http_proxy_module.
അധിക ഉറവിടങ്ങൾ: വേർഡ്പ്രസ്സ് പ്രകടനം മെച്ചപ്പെടുത്തുന്നതിനുള്ള നുറുങ്ങുകൾ.