เปรียบเทียบ ZSTD, Brotli และ GZIP สำหรับ API: ความเร็ว อัตราส่วน การใช้ CPU และค่าตั้งต้นเชิงปฏิบัติสำหรับ payload JSON และไบนารีในโปรดักชัน

การบีบอัดการตอบกลับของ API หมายถึงเซิร์ฟเวอร์ของคุณเข้ารหัสเนื้อหาการตอบกลับ (มักจะเป็น JSON) ให้เป็นสตรีมไบต์ที่เล็กลงก่อนส่งผ่านเครือข่าย ไคลเอนต์ (เบราว์เซอร์ แอปมือถือ SDK หรือบริการอื่น) จะถอดการบีบอัดนั้นก่อนใช้งาน บน HTTP การเจรจานี้ทำผ่านเฮดเดอร์อย่าง Accept-Encoding (ไคลเอนต์รองรับอะไร) และ Content-Encoding (เซิร์ฟเวอร์เลือกอะไร)
การบีบอัดให้ประโยชน์หลักๆ สามอย่าง:
การแลกเปลี่ยนชัดเจน: การบีบอัดประหยัดแบนด์วิดธ์แต่แลกกับ CPU (การบีบอัด/ถอดการบีบอัด) และบางครั้ง หน่วยความจำ (บัฟเฟอร์) ว่าคุ้มหรือไม่ขึ้นกับคอขวดของคุณ
การบีบอัดเด่นเมื่อการตอบกลับเป็น:
ถ้าคุณส่งรายการ JSON ขนาดใหญ่ (แคตตาล็อก ผลลัพธ์การค้นหา ข้อมูลวิเคราะห์) การบีบอัดมักเป็นหนึ่งในวิธีที่ทำได้ง่ายสุดเพื่อปรับปรุงประสิทธิภาพ
การบีบอัดมักไม่คุ้มเมื่อการตอบกลับเป็น:
เมื่อเลือกระหว่าง ZSTD vs Brotli vs GZIP สำหรับการบีบอัด API การตัดสินใจเชิงปฏิบัติมักขึ้นกับ:
ที่เหลือในบทความนี้คือการถ่วงดุลทั้งสามข้อให้เข้ากับ API และรูปแบบทราฟิกของคุณ
ทั้งสามแบบลดขนาด payload แต่แต่ละแบบมีการปรับจูนให้เหมาะกับข้อจำกัดต่างกัน—ความเร็ว อัตราส่วนการบีบอัด และความเข้ากันได้
ความเร็วของ ZSTD: ดีเมื่อ API ของคุณอ่อนไหวต่อ tail latency หรือเซิร์ฟเวอร์ของคุณผูกมัดด้วย CPU มันสามารถบีบอัดได้เร็วพอที่ค่าโอเวอร์เฮดมักไม่น่าสำคัญเมื่อเทียบกับเวลาเครือข่าย—โดยเฉพาะการตอบ JSON ขนาดกลางถึงใหญ่
อัตราส่วนการบีบอัดของ Brotli: ดีที่สุดเมื่อแบนด์วิดธ์เป็นปัจจัยหลัก (ไคลเอนต์มือถือ ค่า egress สูง จัดส่งผ่าน CDN) และการตอบเป็นข้อความเสียส่วนใหญ่ ขนาดเล็กกว่าอาจคุ้มค่าแม้การบีบอัดจะใช้เวลามากขึ้น
ความเข้ากันได้ของ GZIP: ดีที่สุดเมื่อคุณต้องการการรองรับไคลเอนต์สูงสุดโดยความเสี่ยงเจรจาน้อย (SDK เก่า ไคลเอนต์ฝังตัว พร็อกซีเดิม) มันเป็นพื้นฐานที่ปลอดภัยแม้จะไม่ใช่ตัวที่ดีที่สุดเสมอไป
"ระดับ" การบีบอัดคือพรีเซ็ตที่แลก เวลา CPU กับ ขนาดเอาต์พุตที่เล็กกว่า:
การถอดการบีบอัดโดยทั่วไปถูกกว่าการบีบอัดสำหรับทั้งสามแบบ แต่ระดับสูงมากยังสามารถเพิ่มภาระ CPU ของไคลเอนต์—สำคัญกับมือถือ
การบีบอัดมักถูกขายว่า “การตอบเล็กลง = API เร็วขึ้น” ซึ่งมักเป็นจริงบนเครือข่ายช้า/แพง—แต่ไม่ใช่เสมอไป หากการบีบอัดเพิ่มเวลาการใช้ CPU ของเซิร์ฟเวอร์มากพอ คุณอาจได้คำขอที่ช้าลงแม้ไบต์จะน้อยลง
ช่วยแยกค่าใช้จ่ายออกเป็นสองส่วน:
อัตราส่วนการบีบอัดสูงสามารถลดเวลาในการส่ง แต่ถ้าการบีบอัดเพิ่ม (เช่น) 15–30 ms ต่อการตอบ คุณอาจเสียเวลามากกว่าที่ประหยัด—โดยเฉพาะบนการเชื่อมต่อที่เร็ว
ภายใต้โหลด การบีบอัดสามารถทำร้าย p95/p99 latency มากกว่า p50 เมื่อการใช้ CPU พุ่ง คำร้องจะรอคิว การรอคิวจะขยายค่าใช้จ่ายต่อคำร้องเล็กๆ ให้กลายเป็นความหน่วงใหญ่—ค่าเฉลี่ยอาจดูโอเค แต่ผู้ใช้ช้าที่สุดจะได้รับผลกระทบมาก
อย่าเดา รัน A/B test หรือการเปิดตัวแบบค่อยเป็นค่อยไปและเปรียบเทียบ:
ทดสอบด้วยรูปแบบทราฟิกและ payload ที่สมจริง ระดับการบีบอัดที่ดีที่สุดคือระดับที่ลดเวลารวม ไม่ใช่แค่ไบต์
การบีบอัดไม่ฟรี—มันย้ายงานจากเครือข่ายไปยัง CPU และหน่วยความจำทั้งสองด้าน ใน API นั่นแปลว่าเวลาจัดการคำร้องเพิ่ม ขนาดหน่วยความจำต่อคำร้องเพิ่ม และบางครั้งไคลเอนต์ช้าลง
CPU ส่วนมากใช้ไปกับการบีบอัด การตอบกลับ การบีบอัดต้องหาลวดลาย สร้างสถานะ/พจนานุกรม และเขียนผลลัพธ์ที่เข้ารหัส
การถอดการบีบอัดถูกกว่าตามปกติ แต่ยังสำคัญ:
หาก API ของคุณผูกมัดด้วย CPU อยู่แล้ว การเปิดการบีบอัดระดับสูงสามารถเพิ่ม tail latency แม้ payload จะหดลง
การบีบอัดอาจเพิ่มการใช้หน่วยความจำในหลายทาง:
ในสภาพแวดล้อมคอนเทนเนอร์ peak memory สูงอาจทำให้เกิด OOM kill หรือต้องตั้งข้อจำกัดแคบลงซึ่งลดความหนาแน่นของการใช้งานได้
การบีบอัดเพิ่มรอบ CPU ต่อการตอบ ลด throughput ต่ออินสแตนซ์ ส่งผลให้ออโต้สเกลเกิดขึ้นเร็วขึ้นและเพิ่มค่าใช้จ่าย รูปแบบทั่วไป: แบนด์วิดธ์ลดแต่การใช้ CPU เพิ่ม—ดังนั้นการเลือกที่ถูกต้องขึ้นกับทรัพยากรไหนที่คุณขาดแคลน
บนมือถือหรืออุปกรณ์กำลังต่ำ การถอดการบีบอัดแข่งกับการเรนเดอร์ การประมวลผล JavaScript และแบตเตอรี่ รูปแบบที่ประหยัดไม่กี่ KB แต่ใช้เวลาถอดนานกว่าอาจรู้สึกช้ากว่า โดยเฉพาะเมื่อ "เวลาไปสู่ข้อมูลที่ใช้งานได้" สำคัญ
Zstandard (ZSTD) เป็นฟอร์แมตร่วมสมัยที่ออกแบบมาเพื่อให้ได้อัตราส่วนที่ดีโดยไม่ทำให้ API ช้าลง สำหรับ API ที่เน้น JSON เป็นส่วนใหญ่ มันเป็นค่า "ดีฟอลต์" ที่แข็งแรง: ตอบกลับเล็กกว่า GZIP อย่างชัดเจนที่ latency เท่าเดิมหรือน้อยกว่า และการถอดการบีบอัดบนไคลเอนต์เร็วมาก
ZSTD มีค่าสูงเมื่อคุณใส่ใจเวลาแบบ end-to-end ไม่ใช่แค่ไบต์เล็กที่สุด มันมักบีบอัดเร็วและถอดการบีบอัดได้เร็วมาก—เป็นประโยชน์สำหรับ API ที่ทุกมิลลิวินาทีของ CPU แข่งขันกับการจัดการคำร้อง
มันทำงานได้ดีในช่วงขนาด payload กว้าง: JSON ขนาดเล็กถึงกลางมักเห็นประโยชน์ ขณะที่การตอบขนาดใหญ่ได้ประโยชน์มากขึ้นอีก
สำหรับ API ส่วนใหญ่ เริ่มด้วยระดับต่ำ (โดยทั่วไประดับ 1–3) ซึ่งมักให้การแลกเปลี่ยนระหว่าง latency/ขนาดที่ดีที่สุด
ใช้ระดับสูงเฉพาะเมื่อ:
แนวทางปฏิบัติที่เป็นเหตุผลคือใช้ดีฟอลต์ต่ำทั่วทั้งระบบ แล้วเพิ่มระดับเฉพาะเส้นทางที่ตอบกลับใหญ่ๆ
ZSTD รองรับการสตรีม ซึ่งช่วยลด peak memory และเริ่มส่งข้อมูลได้เร็วขึ้นสำหรับการตอบขนาดใหญ่
โหมดพจนานุกรมช่วยได้มากสำหรับ API ที่ส่งวัตถุที่คล้ายกันบ่อยครั้ง (คีย์ซ้ำ โครงสร้างคงที่) เหมาะเมื่อ:
การรองรับฝั่งเซิร์ฟเวอร์ทำได้โดยตรงในสแตกหลายตัว แต่ความเข้ากันได้ของไคลเอนต์อาจเป็นตัวตัดสิน บางไคลเอนต์ HTTP พร็อกซี และเกตเวย์อาจไม่ประกาศหรือยอมรับ Content-Encoding: zstd โดยดี
ถ้าคุณให้บริการผู้บริโภคภายนอก ให้มี fallback (โดยปกติคือ GZIP) และเปิดใช้ ZSTD ก็ต่อเมื่อ Accept-Encoding ระบุชัดเจนว่ารองรับมัน
Brotli ออกแบบมาให้บีบอัดข้อความได้น้อยสุด ใน JSON HTML และ payload อื่นๆ ที่มีคำมาก มันมักชนะ GZIP ในอัตราส่วนการบีบอัด—โดยเฉพาะที่ระดับการบีบอัดสูงๆ
การตอบข้อความเยอะเป็นจุดแข็งของ Brotli ถ้า API ของคุณส่งเอกสาร JSON ขนาดใหญ่ (แคตตาล็อก ผลลัพธ์การค้นหา บล็อบการตั้งค่า) Brotli สามารถลดไบต์ได้อย่างเห็นได้ชัด ช่วยบนเครือข่ายช้าและลดค่า egress
Brotli ยังดีเมื่อคุณสามารถ บีบอัดครั้งเดียวแล้วให้บริการหลายครั้ง (การตอบที่แคชได้ ทรัพยากรที่มีเวอร์ชัน) ในกรณีนั้นระดับ Brotli สูงๆ คุ้มเมื่อค่า CPU ถูกเฉลี่ยบนหลายคำขอ
สำหรับการตอบแบบไดนามิกที่สร้างตามคำขอ (ไม่มีการแคช) อัตราส่วนที่ดีที่สุดของ Brotli มักต้องระดับสูงซึ่งกิน CPU มากและเพิ่มความหน่วง เมื่อคำนึงถึงเวลาในการบีบอัดแล้ว ผลลัพธ์จริงเหนือกว่า ZSTD (หรือ GZIP ปรับแต่งดี) อาจน้อยกว่าที่คาด
นอกจากนี้ Brotli น้อยน่าสนใจสำหรับ payload ที่ไม่บีบอัดได้ดี (ข้อมูลที่บีบอัดแล้ว ฟอร์แมตไบนารีบางแบบ) ในกรณีนั้นคุณจะเผาผลาญ CPU เปล่าๆ
เบราว์เซอร์รองรับ Brotli ดีผ่าน HTTPS ซึ่งเป็นเหตุผลที่มันเป็นที่นิยมสำหรับทราฟฟิกเว็บ สำหรับไคลเอนต์ API ที่ไม่ใช่เบราว์เซอร์ (SDK มือถือ อุปกรณ์ IoT สแต็ก HTTP เก่า) การรองรับอาจไม่สม่ำเสมอ—ดังนั้นเจรจาให้ถูกต้องผ่าน Accept-Encoding และเก็บ fallback (ปกติคือ GZIP)
ใช้การบีบอัดการตอบกลับเมื่อการตอบกลับเป็นข้อความเยอะ (JSON/GraphQL/XML/HTML) ขนาดปานกลางถึงใหญ่ และผู้ใช้ของคุณอยู่ในเครือข่ายที่ช้า/แพง หรือคุณจ่ายค่าทราฟฟิกขาออกที่สำคัญ ให้ข้ามการบีบอัด (หรือเพิ่มเกณฑ์ให้สูง) สำหรับการตอบกลับขนาดเล็ก สื่อที่บีบอัดแล้ว (JPEG/MP4/ZIP/PDF) และบริการที่ใช้งาน CPU หนักซึ่งงานต่อคำร้องเพิ่มจะทำให้ p95/p99 แย่ลง
เพราะมันแลกแบนด์วิดธ์กับ CPU (และบางครั้งหน่วยความจำ) เวลาการบีบอัดอาจทำให้เซิร์ฟเวอร์เริ่มส่งไบต์ช้าลง (TTFB) และตอนที่มีโหลดสูงจะทำให้คำร้องรอคิว—บ่อยครั้งจะทำให้ tail latency แย่ลง แม้ว่าขนาด payload จะเล็กลง การตั้งค่าที่ “ดีที่สุด” คือค่าที่ลดเวลาแบบ end-to-end ไม่ใช่แค่ลดขนาดไบต์
ลำดับค่าดีฟอลต์ที่ปฏิบัติได้สำหรับหลาย API คือ:
zstd เป็นอันดับแรก (เร็ว อัตราส่วนดี)br (มักจะเล็กที่สุดสำหรับข้อความ แต่ใช้ CPU มากกว่าได้)gzip (เข้ากันได้กว้างที่สุด)ท้ายที่สุดให้เลือกตามที่ไคลเอนต์ระบุใน Accept-Encoding และเก็บ fallback ที่ปลอดภัย (ปกติคือ gzip หรือ identity)
เริ่มด้วยค่าต่ำและวัดผล
ใช้เกณฑ์ขนาดขั้นต่ำเพื่อไม่ให้เสีย CPU กับ payload เล็กๆ
จูนแยกตามเส้นทางโดยเปรียบเทียบไบต์ที่ประหยัดได้กับเวลาที่เซิร์ฟเวอร์เพิ่มขึ้นและผลกระทบต่อ p50/p95/p99
เน้นที่ชนิดเนื้อหาที่เป็นโครงสร้างและมีความซ้ำสูง:
การบีบอัดต้องทำตามการเจรจา HTTP:
Accept-Encoding (เช่น zstd, br, gzip)Content-Encoding ที่รองรับถ้าไคลเอนต์ไม่ส่ง การตอบที่ปลอดภัยที่สุดมักจะเป็น อย่าตอบด้วย ที่ไคลเอนต์ไม่ได้โฆษณา มิฉะนั้นไคลเอนต์อาจแปลไม่ได้
เพิ่ม:
Vary: Accept-Encodingซึ่งป้องกัน CDN/proxy จากการแคชตัวแปรแบบหนึ่ง (เช่น gzip) แล้วส่งให้ไคลเอนต์ที่ไม่ได้ร้องขอหรือถอดรหัสไม่ได้ หากคุณรองรับหลายการเข้ารหัส เฮดเดอร์นี้จำเป็นสำหรับการแคชที่ถูกต้อง
ความผิดพลาดที่พบบ่อยได้แก่:
เปิดตัวเหมือนฟีเจอร์ด้านประสิทธิภาพ:
ระดับสูงขึ้นมักให้การลดขนาดที่น้อยลงแต่สามารถเพิ่ม CPU และทำให้ p95/p99 แย่ลง
แนวทางที่ใช้กันคือเปิดการบีบอัดเฉพาะสำหรับค่า Content-Type แบบข้อความและปิดสำหรับฟอร์แมตที่บีบอัดอยู่แล้ว
Accept-EncodingContent-EncodingContent-Encoding ระบุ gzip แต่บอดี้ไม่ได้ถูกบีบอัด)Accept-Encoding)เมื่อดีบัก ให้จับเฮดเดอร์ดิบและยืนยันการถอดความด้วยเครื่องมือ/ไคลเอนต์ที่เชื่อถือได้
ถ้า tail latency เพิ่มภายใต้โหลด ลดระดับ บวกเกณฑ์ หรือสลับไปใช้โค้ดคอมเพรสชันที่เร็วกว่าบ่อยครั้งคือ ZSTD