วิธีแคชเนื้อหาใน NGINX

NGINX เป็นเว็บเซิร์ฟเวอร์โอเพ่นซอร์สประสิทธิภาพสูงแบบรวมที่เร่งความเร็วในการส่งเนื้อหาและแอปพลิเคชัน ปรับปรุงความปลอดภัย และปรับปรุงความสามารถในการปรับขนาด กรณีการใช้งานที่พบบ่อยที่สุดกรณีหนึ่งของ Nginx คือ การแคชเนื้อหา ซึ่งเป็นวิธีที่มีประสิทธิภาพสูงสุดในการเพิ่มประสิทธิภาพของเว็บไซต์

อ่านเพิ่มเติม: เครื่องมือแคชโอเพ่นซอร์สยอดนิยม 10 อันดับสำหรับ Linux

คุณสามารถใช้ NGINX เพื่อเร่งความเร็วเซิร์ฟเวอร์ต้นทางในเครื่องได้โดยการกำหนดค่าให้แคชการตอบสนองจากเซิร์ฟเวอร์อัปสตรีม และเพื่อสร้างเซิร์ฟเวอร์ Edge สำหรับเครือข่ายการนำส่งเนื้อหา (CDNs) NGINX ขับเคลื่อน CDN ที่ใหญ่ที่สุดบางแห่ง

เมื่อกำหนดค่าเป็นแคช NGINX จะ:

แคชเนื้อหาแบบคงที่และไดนามิก
ปรับปรุงประสิทธิภาพเนื้อหาแบบไดนามิกด้วยไมโครแคช
ให้บริการเนื้อหาเก่าในขณะที่ตรวจสอบอีกครั้งในเบื้องหลังเพื่อประสิทธิภาพที่ดีขึ้น
แทนที่หรือตั้งค่าส่วนหัว Cache-Control และอื่นๆ

ในบทความนี้ คุณจะได้เรียนรู้วิธีกำหนดค่า NGINX เป็น การแคชเนื้อหา ใน Linux เพื่อให้เว็บเซิร์ฟเวอร์ของคุณทำงานได้อย่างมีประสิทธิภาพมากที่สุด

ข้อกำหนดเบื้องต้น:

คุณควรติดตั้ง NGINX บนเซิร์ฟเวอร์ Linux ของคุณ หากไม่ทำตามคำแนะนำเหล่านี้เพื่อติดตั้ง Nginx:

วิธีการติดตั้ง Nginx บน CentOS 8
วิธีการติดตั้ง Nginx บน CentOS 7

แคชเนื้อหาแบบคงที่บน Nginx

เนื้อหาแบบคงที่คือเนื้อหาของเว็บไซต์ที่ยังคงเหมือนเดิม (ไม่มีการเปลี่ยนแปลง) ในแต่ละหน้า ตัวอย่างของเนื้อหาแบบคงที่ ได้แก่ ไฟล์ต่างๆ เช่น รูปภาพ วิดีโอ เอกสาร ไฟล์ CSS และไฟล์ JavaScript

หากเว็บไซต์ของคุณใช้เนื้อหาคงที่จำนวนมาก คุณสามารถปรับประสิทธิภาพให้เหมาะสมได้โดยเปิดใช้งานการแคชฝั่งไคลเอ็นต์ โดยที่เบราว์เซอร์จะจัดเก็บสำเนาของเนื้อหาคงที่เพื่อการเข้าถึงที่รวดเร็วยิ่งขึ้น

ตัวอย่างการกำหนดค่าต่อไปนี้ใช้งานได้ดี เพียงแทนที่ www.example.com ด้วย URL ของชื่อเว็บไซต์ของคุณ และทำการแก้ไขชื่อพาธอื่นๆ ตามความเหมาะสม

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 ในส่วนด้านล่าง

การเปิดใช้งานแคช FastCGI ใน NGINX

FastCGI (หรือ FCGI) เป็นโปรโตคอลที่ใช้กันอย่างแพร่หลายสำหรับการเชื่อมต่อแอปพลิเคชันแบบโต้ตอบ เช่น PHP กับเว็บเซิร์ฟเวอร์ เช่น NGINX. เป็นส่วนขยายของ CGI (Common Gateway Interface)

