บทสรุปของโพสต์โดย durumis AI
- บทความนี้กล่าวถึงการตั้งค่าหลักต่างๆ เพื่อเพิ่มประสิทธิภาพเว็บเซิร์ฟเวอร์ nginx เช่น การบีบอัด gzip, การตั้งค่า proxy_buffer, การตั้งค่า worker และ keep-alive
- บทความนี้เน้นความสำคัญของการบีบอัด gzip และการใช้ proxy_buffer ในการลดปริมาณข้อมูลที่ส่ง และลดภาระของเซิร์ฟเวอร์ รวมถึงการจัดการการเชื่อมต่อโดยใช้ worker process และการตั้งค่า keep-alive
- บทความนี้แนะนำให้ทำการทดสอบต่างๆ เพื่อหาค่าที่เหมาะสมกับสภาพแวดล้อมของเซิร์ฟเวอร์ และกล่าวถึงข้อควรระวังเพื่อให้การใช้งานเซิร์ฟเวอร์มีเสถียรภาพ
Nginx เป็นโอเพนซอร์สที่ใช้กันอย่างแพร่หลายเป็นเว็บเซิร์ฟเวอร์หรือเว็บพร็อกซีเซิร์ฟเวอร์
หากกำหนดค่าได้อย่างเหมาะสม สามารถให้บริการเนื้อหาแบบคงที่ได้อย่างมีประสิทธิภาพ
ฉันต้องการบันทึกการตั้งค่าที่สำคัญบางอย่าง
การตั้งค่าที่สำคัญบางอย่างที่เกี่ยวข้องกับประสิทธิภาพ
1. การบีบอัด gzip
เมื่อโหลดเว็บไซต์ คุณจะได้รับไฟล์มากมายจากเว็บเซิร์ฟเวอร์ เช่น JavaScript, รูปภาพ, HTML และ CSS
แทนที่จะส่งเนื้อหานี้ในรูปแบบดั้งเดิม การใช้การบีบอัด gzip สามารถลดปริมาณข้อมูลที่ส่งได้อย่างมีนัยสำคัญ
กล่าวคือ เมื่อนำไปใช้แล้ว
- ปริมาณข้อมูลลดลง ส่งผลให้ประหยัดแบนด์วิดท์
- สามารถประหยัดทรัพยากรเซิร์ฟเวอร์ได้
- สำหรับผู้ใช้ ความเร็วในการโหลดจะเร็วขึ้นจริง ๆ
ในทางกลับกัน เนื่องจากเซิร์ฟเวอร์ต้องดำเนินการบีบอัด gzip ก่อนที่จะตอบกลับเนื้อหา การใช้ CPU ของเซิร์ฟเวอร์อาจเพิ่มขึ้น
จำเป็นต้องมีการทดสอบก่อนที่จะนำไปใช้ในระดับการดำเนินงาน เช่น ประเภทของไฟล์ที่จะบีบอัด ระดับการบีบอัด และขนาดของไฟล์ที่จะบีบอัด
ต่อไปนี้เป็นการตั้งค่าบางอย่างที่เกี่ยวข้องกับ gzip
gzip on; # ตั้งค่าการบีบอัด gzip
gzip_vary on; # เพิ่ม Vary: Accept-Encoding ลงในส่วนหัว
gzip_proxied any; # หากใช้ nginx เป็นพร็อกซีเซิร์ฟเวอร์ จะบีบอัดการตอบกลับที่ได้รับจาก backend (การบีบอัดสำหรับคำขอพร็อกซี)
gzip_min_length 256; # บีบอัดเฉพาะไฟล์ที่มีขนาดมากกว่า 256 ไบต์
gzip_comp_level 5; # ตั้งค่าระดับการบีบอัด 1-9 ยิ่งสูงยิ่งใช้ CPU มากขึ้น 5 บีบอัดประมาณ 50%
gzip_types text/plain text/css text/xml application/json application/javascript;
// ตั้งค่าประเภทเนื้อหาที่จะบีบอัด
* gzip_vary บอกให้เซิร์ฟเวอร์สามารถส่งเนื้อหาในเวอร์ชันที่บีบอัดและเวอร์ชันที่ไม่ได้บีบอัดตามว่าไคลเอนต์รองรับ gzip หรือไม่ (แจ้งให้ทราบว่าเนื้อหาเวอร์ชันต่างๆ อาจมีให้บริการตามส่วนหัวของคำขอของไคลเอนต์ (Accept-Encoding))
2. การตั้งค่า proxy_buffer
nginx จะเก็บการตอบกลับไว้ในบัฟเฟอร์ก่อนที่จะส่งไปยังไคลเอนต์
เมื่อเว็บเซิร์ฟเวอร์ส่งการตอบกลับไปยังไคลเอนต์ หากความเร็วของไคลเอนต์ช้า เซิร์ฟเวอร์จะต้องรอส่งข้อมูลต่อไป (ปัญหาคอขวดของเครือข่าย)
ในกรณีนี้ เนื่องจากเซิร์ฟเวอร์ยังคงใช้ทรัพยากรอยู่ จึงใช้บัฟเฟอร์เพื่อจัดการการตอบกลับชั่วคราวโดยไม่คำนึงถึงความเร็วในการประมวลผลของไคลเอนต์ ซึ่งจะทำให้ได้ประโยชน์ดังต่อไปนี้
- การปรับให้เหมาะสมกับภาระของเซิร์ฟเวอร์
- ลดปัญหาคอขวดของเครือข่าย
location / {
proxy_pass URL ของเซิร์ฟเวอร์;
# การตั้งค่าพร็อกซีบัฟเฟอร์
proxy_buffering on; # เปิดใช้งานบัฟเฟอร์
proxy_buffer_size 4k; # ตั้งค่าขนาดของบัฟเฟอร์ (โดยทั่วไปแล้วจะมีส่วนหัว)
proxy_buffers 8 4k; # จำนวนและขนาดของบัฟเฟอร์สำหรับการเชื่อมต่อแต่ละครั้ง (8 บัฟเฟอร์ ขนาด 4kb)
proxy_busy_buffers_size 8k; # ขนาดบัฟเฟอร์สูงสุดที่จะใช้ในขณะที่ส่งการตอบกลับไปยังไคลเอนต์
}
※ หากตั้งค่าขนาดของบัฟเฟอร์ให้ใหญ่เกินไป การส่งข้อมูลแบบเรียลไทม์ เช่น การสตรีมข้อความ อาจล่าช้า ดังนั้นจึงจำเป็นต้องมีการทดสอบ โดยเฉพาะอย่างยิ่งเนื่องจากมีบริการที่เกี่ยวข้องกับ AI จำนวนมากออกมาในปัจจุบัน หากการสตรีมข้อความไม่ทำงาน ตรวจสอบการตั้งค่านี้ให้แน่ใจ
3. การตั้งค่า worker และ http
worker คือกระบวนการที่ประมวลผลคำขอของไคลเอนต์ และสามารถตั้งค่าจำนวน worker ที่จะใช้สำหรับแต่ละคอร์ CPU ของเซิร์ฟเวอร์ได้
โดยทั่วไปแล้ว http คือคำขอ - การเชื่อมต่อ - การตอบกลับ - การปิดการเชื่อมต่อ แต่เพื่อลดทรัพยากรในการเชื่อมต่อสำหรับคำขอหลายครั้ง คุณสามารถรักษาการเชื่อมต่อของไคลเอนต์ไว้ได้ นี่คือการตั้งค่า keep alive
worker_processes auto; # ตั้งค่าโดยอัตโนมัติตามจำนวนคอร์ CPU ที่ใช้งานได้
worker_connections 1024; # จำนวนการเชื่อมต่อที่ worker แต่ละตัวสามารถประมวลผลได้พร้อมกัน
# การตั้งค่า keep-alive
keepalive_timeout 65;
keepalive_requests 100;
server {
listen 80;
location / {
proxy_pass URL ของเซิร์ฟเวอร์;
}
}
เหตุผลที่รวมสองอย่างนี้เข้าด้วยกันมีดังนี้
หากเซิร์ฟเวอร์ที่ใช้มี 4 คอร์ จำนวนการเชื่อมต่อที่เป็นไปได้ทางทฤษฎีคือ 1,024 * 4 = 4,096
(อาจไม่ถูกต้องตามทรัพยากรหรือสภาพแวดล้อมการรับส่งข้อมูล)
เมื่อไคลเอนต์ 4,096 รายเชื่อมต่อพร้อมกันและใช้ keepalive ทั้งหมดเป็นเวลา 65 วินาที
หากผู้ใช้คนที่ 4,097 พยายามเชื่อมต่อ การเชื่อมต่อจะไม่สามารถทำได้ ส่งผลให้การตอบกลับล่าช้า
ดังนั้น หากสมมติว่าทรัพยากรเซิร์ฟเวอร์มีความเสถียร เช่น การปรับขนาดอัตโนมัติ หากเกิดความล่าช้าในการตอบกลับในระหว่างเหตุการณ์ การตั้งค่าข้างต้นอาจส่งผลกระทบโดยอ้อม
4. อื่นๆ - บล็อก location
สามารถใช้การตั้งค่าบางอย่าง เช่น proxy buffer กับ URL ของคำขอแต่ละรายการได้
* การตั้งค่าบางอย่าง เช่น keep-alive ถูกนำไปใช้ในระดับ HTTP/Server และไม่สามารถตั้งค่าได้ทีละบล็อก
server {
listen 80;
server_name example.com;
# การประมวลผลเส้นทางเริ่มต้น (/)
location / {
proxy_pass URL ของเซิร์ฟเวอร์;
# การตั้งค่าบัฟเฟอร์
proxy_buffering on;
proxy_buffers 8 16k;
proxy_buffer_size 32k;
proxy_busy_buffers_size 64k;
}
# การประมวลผลเส้นทาง /test
location /test {
proxy_pass URL ของเซิร์ฟเวอร์ 2;
# ปิดใช้งานบัฟเฟอร์
proxy_buffering off; # ปิดใช้งานบัฟเฟอร์ (ส่งการตอบกลับทันที)
}
}
การตั้งค่าข้างต้นสามารถใช้เพื่อเพิ่มประสิทธิภาพเว็บได้ ให้ทำการทดสอบอย่างละเอียดโดยพิจารณาจากกรณีทดสอบต่างๆ เพื่อปรับให้เหมาะสมกับประสิทธิภาพของเซิร์ฟเวอร์!
* สามารถใช้ nginx ที่มีการตั้งค่าที่เปลี่ยนแปลงแล้วโดยไม่มีการหยุดทำงานของเซิร์ฟเวอร์ ดังนั้นจึงมีความเสถียรมากที่สุด