สิ่งนี้พิสูจน์ได้ว่าเป็นปัญหาคอขวดแบนด์วิดท์ของเครือข่ายหรือไม่


14

ฉันสันนิษฐานว่าการทดสอบ AB ภายในของฉันไม่ถูกต้องหมายความว่าเซิร์ฟเวอร์ของฉันสามารถจัดการ 1k concurrency @ 3k hits ต่อวินาที

ทฤษฎีของฉันในขณะนี้คือเครือข่ายเป็นคอขวด เซิร์ฟเวอร์ไม่สามารถส่งข้อมูลได้เร็วพอ

การทดสอบภายนอกจาก blitz.io ที่ 1k เห็นพ้องด้วยแสดงจำนวนครั้งที่ฉันเข้าชมสูงสุดที่ 180 โดยใช้เวลานานขึ้นและนานขึ้นในการตอบกลับเนื่องจากเซิร์ฟเวอร์สามารถส่งคืนได้ 180 ต่อวินาทีเท่านั้น

ป้อนคำอธิบายรูปภาพที่นี่

ฉันทำหน้าที่ไฟล์เปล่าจาก nginx และ benched มันมันชั่ง 1: 1 พร้อมกัน

ป้อนคำอธิบายรูปภาพที่นี่

ตอนนี้เพื่อแยกคอขวด IO / memcached (โดยปกติแล้ว nginx จะดึงจาก memcached) ฉันให้บริการหน้าแคชรุ่นคงที่จากระบบไฟล์

ป้อนคำอธิบายรูปภาพที่นี่

ผลลัพธ์คล้ายกันมากกับการทดสอบดั้งเดิมของฉัน ฉันปกคลุมที่ประมาณ 180 RPS

การแยกหน้า HTML ออกครึ่งหนึ่งจะให้ RPS สองเท่าดังนั้นมันจึงถูก จำกัด ด้วยขนาดของหน้า

ป้อนคำอธิบายรูปภาพที่นี่

ถ้าฉันภายใน ApacheBench จากเซิร์ฟเวอร์ภายในฉันได้รับผลลัพธ์ที่สอดคล้องกันประมาณ 4k RPS ทั้งบนหน้าเต็มและครึ่งหน้าในอัตราการถ่ายโอนสูง อัตราการถ่ายโอน: ได้รับ 62586.14 [Kbytes / วินาที]

ถ้าฉัน AB จากเซิร์ฟเวอร์ภายนอกฉันจะได้ประมาณ 180RPS - เหมือนกับผลลัพธ์ blitz.io

ฉันจะรู้ได้อย่างไรว่าไม่ใช่การควบคุมปริมาณโดยเจตนา

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

ดังนั้นฉันกลับไปที่ข้อสรุปว่าเซิร์ฟเวอร์ของฉันไม่สามารถส่งข้อมูลได้เร็วพอ

ฉันถูกไหม? มีวิธีอื่นในการตีความข้อมูลนี้หรือไม่? วิธีแก้ปัญหา / การปรับให้เหมาะสมในการตั้งค่าเซิร์ฟเวอร์หลายตัว + การทำโหลดบาลานซ์ที่แต่ละเซิร์ฟเวอร์สามารถรับชมได้ 180 ครั้งต่อวินาทีหรือไม่?

ฉันค่อนข้างใหม่กับการปรับแต่งเซิร์ฟเวอร์ดังนั้นฉันขอขอบคุณที่ยืนยันการตีความข้อมูลนี้


การรับส่งข้อมูลขาออก

ต่อไปนี้เป็นข้อมูลเพิ่มเติมเกี่ยวกับแบนด์วิดท์ขาออก: กราฟเครือข่ายแสดงเอาต์พุตสูงสุด 16 Mb / s: 16 เมกะบิตต่อวินาที ฟังดูไม่ค่อยชอบเลย

เนื่องจากข้อเสนอแนะเกี่ยวกับการควบคุมปริมาณฉันจึงตรวจสอบเรื่องนี้และพบว่า linode มีขีดสูงสุด 50mbps (ซึ่งฉันไม่ได้ใกล้เคียงกับการชน) ฉันเพิ่มมันเป็น 100mbps

ตั้งแต่ linode จำกัด ปริมาณการใช้งานของฉันและฉันไม่ได้กดปุ่มนี่หมายความว่าเซิร์ฟเวอร์ของฉันควรสามารถแสดงผลได้สูงสุดถึง 100mbps แต่ถูก จำกัด ด้วยคอขวดภายในอื่น ฉันไม่เข้าใจว่าเครือข่ายขนาดใหญ่นี้ทำงานอย่างไร พวกเขาสามารถส่งข้อมูลได้เร็วเท่าที่พวกเขาสามารถอ่านจาก HDD ได้หรือไม่? คือท่อเครือข่ายที่ใหญ่?

ป้อนคำอธิบายรูปภาพที่นี่


สรุปแล้ว

1: จากข้างต้นฉันคิดว่าฉันสามารถยกระดับ 180RPS ของฉันได้อย่างแน่นอนโดยเพิ่มตัวโหลดบาลานซ์ของ nginx ที่ด้านบนของการตั้งค่าเซิร์ฟเวอร์ nginx หลายตัวที่ 180RPS ต่อเซิร์ฟเวอร์ที่อยู่ด้านหลัง LB

2: หาก linode มีขีด จำกัด 50/100mbit ที่ฉันไม่ได้กดปุ่มเลยต้องมีบางอย่างที่ฉันสามารถทำได้เพื่อให้ถึงขีด จำกัด นั้นด้วยการตั้งค่าเซิร์ฟเวอร์เดียวของฉัน ถ้าฉันสามารถอ่าน / ส่งข้อมูลเร็วพอในพื้นที่และแม้แต่ลินุกซ์ก็ยังมีหมวก 50mbit / 100mbit ต้องมีคอขวดภายในที่ไม่อนุญาตให้ฉันกดปุ่มเหล่านั้นที่ฉันไม่แน่ใจว่าจะตรวจจับได้อย่างไร แก้ไข?

ฉันรู้ว่าตอนนี้คำถามมีขนาดใหญ่และคลุมเครือ แต่ฉันไม่แน่ใจว่าจะย่อหย่อนได้อย่างไร ข้อมูลใด ๆ ที่ชื่นชมในข้อสรุปใด ๆ ที่ฉันทำ


1
ในการตรวจสอบว่าเป็นปัญหาเกี่ยวกับแบนด์วิดท์หรือไม่คุณสามารถเพิ่มหน้า html ของคุณให้ใหญ่ขึ้นได้ หากหน้าของคุณมีขนาดใหญ่ขึ้นเช่น 5MB คุณควรจะสามารถเข้าถึงปริมาณงานเดียวกันด้วยการร้องขอเพียงไม่กี่ครั้ง / วินาทีซึ่งจะมีค่าใช้จ่ายน้อยกว่ามากและให้คุณเข้าใกล้ขีด จำกัด แบนด์วิดท์จริง
brain99

ฉันเพิ่งทดสอบหน้าที่มีขนาดเท่ากับ 10x RPS ของฉันสัมพันธ์โดยตรงกับขนาดหน้ากระดาษ ขนาดใหญ่กว่า 10x == 18RPS 1x == 180 ฉันคิดว่านี่น่าสงสัยใกล้กับ 50mbits ฉันคิดว่ามีโอกาสตรวจสอบสถานะ linode สูงสุด 24mbits อาจผิดและจริง ๆ แล้วฉันกดปุ่มหมวกของพวกเขา ฉันขอเพิ่มอีกครั้งและจะรายงานกลับ
Yuji Tomita

คำตอบ:


5

ปัญหาคือฉันสมมติว่ากราฟยอด linode.com เป็นยอดจริง ปรากฎว่ากราฟใช้จุดข้อมูลเฉลี่ย 5 นาทีดังนั้นจุดสูงสุดของฉันดูเหมือนจะเป็น 24mbits เมื่อจริง ๆ แล้วฉันกดปุ่ม 50mbit

ตอนนี้พวกเขาเพิ่มมันเป็น 100mbb แล้วมาตรฐานของฉันก็เพิ่มขึ้นถึงขีด จำกัด การจราจรขาออกใหม่ทันที

ถ้าเพียงฉันได้สังเกตเห็นว่าก่อนหน้านี้! มีเหตุผลมากมายที่ทำให้ฉันคิดว่าฉันไม่ได้ จำกัด ปริมาณการใช้งานขาออกเนื่องจากกราฟนั้น

ตอนนี้ฉันถึงจุดสูงสุดที่ 370 คำขอต่อวินาทีซึ่งอยู่ต่ำกว่า 100mbps ที่จุดนี้ฉันเริ่มได้รับ "backlog" ของการร้องขอและเวลาตอบสนองเริ่มขึ้น

ป้อนคำอธิบายรูปภาพที่นี่

ตอนนี้ฉันสามารถเพิ่มการเกิดพร้อมกันสูงสุดโดยลดขนาดหน้า; ด้วยการเปิดใช้งาน gzip ฉันจะได้รับ 600RPS

ป้อนคำอธิบายรูปภาพที่นี่

