จุดใดที่การอ่านแบบอะซิงโครนัสของดิสก์ I / O มีประสิทธิภาพมากกว่าแบบซิงโครนัส

22

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

ฉันสังเกตเห็น (และบางทีฉันไม่ถูกต้อง) ว่าเมื่ออ่านไฟล์ที่มีขนาดเล็กมากมันใช้เวลานานในการอ่านแบบอะซิงโครนัสมากกว่าแบบซิงโครนัส (โดยเฉพาะกับ. NET) ฉันสมมติว่าสิ่งนี้เกี่ยวข้องกับการตั้งค่าเวลาสำหรับสิ่งต่างๆเช่นพอร์ต I / O Completion Port, เธรดและอื่น ๆ

มีกฎง่ายๆที่จะช่วยออกที่นี่? หรือมันขึ้นอยู่กับระบบและสิ่งแวดล้อม?

— blesh
แหล่งที่มา

คุณสามารถให้รหัสที่คุณใช้เป็นเกณฑ์มาตรฐานได้หรือไม่? ฉันคิดว่าสิ่งนี้อาจเกิดขึ้นเฉพาะในกรณีที่ขนาดไฟล์เล็กกว่าขนาดบัฟเฟอร์ภายในของตัวอ่านสตรีม แต่ถ้าคุณต้องอ่านไฟล์ขนาดเล็กจำนวนมากคุณอาจจะประสบปัญหาอื่น ๆ กับดิสก์ i / o

— Daniel Iankov

ฉันไม่มีรหัสที่มีประโยชน์ฉันกลัว มันเป็นสิ่งที่ฉันวิ่งกลับไปพักหนึ่งและมันก็อยู่ในใจของฉันตั้งแต่นั้นมา รหัสอยู่ใน. NET และเป็นหลัก File.ReadAllBytes () เทียบกับ FileStream.BeginRead () ในการวนรอบ

— blesh

เมื่อเส้นโค้งที่แสดงถึงประสิทธิภาพข้ามและ async IO ออกจากการข้ามที่ค่าสูงกว่าการโค้ง IO ของการซิงค์

— Thomas Eding

14

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

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

— มาร์ตินซีมาร์ติน
แหล่งที่มา

1

ใช่ฉันคิดมาก ฉันคิดว่าฉันหวังว่าจะมีการศึกษาบางประเภทที่จะใช้เป็นแนวทางหรือกฎง่ายๆ

— blesh

9

Async มี 3 ข้อได้เปรียบหลัก:

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

ฉันเชื่อว่าประโยชน์หลักของการอ่านแบบอะซิงโครนัสคือเมื่อคุณทำงานกับไฟล์จำนวนมากหรือคุณต้องการพลังงาน CPU มาก

— ร่าเริง
แหล่งที่มา

หมายเหตุสำหรับจุดที่ 2 ว่าจะไม่ปรับสิ่งใดให้เหมาะสมหากการดำเนินการ I / O เป็นคอขวด สิ่งต่าง ๆ หากคุณเข้าถึงแบบขนานผ่าน RAID หรือเครือข่ายไฟล์ที่อยู่บนดิสก์ที่แตกต่างกัน

— Arseni Mourzenko

5

อืมฉันมีปัญหาในการทำความเข้าใจความหมายของ # 1 ฉันจะบอกว่ามันเป็นอีกวิธีหนึ่งในการฝึกฝน เนื่องจากด้วยกรณี async ตอนนี้คุณจึงเปลี่ยนเธรดของคุณจากblocked waiting for I/O(0% CPU) เป็นcontinue normal processing(> 0% CPU)

— Isak Savo

3

มันขึ้นอยู่กับ

สิ่งหนึ่งที่ต้องจำไว้คือราคาจะเปลี่ยนบริบทระหว่างกระบวนการอย่างไร Node.JS ได้รับการออกแบบในแบบที่มันเป็นเพราะมันคิดว่าการทำ context switch นั้นมีราคาแพงมากและคุณจะมีกระบวนการมากมายที่รอคอย IE ซึ่งจะทำให้คอมพิวเตอร์ชะงัก

ในทางกลับกัน Erlang ทำให้การสลับบริบทของกระบวนการมีราคาถูกมากดังนั้นทุกอย่างสามารถซิงโครนัสได้และเวลาทำงานของ Erlang สามารถติดตามทุกสิ่งได้

ดังนั้นปัจจัยที่ต้องพิจารณา:

ต้นทุนของการดำเนินการสลับบริบท
ความเร็วของดิสก์สำหรับการดำเนินการค้นหา
ความเร็วของดิสก์สำหรับการอ่าน
คือไฟล์ในแคช

และฉันมั่นใจว่าฉันกำลังทิ้งปัจจัยครึ่งโหลไว้

— Zachary K
แหล่งที่มา

2

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

— TMN
แหล่งที่มา

ใช่นั่นเป็นจุดรวมของการทำมัลติเธรด!

— Vlad

1

ฉันคิดว่าปัญหาที่นี่ไม่ใช่ความเร็วในการอ่านมากนักเนื่องจากมันเป็นเวลาแฝง

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

— coder
แหล่งที่มา