# กำหนดขนาดการถ่ายโอนด้วยการวัดเวลาแฝง การทำงานพร้อมกัน และปริมาณงาน | SwissOctet Insights

https://swissoctet.com/th/insights/size-throughput-with-bandwidth-delay/

SwissOctet / ข้อมูลเชิงลึก / วิศวกรรมเครือข่าย วิศวกรรมเครือข่าย ขั้นสูง · อ่าน 4 นาที

ขนาดการรับส่งข้อมูลด้วยการวัดความหน่วง การทำงานพร้อมกัน และปริมาณงาน

สร้างโมเดลการรับส่งข้อมูลที่ทำซ้ำได้โดยใช้ปริมาณเพย์โหลด หน้าต่างการส่งมอบ และเวลาตอบสนองไปกลับ จากนั้นทดสอบโดยไม่สับสนป้ายพอร์ตกับปริมาณงานที่มีประโยชน์

โดย SwissOctet Editorial บันทึกคู่มือ คัดลอกลิงก์

ในหน้านี้ 01 เปลี่ยนหน้าต่างการส่งมอบให้เป็นอัตรา 02 แยกความจุพอร์ตออกจากปริมาณงานที่มีประโยชน์ 03 เข้าใจว่าเหตุใดเวลาการไปกลับจึงสำคัญ 04 สร้างเมทริกซ์การทดสอบที่ควบคุมได้ 05 ดูที่ปลายทางทั้งสองระหว่างการทดสอบ 06 ทดสอบแอปพลิเคชันด้วยเพย์โหลดที่สมจริง 07 ใช้ผลลัพธ์เพื่อเลือกการกำหนดค่า รายการตรวจสอบปฏิบัติของคุณ แหล่งอ้างอิงและอ่านเพิ่มเติม กลับไปยังคลัง คำตอบตรงประเด็น คำนวณอัตราการถ่ายโอนที่มีประโยชน์ที่หน้าต่างการส่งมอบของคุณต้องการ จากนั้นวัดเส้นทางทั้งหมด ความจุพอร์ต เวลาการไปกลับ พฤติกรรม TCP ที่เก็บข้อมูล และการประมวลผลของแอปพลิเคชัน ล้วนมีผลต่อผลลัพธ์ ใช้การทดสอบที่ควบคุมได้ด้วยการทำงานพร้อมกันที่สมจริงและทำซ้ำผ่านแอปพลิเคชันจริงก่อนเลือกชั้นเครือข่าย

01 เปลี่ยนหน้าต่างการส่งมอบให้เป็นอัตรา

เริ่มจากปริมาณข้อมูลแอปพลิเคชันที่มีประโยชน์และเวลาที่มีสำหรับส่งมอบ โดยใช้หน่วยทศนิยม การถ่ายโอน 2 TB ในสองชั่วโมงต้องใช้เพย์โหลดประมาณ 278 MB ต่อวินาที หรือ 2.22 Gbps ก่อนเผื่อค่าใช้จ่ายของโปรโตคอลและการหยุดชะงัก การคำนวณนี้เป็นตัวอย่างการวางแผน ไม่ใช่ผลลัพธ์บริการที่วัดได้

รวมการถ่ายโอนที่ทับซ้อนกัน การส่งออกตามกำหนด การดาวน์โหลดของลูกค้า และการอัปโหลดข้อมูลสำรองสามารถใช้ทรัพยากรร่วมกันได้ แม้ยอดรวมรายเดือนจะดูไม่มาก เขียนแบบจำลองช่วงเวลาที่มีงานหนัก ไม่ใช่แค่ค่าเฉลี่ยรายเดือน ระบุว่าทิศทางใดสำคัญ และการถ่ายโอนที่ล้มเหลวต้องเริ่มใหม่หรือสามารถดำเนินต่อได้ พฤติกรรมนั้นมีผลต่อปริมาณงานที่ระบบต้องทำ

02 แยกความจุพอร์ตออกจากปริมาณงานที่มีประโยชน์

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

IETF RFC 6349 แยกความแตกต่างระหว่างการทดสอบเส้นทางเครือข่ายกับการตรวจสอบประสิทธิภาพ TCP อย่างชัดเจน ใช้การแยกนี้ในการวินิจฉัยของคุณเอง ขั้นแรกยืนยันว่าปลายทางและเส้นทางเหมาะสม จากนั้นตรวจสอบการขนส่งและแอปพลิเคชัน การเพิ่มพอร์ตที่ซื้อไม่ได้แก้ไขผู้รับที่เขียนข้อมูลช้าหรือแอปพลิเคชันที่ประมวลผลครั้งละหนึ่งคำขอ

03 เข้าใจว่าเหตุใดเวลาการไปกลับจึงสำคัญ

TCP ควบคุมว่าข้อมูลจำนวนเท่าใดสามารถอยู่ในระหว่างการส่งก่อนที่การตอบรับจะกลับมา ผลคูณแบนด์วิดท์-ดีเลย์ให้มาตรวัดที่มีประโยชน์สำหรับเรื่องนี้: อัตราคูณเวลาการไปกลับ เส้นทาง 10 Gbps สมมติที่มีความล่าช้าไปกลับ 40 มิลลิวินาที คิดเป็นข้อมูลระหว่างส่งประมาณ 50 MB การคำนวณนี้อธิบายว่าเหตุใดเวลาแฝงและพฤติกรรมการขนส่งจึงเป็นส่วนหนึ่งของการวางแผนความเร็วสูง

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