ฉันยังคงประสบปัญหาเมื่อถึงจุดสูงสุดและยอดค้างของคำขอที่รอดำเนินการ (ถูก จำกัด โดยแบนด์วิดท์) เริ่มสะสม แต่นั่นฟังดูเหมือนคำถามที่แตกต่าง

ป้อนคำอธิบายรูปภาพที่นี่

มันเป็นบทเรียนที่ยอดเยี่ยมในการเพิ่มประสิทธิภาพ / อ่านข้อมูลนี้ / ลดปัญหาที่อาจเกิดขึ้น ขอบคุณมากสำหรับข้อมูลของคุณ!


4

ช้าไปหน่อยที่คุณคิดออก ... แต่บางทีคุณควรลองอ่านบล็อก ServerFault เป็นครั้งคราว

ฉันกำลังคิดถึงโพสต์นี้เป็นพิเศษโดยที่พวกเขาพูดคุยกันว่าทำไมการมีช่วงเวลาการโพลหนึ่งวินาทีไม่ได้ลดลงเป็นครั้งคราวเกี่ยวข้องกับปัญหาที่คล้ายกันมากกับที่คุณมี ..

เราค้นพบว่าเราทิ้งแพ็คเก็ตบ่อยๆบน 1 Gbit / s อินเตอร์เฟสที่อัตราเพียง 10-30 MBit / s ซึ่งทำให้ประสิทธิภาพของเราแย่ลง เนื่องจากอัตรา 10-30 MBit / s นั้นเป็นจำนวนบิตที่ถ่ายโอนต่อ 5 นาทีที่ถูกแปลงเป็นอัตราหนึ่งวินาที เมื่อเราขุดเข้าไปใกล้กับ Wireshark และใช้กราฟ IO หนึ่งมิลลิวินาทีเราเห็นว่าเรามักจะปล่อยอัตรา 1 Mbit ต่อมิลลิวินาทีของส่วนต่อประสานที่เรียกว่า 1 Gbit / s

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

ใครจะรู้ฉันอาจให้บางคนในที่ลับ :)


จุดดี! พวกเขาสนใจกราฟ 5 นาทีที่อัตรา 1 วินาทีด้วย ... ฉันค่อนข้างสบายใจกับข้อมูลเพราะการทดสอบ 1k ของฉันพร้อมกันนั้นเป็นจุดสูงสุดที่แย่ที่สุด (ฉันคิดว่า .. ) ผู้ใช้ประมาณ 600 คนกำลังโหลดหน้าเว็บทุกวินาที == ~ 2m ต่อชั่วโมงซึ่งเราไม่ได้เข้าใกล้ ฉันไม่ต้องการที่จะชะงักลงในไม่กี่นาทีแรกของเข็ม
Yuji Tomita

0

อาจถูก จำกัด โดยเครือข่าย แต่ไม่จำเป็นต้องเป็นเพียงคำถามเกี่ยวกับแบนด์วิดท์ เวลาแฝงของหน่วยทดสอบระยะไกลของคุณจะมีผลต่อจำนวนการเชื่อมต่อที่ค้างอยู่ ณ เวลาใด ๆ (การรอ 50 มิลลิวินาทีสำหรับการตอบรับจะแตกต่างจาก. 5ms ในเครื่อง) เช่นเดียวกับการเจรจาต่อรองและความเสถียรของขนาดหน้าต่าง นอกจากนี้คุณยังอาจได้รับผลกระทบจากการสูญเสียแพ็กเก็ตบางส่วนไม่ว่าจะเป็นความแออัดหรือเป็นกลไกของการ จำกัด แบนด์วิดท์ในส่วนของผู้ให้บริการของคุณ (หรือต้นน้ำเหล่านั้น)

ฉันขอแนะนำให้กำจัดมากที่สุดเท่าที่เป็นไปได้จากสมการเพื่อวาดพื้นฐานที่เหมาะสม วัดแบนด์วิดท์สูงสุดความหน่วงและการสูญหายของแพ็คเก็ตจากเซิร์ฟเวอร์ของคุณไปยังจุดต่าง ๆ บนอินเทอร์เน็ตทั่วไป ไม่น่าจะฟังได้ลองค้นหา "Voip traffic test" หรือคล้ายกัน ผู้ให้บริการ VOIP หลายรายมีแอพที่สามารถวัดรูปแบบเหล่านี้ (แบบสองทิศทาง) ด้วยความแม่นยำระดับยุติธรรม เมื่อคุณมีข้อมูลเชิงประจักษ์ที่ถูกต้องเกี่ยวกับความเร็วที่เป็นประโยชน์จริงของลิงก์ของคุณผลลัพธ์ของคุณอาจได้รับการตรวจสอบแล้ว

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.