คำนวณอัตราการถ่ายโอนที่มีประโยชน์ที่หน้าต่างการส่งมอบของคุณต้องการ จากนั้นวัดเส้นทางทั้งหมด ความจุพอร์ต เวลาการไปกลับ พฤติกรรม TCP ที่เก็บข้อมูล และการประมวลผลของแอปพลิเคชัน ล้วนมีผลต่อผลลัพธ์ ใช้การทดสอบที่ควบคุมได้ด้วยการทำงานพร้อมกันที่สมจริงและทำซ้ำผ่านแอปพลิเคชันจริงก่อนเลือกชั้นเครือข่าย
เปลี่ยนหน้าต่างการส่งมอบให้เป็นอัตรา
เริ่มจากปริมาณข้อมูลแอปพลิเคชันที่มีประโยชน์และเวลาที่มีสำหรับส่งมอบ โดยใช้หน่วยทศนิยม การถ่ายโอน 2 TB ในสองชั่วโมงต้องใช้เพย์โหลดประมาณ 278 MB ต่อวินาที หรือ 2.22 Gbps ก่อนเผื่อค่าใช้จ่ายของโปรโตคอลและการหยุดชะงัก การคำนวณนี้เป็นตัวอย่างการวางแผน ไม่ใช่ผลลัพธ์บริการที่วัดได้
รวมการถ่ายโอนที่ทับซ้อนกัน การส่งออกตามกำหนด การดาวน์โหลดของลูกค้า และการอัปโหลดข้อมูลสำรองสามารถใช้ทรัพยากรร่วมกันได้ แม้ยอดรวมรายเดือนจะดูไม่มาก เขียนแบบจำลองช่วงเวลาที่มีงานหนัก ไม่ใช่แค่ค่าเฉลี่ยรายเดือน ระบุว่าทิศทางใดสำคัญ และการถ่ายโอนที่ล้มเหลวต้องเริ่มใหม่หรือสามารถดำเนินต่อได้ พฤติกรรมนั้นมีผลต่อปริมาณงานที่ระบบต้องทำ
แยกความจุพอร์ตออกจากปริมาณงานที่มีประโยชน์
พอร์ตของเซิร์ฟเวอร์อธิบายความจุลิงก์ ปริมาณงานที่มีประโยชน์อธิบายข้อมูลที่แอปพลิเคชันของคุณส่งมอบในช่วงเวลาที่สังเกต การเข้ารหัส การจัดเฟรมโปรโตคอล การส่งซ้ำ กิจกรรมที่เก็บข้อมูล และงานที่ผู้รับ ต่างก็ใช้ส่วนหนึ่งของเส้นทางนั้น ดังนั้นพอร์ต 10 Gbps ที่ระบุไว้จึงไม่ได้ยืนยันว่าแอปพลิเคชันจะส่งมอบเพย์โหลด 10 Gbps อย่างต่อเนื่อง
IETF RFC 6349 แยกความแตกต่างระหว่างการทดสอบเส้นทางเครือข่ายกับการตรวจสอบประสิทธิภาพ TCP อย่างชัดเจน ใช้การแยกนี้ในการวินิจฉัยของคุณเอง ขั้นแรกยืนยันว่าปลายทางและเส้นทางเหมาะสม จากนั้นตรวจสอบการขนส่งและแอปพลิเคชัน การเพิ่มพอร์ตที่ซื้อไม่ได้แก้ไขผู้รับที่เขียนข้อมูลช้าหรือแอปพลิเคชันที่ประมวลผลครั้งละหนึ่งคำขอ
เข้าใจว่าเหตุใดเวลาการไปกลับจึงสำคัญ
TCP ควบคุมว่าข้อมูลจำนวนเท่าใดสามารถอยู่ในระหว่างการส่งก่อนที่การตอบรับจะกลับมา ผลคูณแบนด์วิดท์-ดีเลย์ให้มาตรวัดที่มีประโยชน์สำหรับเรื่องนี้: อัตราคูณเวลาการไปกลับ เส้นทาง 10 Gbps สมมติที่มีความล่าช้าไปกลับ 40 มิลลิวินาที คิดเป็นข้อมูลระหว่างส่งประมาณ 50 MB การคำนวณนี้อธิบายว่าเหตุใดเวลาแฝงและพฤติกรรมการขนส่งจึงเป็นส่วนหนึ่งของการวางแผนความเร็วสูง
ผลลัพธ์ไม่ใช่คำสั่งให้ใช้การตั้งค่าซ็อกเก็ตตามอำเภอใจ ระบบปฏิบัติการ การควบคุมความแออัด หน้าต่างที่เจรจา และเส้นทางจริงมีอิทธิพลต่อพฤติกรรม ตรวจสอบเอกสารซอฟต์แวร์ปัจจุบันและตรวจดูการวัดก่อนปรับแต่ง การเชื่อมต่อแบบขนานที่มากขึ้นอาจปรับปรุงปริมาณงานรวมในบางสถานการณ์ แต่ก็อาจซ่อนพฤติกรรมของการถ่ายโอนแต่ละรายการที่แอปพลิเคชันของคุณพึ่งพาได้เช่นกัน
สร้างเมทริกซ์การทดสอบที่ควบคุมได้
ใช้เฉพาะปลายทางที่คุณเป็นเจ้าของหรือได้รับอนุญาตให้ทดสอบ ตกลงช่วงเวลาทดสอบและอัตราเพื่อให้แบบฝึกหัดไม่รบกวนบริการปกติ เครื่องมือเช่น iperf3 มีทิศทาง ระยะเวลา และสตรีมแบบขนานที่กำหนดค่าได้ เอกสารอย่างเป็นทางการนิยามการควบคุมเหล่านั้น บันทึกเวอร์ชัน ปลายทาง บริบทเส้นทาง และการตั้งค่าพร้อมผลลัพธ์ เพื่อให้ผู้ดำเนินการรายอื่นทำซ้ำได้
เริ่มจากโฟลว์เดียว จากนั้นเพิ่มการทำงานพร้อมกันที่เป็นตัวแทน รันทั้งสองทิศทางหากแอปพลิเคชันพึ่งพาทั้งสอง เมทริกซ์ตัวอย่างนี้แยกคำถามที่ผลลัพธ์พาดหัวเดียวจะปะปนกัน เก็บผลลัพธ์ดิบไว้เป็นส่วนตัวเมื่อเปิดเผยที่อยู่ภายในหรือรายละเอียดการดำเนินงาน และเผยแพร่เฉพาะการวัดที่จำเป็นสำหรับการตัดสินใจ
| การทดสอบ | สิ่งที่ตรวจสอบ | สิ่งที่ไม่ได้พิสูจน์ |
|---|---|---|
| โฟลว์การขนส่งหนึ่งรายการ | พฤติกรรมเส้นทางของโฟลว์เดียว | การส่งมอบแอปพลิเคชันแบบรวม |
| โฟลว์ขนานหลายรายการ | การทำงานพร้อมกันและขีดจำกัดรวม | อัตราการถ่ายโอนของลูกค้ารายหนึ่ง |
| การถ่ายโอนของแอปพลิเคชัน | ที่เก็บข้อมูล โปรโตคอล และซอฟต์แวร์ร่วมกัน | ประสิทธิภาพสำหรับทุกชุดข้อมูล |
| การทำซ้ำในช่วงเวลาที่มีงานหนัก | ความแปรผันภายใต้กิจกรรมที่สมจริง | การรับประกันปริมาณงานถาวร |
ดูที่ปลายทางทั้งสองระหว่างการทดสอบ
บันทึกการใช้งาน CPU ความกดดันหน่วยความจำ กิจกรรมที่เก็บข้อมูล และตัวนับข้อผิดพลาดที่ปลายทางทั้งสอง ผลลัพธ์การถ่ายโอนที่ไม่มีการสังเกตปลายทางอาจทำให้ข้อจำกัดจริงมองไม่เห็น ตรวจสอบว่ากระบวนการหนึ่งหรือ CPU อิ่มตัวในขณะที่ส่วนอื่นว่างหรือไม่ หลีกเลี่ยงการเปลี่ยนการตั้งค่าหลายอย่างพร้อมกัน เพราะทำให้ระบุได้ยากว่าการปรับใดช่วยได้
แยกการทดสอบที่ใช้หน่วยความจำรองรับออกจากการทดสอบที่อ่านและเขียนข้อมูลจริง แบบแรกช่วยตรวจสอบเส้นทางการขนส่งได้ แบบหลังสะท้อนงานของแอปพลิเคชันได้มากกว่า หากผลลัพธ์ต่างกันมาก ให้ตรวจสอบที่เก็บข้อมูลและการประมวลผล แทนที่จะถือตัวเลขที่ใช้หน่วยความจำรองรับเป็นคำสัญญาการส่งมอบ การวัดทั้งสองแบบมีประโยชน์เมื่อขอบเขตชัดเจน
ทดสอบแอปพลิเคชันด้วยเพย์โหลดที่สมจริง
การส่งออก HTTP สตรีมการจำลองแบบที่เข้ารหัส และเซสชันการถ่ายโอนไฟล์มีรูปแบบการประมวลผลที่ต่างกัน ใช้ขนาดไฟล์ อัตราคำขอ และการตั้งค่าการเข้ารหัสที่เป็นตัวแทน รวมเวลาที่ใช้เตรียมข้อมูลก่อนส่งไบต์แรกเมื่อผู้ใช้รอขั้นตอนนั้น แยกความหน่วงของการตอบกลับครั้งแรกออกจากเวลาที่เสร็จสิ้น แทนที่จะรายงานอย่างหนึ่งเป็นอีกอย่างหนึ่ง
ทำการทดสอบซ้ำในช่วงเวลาที่มากพอเพื่อดูความแปรผัน และเก็บบาสไลน์ก่อนเปลี่ยนการกำหนดค่า สำหรับการส่งออก 2 TB สมมติ ให้เปรียบเทียบเวลาที่เสร็จสิ้นจริงกับหน้าต่างสองชั่วโมงและเผื่อระยะสำหรับการหยุดชะงัก เลือกการปรับปรุงตามคอขวดที่สังเกตได้ แทนที่จะคูณความจุพอร์ตโดยไม่มีเหตุผล
ใช้ผลลัพธ์เพื่อเลือกการกำหนดค่า
ผลลัพธ์ที่มีประโยชน์คือข้อกำหนดทรัพยากรพร้อมหลักฐาน: อัตราเพย์โหลดที่วัดได้ เวลาที่เสร็จสิ้นที่ยอมรับได้ การทำงานพร้อมกันที่คาดหวัง และขั้นตอนที่จำกัดซึ่งทราบแล้ว เปรียบเทียบตัวเลือกเครือข่าย SwissOctet กับข้อกำหนดนั้น รวมถึงปริมาณทราฟฟิกที่อนุญาตและข้อกำหนด CPU และที่เก็บข้อมูล ตำแหน่งเพียงอย่างเดียวไม่ได้กำหนดเส้นทางหรือเวลาแฝงแบบปลายถึงปลายไปยังผู้รับทุกคน
เก็บขั้นตอนการทดสอบไว้หลังการปรับใช้ ใช้ซ้ำเมื่อชุดข้อมูลเติบโต ซอฟต์แวร์เปลี่ยน หรือผู้ใช้ย้ายไปเครือข่ายอื่น บาสไลน์ที่ทำซ้ำได้ทำให้วินิจฉัยเหตุการณ์ด้านประสิทธิภาพได้ง่ายขึ้น และให้เหตุผลที่หนักแน่นกว่าสำหรับการเปลี่ยนการกำหนดค่า มากกว่าการทดสอบความเร็วแบบแยกส่วนหรือค่าสูงสุดที่โฆษณาไว้
รายการตรวจสอบปฏิบัติของคุณ
- คำนวณอัตราเพย์โหลดจากปริมาณและกำหนดเวลา
- จำลองการถ่ายโอนที่ทับซ้อนกันและทิศทาง
- ตกลงปลายทางทดสอบและขีดจำกัดที่ได้รับอนุญาต
- เปรียบเทียบโฟลว์เดียว การทำงานพร้อมกัน และการทดสอบแอปพลิเคชัน
- สังเกตปลายทางทั้งสองขณะทดสอบ
- รักษาบาสไลน์ที่ทำซ้ำได้และระยะเผื่อที่มีประโยชน์
รายละเอียดที่สำคัญ
หน้าต่าง TCP ที่ใหญ่ขึ้นแก้ไขการถ่ายโอนที่ช้าได้เสมอหรือไม่+
ไม่ วินิจฉัยเส้นทางและปลายทางก่อน ที่เก็บข้อมูล CPU การสูญหาย และพฤติกรรมแอปพลิเคชันอาจมีอิทธิพลเหนือกว่า และการปรับแต่งการขนส่งต้องเหมาะกับระบบจริง
เหตุใดจึงทดสอบโฟลว์เดียวและหลายโฟลว์+
ทั้งสองตอบคำถามที่ต่างกัน ความจุรวมอาจสูงกว่าอัตราของการถ่ายโอนหนึ่งรายการ การทำงานพร้อมกันของแอปพลิเคชันเป็นตัวกำหนดว่าผลลัพธ์ใดสำคัญ
ฉันสามารถทดสอบความจุกับเซิร์ฟเวอร์สาธารณะใดก็ได้หรือไม่+
ใช้ปลายทางที่คุณควบคุมหรือได้รับอนุญาตให้ทดสอบ ตกลงระยะเวลา อัตรา และจังหวะเวลา เพื่อให้การวัดไม่รบกวนบริการที่ไม่เกี่ยวข้อง
ไปที่ต้นทาง
แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน
- IETF RFC 6349: กรอบการทำงานสำหรับการทดสอบปริมาณงาน TCP datatracker.ietf.org
- ESnet: การเรียกใช้ iperf3 software.es.net
คำแนะนำด้านบรรณาธิการโดย SwissOctet ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก