เราพูดคุยเกี่ยวกับวิธีการใน บทความในบทความนี้เราทดสอบ HTTPS แต่ในสถานการณ์ที่สมจริงยิ่งขึ้น สำหรับการทดสอบ เราได้รับใบรับรอง Let's Encrypt และเปิดใช้งานการบีบอัด Brotli เป็น 11
คราวนี้เราจะพยายามสร้างสถานการณ์จำลองของการปรับใช้เซิร์ฟเวอร์บน VDS หรือเป็นเครื่องเสมือนบนโฮสต์ที่มีโปรเซสเซอร์มาตรฐาน เพื่อจุดประสงค์นี้ จึงมีการกำหนดขีดจำกัดไว้ที่:
- 25% - ซึ่งเทียบเท่ากับความถี่ ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 เมกะเฮิรตซ์
- 65% - 3510 เมกะเฮิรตซ์
จำนวนการเชื่อมต่อครั้งเดียวลดลงจาก 500 เป็น 1, 3, 5, 7 และ 9
ผล:
ความล่าช้า:
TTFB ถูกรวมไว้เป็นการทดสอบแยกต่างหากโดยเฉพาะ เนื่องจากเครื่องมือ HTTPD จะสร้างผู้ใช้ใหม่สำหรับคำขอแต่ละรายการ การทดสอบนี้ยังค่อนข้างแยกจากความเป็นจริง เนื่องจากผู้ใช้จะยังคงคลิกไปสองสามหน้า และในความเป็นจริง TTFP จะมีบทบาทหลัก
คำขอแรก โดยทั่วไปคำขอแรกหลังจากการเริ่มเครื่องเสมือน IIS ครั้งแรกจะใช้เวลาเฉลี่ย 120 มิลลิวินาที
คำขอที่ตามมาทั้งหมดแสดง TTFP ที่ 1.5 มิลลิวินาที Apache และ Nginx ล้าหลังในเรื่องนี้ โดยส่วนตัวแล้วผู้เขียนถือว่าการทดสอบนี้เปิดเผยมากที่สุดและจะเลือกผู้ชนะตามการทดสอบเท่านั้น
ผลลัพธ์จึงไม่น่าแปลกใจเนื่องจาก IIS แคชเนื้อหาคงที่ที่บีบอัดแล้ว และไม่บีบอัดทุกครั้งที่มีการเข้าถึง
เวลาที่ใช้ต่อลูกค้า
เพื่อประเมินประสิทธิภาพ การทดสอบด้วยการเชื่อมต่อ 1 จุดก็เพียงพอแล้ว
ตัวอย่างเช่น IIS ทดสอบผู้ใช้ 5000 รายเสร็จภายใน 40 วินาที ซึ่งเท่ากับ 123 คำขอต่อวินาที
กราฟด้านล่างแสดงเวลาจนกว่าเนื้อหาไซต์จะถูกถ่ายโอนอย่างสมบูรณ์ นี่คือสัดส่วนของคำขอที่เสร็จสมบูรณ์ในเวลาที่กำหนด ในกรณีของเรา 80% ของคำขอทั้งหมดได้รับการประมวลผลใน 8 มิลลิวินาทีบน IIS และ 4.5 มิลลิวินาทีบน Apache และ Nginx และ 8% ของคำขอทั้งหมดบน Apache และ Nginx เสร็จสิ้นภายในช่วงเวลาสูงสุด 98 มิลลิวินาที
เวลาที่ประมวลผลคำขอ 5000 รายการ:
เวลาที่ประมวลผลคำขอ 5000 รายการ:
หากคุณมีเครื่องเสมือนที่มี CPU 3.5GHz และ 8 คอร์ ให้เลือกสิ่งที่คุณต้องการ เว็บเซิร์ฟเวอร์ทั้งหมดมีความคล้ายคลึงกันมากในการทดสอบนี้ เราจะพูดถึงเว็บเซิร์ฟเวอร์ที่จะเลือกสำหรับแต่ละโฮสต์ด้านล่าง
เมื่อพูดถึงสถานการณ์ที่สมจริงกว่านี้เล็กน้อย เว็บเซิร์ฟเวอร์ทั้งหมดจะต้องเผชิญหน้ากัน
ผ่าน:
กราฟความล่าช้าเทียบกับจำนวนการเชื่อมต่อพร้อมกัน นุ่มนวลและต่ำลงจะดีกว่า 2% สุดท้ายถูกลบออกจากแผนภูมิเนื่องจากจะทำให้ไม่สามารถอ่านได้
ตอนนี้ลองพิจารณาตัวเลือกที่เซิร์ฟเวอร์โฮสต์บนโฮสติ้งเสมือน ลองใช้ 4 คอร์ที่ 2.2 GHz และหนึ่งคอร์ที่ 1.8 GHz
วิธีการปรับขนาด
หากคุณเคยเห็นลักษณะเฉพาะของแรงดันกระแสของสุญญากาศไตรโอด เพนโทด และอื่นๆ กราฟเหล่านี้คงจะคุ้นเคยกับคุณ นี่คือสิ่งที่เราพยายามจับ - ความอิ่มตัว ขีดจำกัดคือเมื่อไม่ว่าคุณจะโยนคอร์ไปกี่คอร์ ประสิทธิภาพที่เพิ่มขึ้นก็จะไม่สังเกตเห็นได้ชัดเจน
ก่อนหน้านี้ ความท้าทายทั้งหมดคือการประมวลผลคำขอ 98% โดยมีเวลาแฝงต่ำที่สุดสำหรับคำขอทั้งหมด โดยรักษาเส้นโค้งให้เรียบที่สุดเท่าที่จะเป็นไปได้ ตอนนี้ ด้วยการสร้างเส้นโค้งอีกเส้นหนึ่ง เราจะพบจุดปฏิบัติการที่เหมาะสมที่สุดสำหรับแต่ละเซิร์ฟเวอร์
เมื่อต้องการทำเช่นนี้ ลองใช้ตัวบ่งชี้คำขอต่อวินาที (RPR) แนวนอนคือความถี่ แนวตั้งคือจำนวนคำขอที่ประมวลผลต่อวินาที เส้นคือจำนวนคอร์
แสดงความสัมพันธ์ว่ากระบวนการ Nginx ร้องขอทีละรายการได้ดีเพียงใด 8 คอร์ทำงานได้ดีกว่าในการทดสอบนี้
กราฟนี้แสดงให้เห็นอย่างชัดเจนว่า Nginx ทำงานได้ดีเพียงใด (ไม่มาก) บนคอร์เดียว หากคุณมี Nginx คุณควรพิจารณาลดจำนวนคอร์ให้เหลือหนึ่งคอร์หากคุณโฮสต์เฉพาะคอร์แบบคงที่
IIS แม้ว่าจะมี TTFB ต่ำที่สุดตาม DevTools ใน Chrome แต่ก็สามารถพ่ายแพ้ทั้ง Nginx และ Apache ในการต่อสู้อย่างจริงจังกับการทดสอบความเครียดจาก Apache Foundation
ความโค้งทั้งหมดของกราฟถูกจำลองขึ้นมาด้วยเกราะเหล็ก
ข้อสรุปบางประการ:
ใช่ Apache ทำงานได้แย่กว่าบน 1 และ 8 คอร์ แต่ทำงานได้ดีกว่าเล็กน้อยใน 4 คอร์
ใช่ Nginx บน 8 คอร์จะประมวลผลได้ดีขึ้นทีละคอร์บน 1 และ 4 คอร์ และทำงานได้แย่ลงเมื่อมีการเชื่อมต่อจำนวนมาก
ใช่ IIS ต้องการ 4 คอร์สำหรับปริมาณงานแบบมัลติเธรด และต้องการ 8 คอร์สำหรับปริมาณงานแบบเธรดเดียว ในที่สุด IIS ก็เร็วกว่าคนอื่นๆ เล็กน้อยบน 8 คอร์ภายใต้ภาระงานสูง แม้ว่าเซิร์ฟเวอร์ทั้งหมดจะพอๆ กันก็ตาม
นี่ไม่ใช่ข้อผิดพลาดในการวัด ข้อผิดพลาดที่นี่ไม่เกิน +-1ms ในความล่าช้าและไม่เกิน +- 2-3 คำขอต่อวินาทีสำหรับ RPR
ผลลัพธ์ที่ 8 คอร์ทำงานได้แย่ลงนั้นไม่น่าแปลกใจเลย คอร์จำนวนมากและ SMT/Hyperthreading ประสิทธิภาพจะลดลงอย่างมากหากเรามีกรอบเวลาที่เราต้องดำเนินการไปป์ไลน์ทั้งหมดให้เสร็จสิ้น
ที่มา: will.com