ข้อได้เปรียบหลักของ FCGI คือสามารถจัดการคำขอ CGI หลายรายการในกระบวนการเดียว หากไม่มีสิ่งนี้ เว็บเซิร์ฟเวอร์จะต้องเปิดกระบวนการใหม่ (ที่ต้องควบคุม ประมวลผลคำขอ และปิด) สำหรับทุกคำขอของลูกค้าสำหรับบริการ

ในการประมวลผลสคริปต์ PHP ในการปรับใช้ LEMP stack นั้น NGINX จะใช้ FPM (FastCGI Process Manager) หรือ PHP-FPM ซึ่งเป็นการนำ PHP FastCGI ทางเลือกยอดนิยมมาใช้ เมื่อกระบวนการ PHP-FPM ทำงาน NGINX จะถูกกำหนดค่าให้ส่งคำขอพร็อกซีเพื่อประมวลผล ดังนั้น NGINX ยังสามารถกำหนดค่าให้แคชการตอบสนองจากแอปพลิเคชันเซิร์ฟเวอร์แบ็กเอนด์ PHP-FPM ได้ด้วย

ภายใต้ NGINX แคชเนื้อหา FastCGI จะถูกประกาศโดยใช้คำสั่งที่เรียกว่า fastcgi_cache_path ใน http{} ระดับบนสุด บริบทภายในโครงสร้างการกำหนดค่า NGINX คุณยังสามารถเพิ่ม fastcgi_cache_key ซึ่งกำหนดคีย์ (ตัวระบุคำขอ) สำหรับการแคช
นอกจากนี้ หากต้องการอ่านสถานะอัปสตรีมแคช ให้เพิ่มคำสั่ง add_header X-Cache-Status ภายในบริบท http{} ซึ่งมีประโยชน์สำหรับวัตถุประสงค์ในการแก้ไขจุดบกพร่อง
สมมติว่าไฟล์การกำหนดค่าบล็อกเซิร์ฟเวอร์ของไซต์ของคุณอยู่ที่ /etc/nginx/conf.d/testapp.conf หรือ /etc/nginx/sites-available/testapp.conf ( ภายใต้ Ubuntu และอนุพันธ์) ให้เปิดไฟล์แก้ไขและเพิ่มบรรทัดต่อไปนี้ที่ด้านบนของไฟล์
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
keys_zone (name:size) – เปิดใช้งานการสร้างโซนหน่วยความจำที่ใช้ร่วมกันซึ่งจัดเก็บคีย์ที่ใช้งานอยู่และข้อมูลเกี่ยวกับข้อมูล (เมตา) ทั้งหมด โปรดทราบว่าการเก็บคีย์ไว้ในหน่วยความจำจะเร่งกระบวนการตรวจสอบให้เร็วขึ้น โดยทำให้ NGINX พิจารณาว่าเป็น MISS หรือ HIT ได้ง่ายขึ้น โดยไม่ต้องตรวจสอบสถานะบนดิสก์
ไม่ใช้งาน – ระบุระยะเวลาที่ข้อมูลที่แคชไว้ซึ่งไม่เข้าถึงในช่วงเวลาที่ระบุจะถูกลบออกจากแคชโดยไม่คำนึงถึงความสดใหม่ ค่า 60m ในการกำหนดค่าตัวอย่างของเราหมายความว่าไฟล์ที่ไม่เข้าถึงหลังจาก 60 จะถูกลบออกจากแคช
max_size – ระบุขนาดสูงสุดของแคช มีพารามิเตอร์เพิ่มเติมที่คุณสามารถใช้ได้ที่นี่ (อ่านเอกสาร NGINX สำหรับข้อมูลเพิ่มเติม)
ตัวแปรในคำสั่ง fastcgi_cache_key มีอธิบายไว้ด้านล่างนี้
NGINX ใช้ในการคำนวณคีย์ (ตัวระบุ) ของคำขอ ที่สำคัญ หากต้องการส่งการตอบกลับที่แคชไว้ไปยังไคลเอนต์ คำขอจะต้องมีคีย์เดียวกันกับการตอบกลับที่แคชไว้
$scheme – รูปแบบคำขอ HTTP หรือ HTTPS
$request_method – วิธีการร้องขอ โดยปกติจะเป็น “GET ” หรือ “POST ”
$host – อาจเป็นชื่อโฮสต์จากบรรทัดคำขอ หรือชื่อโฮสต์จากช่องส่วนหัวคำขอ “โฮสต์ ” หรือชื่อเซิร์ฟเวอร์ที่ตรงกับคำขอ โดยเรียงตามลำดับความสำคัญ .
$request_uri – หมายถึง URI คำขอดั้งเดิมแบบเต็ม (พร้อมอาร์กิวเมนต์)
นอกจากนี้ ตัวแปร $upstream_cache_status ในคำสั่ง add_header X-Cache-Status จะได้รับการคำนวณสำหรับแต่ละคำขอที่ NGINX ตอบสนอง ไม่ว่าจะเป็น MISS (ไม่พบการตอบสนองในแคช ได้รับจากแอปพลิเคชันเซิร์ฟเวอร์) หรือ HIT (การตอบสนองเสิร์ฟจากแคช) หรือค่าอื่นๆ ที่สนับสนุน
ถัดไป ภายในคำสั่ง location ซึ่งส่งคำขอ PHP ไปยัง PHP-FPM ให้ใช้คำสั่ง 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;
การปรับแต่งประสิทธิภาพการแคช FastCGI อย่างละเอียดบน Nginx
หากต้องการกำหนดจำนวนครั้งขั้นต่ำที่ต้องส่งคำขอด้วยคีย์เดียวกันก่อนที่การตอบกลับจะถูกแคช ให้รวมคำสั่ง fastcgi_cache_min_uses ไว้ใน http{} หรือ เซิร์ฟเวอร์{} หรือบริบท ตำแหน่ง{}
fastcgi_cache_min_uses 3
หากต้องการเปิดใช้งานการตรวจสอบความถูกต้องอีกครั้งของรายการแคชที่หมดอายุโดยใช้คำขอแบบมีเงื่อนไขพร้อมกับฟิลด์ส่วนหัว “If-Modified-Since ” และ “If-None-Match ” ให้เพิ่ม fastcgi_cache_revalidate ภายในบริบท http{} หรือ server{} หรือ location{}
fastcgi_cache_revalidate on;
คุณยังสามารถสั่งให้ NGINX ส่งเนื้อหาที่แคชไว้เมื่อเซิร์ฟเวอร์ต้นทางหรือเซิร์ฟเวอร์ FCGI หยุดทำงาน โดยใช้คำสั่ง proxy_cache_use_stale ภายในคำสั่งตำแหน่ง
การกำหนดค่าตัวอย่างนี้หมายความว่าเมื่อ NGINX ได้รับข้อผิดพลาด การหมดเวลา และข้อผิดพลาดใดๆ ที่ระบุจากเซิร์ฟเวอร์อัปสตรีม และมีไฟล์ที่ร้องขอในเวอร์ชันเก่าในเนื้อหาที่แคชไว้ ก็จะส่งไฟล์เก่าไป
proxy_cache_use_stale error timeout http_500;
คำสั่งที่มีประโยชน์อีกประการหนึ่งในการปรับแต่งประสิทธิภาพแคช FCGI อย่างละเอียดคือ fastcgi_cache_ground_update ซึ่งทำงานร่วมกับคำสั่ง proxy_cache_use_stale เมื่อตั้งค่าเป็นเปิด ระบบจะสั่งให้ NGINX ให้บริการเนื้อหาเก่าเมื่อไคลเอนต์ร้องขอไฟล์ที่หมดอายุหรืออยู่ระหว่างการอัปเดตจากเซิร์ฟเวอร์อัปสตรีม
fastcgi_cache_background_update on;
fastcgi_cache_lock ก็มีประโยชน์เช่นกัน สำหรับการปรับแต่งประสิทธิภาพของแคชอย่างละเอียด หากไคลเอ็นต์หลายตัวร้องขอเนื้อหาเดียวกันที่ไม่อยู่ในแคช NGINX จะส่งต่อเฉพาะคำขอแรกไปยังเซิร์ฟเวอร์อัปสตรีม แคช การตอบสนองจากนั้นจะให้บริการคำขอไคลเอ็นต์อื่นจากแคช
fastcgi_cache_lock on;
หลังจากทำการเปลี่ยนแปลงข้างต้นทั้งหมดในไฟล์การกำหนดค่า NGINX แล้ว ให้บันทึกและปิด จากนั้นตรวจสอบโครงสร้างการกำหนดค่าเพื่อหาข้อผิดพลาดทางไวยากรณ์ก่อนเริ่มบริการ NGINX ใหม่
nginx -t systemctl restart nginx
ถัดไป ทดสอบว่าแคชทำงานอย่างถูกต้องหรือไม่ ลองเข้าถึงเว็บแอปพลิเคชันหรือไซต์ของคุณโดยใช้คำสั่ง curl ต่อไปนี้ (ครั้งแรกควรระบุว่า พลาด แต่คำขอครั้งต่อไปควรระบุ HIT ดังที่แสดงในภาพหน้าจอ)
curl -I http://testapp.linux-console.net
นี่คือภาพหน้าจออื่นที่แสดง NGINX ที่ให้บริการข้อมูลเก่า
การเพิ่มข้อยกเว้นให้กับ Bypass Cache
คุณสามารถกำหนดเงื่อนไขที่ NGINX ไม่ควรส่งการตอบกลับที่แคชไว้ไปยังไคลเอนต์ได้ โดยใช้คำสั่ง fastcgi_cache_bypass และหากต้องการสั่ง NGINX ไม่ให้แคชการตอบสนองจากเซิร์ฟเวอร์อัปสตรีมเลย ให้ใช้ fastcgi_no_cache
ตัวอย่างเช่น หากคุณต้องการให้คำขอ POST และ URL ที่มีสตริงข้อความค้นหาไปที่ PHP เสมอ ขั้นแรก ให้ประกาศคำสั่ง if เพื่อกำหนดเงื่อนไขดังต่อไปนี้
set $skip_cache 0; if ($request_method = POST) { set $skip_cache 1; }
จากนั้นเปิดใช้งานข้อยกเว้นข้างต้นในคำสั่ง location ซึ่งส่งคำขอ PHP ไปยัง PHP-FPM โดยใช้ fastcgi_cache_bypass และ fastcgi_no_cache คำสั่ง
fastcgi_cache_bypass $skip_cache; fastcgi_no_cache $skip_cache;
มีส่วนอื่นๆ มากมายในไซต์ของคุณที่คุณอาจไม่ต้องการเปิดใช้งานการแคชเนื้อหา ต่อไปนี้คือตัวอย่างการกำหนดค่า NGINX เพื่อปรับปรุงประสิทธิภาพของไซต์ WordPress ซึ่งมีอยู่ในบล็อก nginx.com
หากต้องการใช้งาน ให้ทำการเปลี่ยนแปลง (เช่น โดเมน เส้นทาง ชื่อไฟล์ ฯลฯ) เพื่อให้สะท้อนถึงสิ่งที่มีอยู่ในสภาพแวดล้อมของคุณ
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) สำหรับกรณีทดสอบนี้ เราใช้ NGINX เป็นพร็อกซีย้อนกลับสำหรับเว็บแอปพลิเคชัน Node.js ดังนั้นเราจะเปิดใช้งาน NGINX เป็นแคชสำหรับแอปพลิเคชัน Node.js คำสั่งการกำหนดค่าทั้งหมดที่ใช้ในที่นี้มีความหมายคล้ายกับคำสั่ง FastCGI ในส่วนก่อนหน้า ดังนั้นเราจะไม่อธิบายอีกครั้ง
หากต้องการเปิดใช้งานการแคชการตอบสนองจากเซิร์ฟเวอร์พร็อกซี ให้รวมคำสั่ง proxy_cache_path ในบริบท http{} ระดับบนสุด หากต้องการระบุวิธีการแคชคำขอ คุณสามารถเพิ่มคำสั่ง 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 จะไม่ส่งเนื้อหาที่แคชไว้และไม่แคชการตอบสนองเลยจากเซิร์ฟเวอร์อัปสตรีม ให้รวม proxy_cache_bypass และ proxy_no_cache
proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment; proxy_no_cache $http_pragma $http_authorization;
การปรับแต่งประสิทธิภาพแคชพร็อกซีอย่างละเอียด
คำสั่งต่อไปนี้มีประโยชน์สำหรับการปรับแต่งประสิทธิภาพของแคชพร็อกซีอย่างละเอียด นอกจากนี้ยังมีความหมายเช่นเดียวกับคำสั่ง 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_fastcgi_module และ ngx_http_proxy_module
แหล่งข้อมูลเพิ่มเติม: การแคชเนื้อหา NGINX และเคล็ดลับในการปรับปรุงประสิทธิภาพ WordPress