04 สร้างเมทริกซ์การทดสอบที่ควบคุมได้

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

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

การทดสอบ สิ่งที่ตรวจสอบ สิ่งที่ไม่ได้พิสูจน์

โฟลว์การขนส่งหนึ่งรายการ พฤติกรรมเส้นทางของโฟลว์เดียว การส่งมอบแอปพลิเคชันแบบรวม

โฟลว์ขนานหลายรายการ การทำงานพร้อมกันและขีดจำกัดรวม อัตราการถ่ายโอนของลูกค้ารายหนึ่ง

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

การทำซ้ำในช่วงเวลาที่มีงานหนัก ความแปรผันภายใต้กิจกรรมที่สมจริง การรับประกันปริมาณงานถาวร

05 ดูที่ปลายทางทั้งสองระหว่างการทดสอบ

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

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

06 ทดสอบแอปพลิเคชันด้วยเพย์โหลดที่สมจริง

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

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

07 ใช้ผลลัพธ์เพื่อเลือกการกำหนดค่า

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

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

เปลี่ยนเป็น行動 รายการตรวจสอบปฏิบัติของคุณ

✓ คำนวณอัตราเพย์โหลดจากปริมาณและกำหนดเวลา

✓ จำลองการถ่ายโอนที่ทับซ้อนกันและทิศทาง

✓ ตกลงปลายทางทดสอบและขีดจำกัดที่ได้รับอนุญาต

✓ เปรียบเทียบโฟลว์เดียว การทำงานพร้อมกัน และการทดสอบแอปพลิเคชัน

✓ สังเกตปลายทางทั้งสองขณะทดสอบ

✓ รักษาบาสไลน์ที่ทำซ้ำได้และระยะเผื่อที่มีประโยชน์

ดาวน์โหลดรายการตรวจสอบ

คำถามที่พบบ่อย รายละเอียดที่สำคัญ

หน้าต่าง TCP ที่ใหญ่ขึ้นแก้ไขการถ่ายโอนที่ช้าได้เสมอหรือไม่ +

ไม่ วินิจฉัยเส้นทางและปลายทางก่อน ที่เก็บข้อมูล CPU การสูญหาย และพฤติกรรมแอปพลิเคชันอาจมีอิทธิพลเหนือกว่า และการปรับแต่งการขนส่งต้องเหมาะกับระบบจริง

เหตุใดจึงทดสอบโฟลว์เดียวและหลายโฟลว์ +

ทั้งสองตอบคำถามที่ต่างกัน ความจุรวมอาจสูงกว่าอัตราของการถ่ายโอนหนึ่งรายการ การทำงานพร้อมกันของแอปพลิเคชันเป็นตัวกำหนดว่าผลลัพธ์ใดสำคัญ

ฉันสามารถทดสอบความจุกับเซิร์ฟเวอร์สาธารณะใดก็ได้หรือไม่ +

ใช้ปลายทางที่คุณควบคุมหรือได้รับอนุญาตให้ทดสอบ ตกลงระยะเวลา อัตรา และจังหวะเวลา เพื่อให้การวัดไม่รบกวนบริการที่ไม่เกี่ยวข้อง

แหล่งอ้างอิงหลัก ไปที่ต้นทาง

แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน

IETF RFC 6349: กรอบการทำงานสำหรับการทดสอบปริมาณงาน TCP datatracker.ietf.org

ESnet: การเรียกใช้ iperf3 software.es.net

คำแนะนำด้านบรรณาธิการโดย SwissOctet ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก

เชื่อมโยงความรู้ โครงสร้างพื้นฐานที่เกี่ยวข้อง

Metal Atlas สวิตเซอร์แลนด์ Transit 40 สวิตเซอร์แลนด์ Transit 100 สวิตเซอร์แลนด์

รักษาสายไว้ บันทึกภาคสนามถัดไปของคุณ

สำรวจทุกคู่มือ

บันทึกภาคสนาม / 01

+

เฉพาะเครื่องและ GPU พื้นฐาน

VPS หรือเฉพาะ: เลือกขอบเขตที่เหมาะสม

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

อ่าน 4 นาที อ่านคู่มือ

บันทึกภาคสนาม / 02

+

วิศวกรรมเครือข่าย พื้นฐาน

แบนด์วิดท์ ความเร็วพอร์ต และการรับส่งข้อมูล: อ่านภาพรวมทั้งหมด

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

อ่าน 4 นาที อ่านคู่มือ

บันทึกภาคสนาม / 03

+

วิศวกรรมเครือข่าย ขั้นสูง

วางแผน 40, 100 หรือ 200 Gbps origin เป็นระบบที่สมบูรณ์

แปลคลาสพอร์ตขนาดใหญ่เป็นคำถามด้านพื้นที่จัดเก็บ CPU การทำงานพร้อมกัน และการดำเนินงาน ก่อนเลือกการกำหนดค่าการกระจายปริมาณสูง

อ่าน 4 นาที อ่านคู่มือ