เมื่อใดที่ฉันควรใช้ Async Controllers ใน ASP.NET MVC

ฉันมีข้อกังวลบางอย่างเกี่ยวกับการใช้การกระทำของ async ใน ASP.NET MVC เมื่อไหร่มันจะปรับปรุงประสิทธิภาพการทำงานของแอพพลิเคของฉันและเมื่อไม่ได้ไม่ได้ ?

1. มันเป็นการดีที่จะใช้ async การกระทำทุกที่ใน ASP.NET MVC?
2. เกี่ยวกับวิธีการที่รอคอย: ฉันจะใช้ async / คอยคำสำคัญเมื่อฉันต้องการสอบถามฐานข้อมูล (ผ่าน EF / NHibernate / ORM อื่น ๆ )
3. กี่ครั้งที่ฉันสามารถใช้คำหลักที่รอคอยที่จะสอบถามฐานข้อมูลแบบไม่พร้อมกันในหนึ่งวิธีการดำเนินการเดียว?

วิธีการดำเนินการแบบอะซิงโครนัสมีประโยชน์เมื่อการดำเนินการต้องดำเนินการกับการดำเนินการที่รันนานหลายครั้ง

การใช้งานทั่วไปสำหรับคลาส AsyncController เป็นการเรียกบริการบนเว็บที่ใช้เวลานาน

การเรียกฐานข้อมูลของฉันควรเป็นแบบอะซิงโครนัสหรือไม่

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

คุณควรดูข้อมูลอ้างอิงที่1และ2

มาจากความเห็น @PanagiotisKanavos:

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

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

คุณอาจพบฉันบทความ MSDN ในเรื่องที่เป็นประโยชน์ ; ฉันใช้พื้นที่จำนวนมากในบทความที่อธิบายเมื่อคุณควรใช้asyncบน ASP.NET ไม่ใช่แค่วิธีใช้asyncบน ASP.NET

ฉันมีข้อกังวลบางอย่างเกี่ยวกับการใช้การกระทำของ async ใน ASP.NET MVC เมื่อมันปรับปรุงประสิทธิภาพของแอพของฉันและเมื่อ - ไม่

ครั้งแรกเข้าใจว่าasync/ awaitคือทั้งหมดที่เกี่ยวกับการพ้นขึ้นหัวข้อ ในแอปพลิเคชัน GUI ส่วนใหญ่เกี่ยวกับการเพิ่มเธรด GUIเพื่อให้ประสบการณ์การใช้งานของผู้ใช้ดีขึ้น บนแอปพลิเคชันเซิร์ฟเวอร์ (รวมถึง ASP.NET MVC) ส่วนใหญ่เกี่ยวกับการเพิ่มเธรดการร้องขอเพื่อให้เซิร์ฟเวอร์สามารถปรับขนาดได้

โดยเฉพาะอย่างยิ่งมันจะไม่:

• ทำให้คำขอของคุณเสร็จสมบูรณ์เร็วขึ้น ในความเป็นจริงพวกเขาจะเสร็จสมบูรณ์ (ช้าลงเล็กน้อย)
• กลับไปที่โทร / awaitเบราว์เซอร์เมื่อคุณตี awaitเฉพาะ "อัตราผลตอบแทน" ไปยังพูลเธรด ASP.NET ไม่ใช่เบราว์เซอร์

คำถามแรกคือ - ใช้แอคชั่น async ใน ASP.NET MVC ดีหรือไม่?

ฉันว่ามันดีที่จะใช้ทุกที่ที่คุณทำ I / O มันอาจไม่เป็นประโยชน์แต่ (ดูด้านล่าง)

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

ฉันจะใช้คำหลักแบบ async / รอคำสั่งเมื่อฉันต้องการสืบค้นฐานข้อมูล (ผ่าน EF / NHibernate / ORM อื่น ๆ ) หรือไม่

คุณสามารถใช้วิธีการใด ๆ ที่คุณมีอยู่ ตอนนี้ผู้เล่นหลักส่วนใหญ่สนับสนุนasyncแต่ก็มีบางอย่างที่ไม่ หากออมของคุณไม่สนับสนุนasyncอย่าพยายามห่อในTask.Runหรืออะไรทำนองนั้น (ดูด้านบน)

โปรดทราบว่าฉันพูดว่า "คุณสามารถใช้" หากคุณกำลังพูดคุยเกี่ยวกับ ASP.NET MVC กับแบ็กเอนด์ฐานข้อมูลเดียวแล้วคุณ (เกือบจะแน่นอน) จะไม่ได้รับผลประโยชน์ใด ๆ asyncจากการขยายขีดความสามารถ นี่เป็นเพราะ IIS สามารถจัดการการร้องขอพร้อมกันได้มากกว่าอินสแตนซ์เดียวของเซิร์ฟเวอร์ SQL (หรือ RDBMS แบบดั้งเดิมอื่น ๆ ) แต่ถ้าแบ็กเอนด์ของคุณมีความทันสมัยมากขึ้น - เซิร์ฟเวอร์คลัสเตอร์ของ SQL Azure SQL, NoSQL ฯลฯ - และแบ็กเอนด์ของคุณสามารถปรับขนาดและความยืดหยุ่นคอขวดของคุณเป็นของ IIS แล้วasyncคุณจะได้รับประโยชน์จากความยืดหยุ่น

คำถามที่สาม - ฉันสามารถใช้คำหลักที่รอคอยเพื่อค้นหาฐานข้อมูลแบบอะซิงโครนัสในวิธีการเดียวได้กี่ครั้ง

มากเท่าที่คุณต้องการ อย่างไรก็ตามโปรดทราบว่าหลาย ORMs มีกฎหนึ่งการดำเนินการต่อการเชื่อมต่อ โดยเฉพาะอย่างยิ่ง EF อนุญาตให้ดำเนินการเพียงครั้งเดียวต่อ DbContext; สิ่งนี้เป็นจริงไม่ว่าจะเป็นการดำเนินการแบบซิงโครนัสหรือแบบอะซิงโครนัส

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

มันเป็นการดีที่จะใช้การกระทำ async ทุกที่ใน ASP.NET MVC?

ตามปกติในการเขียนโปรแกรมก็ขึ้นอยู่กับ ยังคงมีการแลกเปลี่ยนเมื่อลงเส้นทางที่แน่นอน

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

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

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

ฉันจะใช้คำหลักแบบ async / รอคำสั่งเมื่อฉันต้องการสืบค้นฐานข้อมูล (ผ่าน EF / NHibernate / ORM อื่น ๆ ) หรือไม่

หากคุณเลือกที่จะลงเส้นทางของการใช้การโทรแบบ async IO ก็async-awaitจะเป็นตัวเลือกที่ดีเนื่องจากผู้ให้บริการฐานข้อมูลที่ทันสมัยขึ้นเรื่อย ๆ เปิดเผยวิธีการแบบอะซิงโครนัสที่ใช้ TAP (รูปแบบงานแบบอะซิงโครนัส)

ฉันสามารถใช้คำหลักที่รอคอยเพื่อค้นหาฐานข้อมูลแบบอะซิงโครนัสในวิธีการเดียวได้กี่ครั้ง

มากเท่าที่คุณต้องการตราบใดที่คุณปฏิบัติตามกฎที่ระบุโดยผู้ให้บริการฐานข้อมูลของคุณ ไม่ จำกัด จำนวนการโทรแบบ async ที่คุณสามารถทำได้ หากคุณมีคำถามที่ไม่เกี่ยวข้องกันและสามารถทำพร้อมกันคุณสามารถหมุนงานใหม่สำหรับแต่ละรายการและใช้await Task.WhenAllเพื่อรอให้ทั้งสองดำเนินการให้เสร็จสมบูรณ์

5 เซนต์ของฉัน:

1. ใช้async/awaitถ้าหากคุณทำการดำเนินการ IO เช่น DB หรือบริการเว็บเซอร์วิสภายนอก
2. ต้องการเรียก async ไปยัง DB เสมอ
3. ทุกครั้งที่คุณค้นหา DB

ป.ล. มีกรณีพิเศษสำหรับจุดที่ 1 แต่คุณจำเป็นต้องมีความเข้าใจที่ดีเกี่ยวกับการทำ async internals สำหรับสิ่งนี้

ในฐานะที่เป็นข้อได้เปรียบเพิ่มเติมคุณสามารถโทร IO สองสามขนานในกรณีที่จำเป็น:

Task task1 = FooAsync(); // launch it, but don't wait for result
Task task2 = BarAsync(); // launch bar; now both foo and bar are running
await Task.WhenAll(task1, task2); // this is better in regard to exception handling
// use task1.Result, task2.Result

asyncการกระทำช่วยได้ดีที่สุดเมื่อการดำเนินการบางอย่างเป็นการดำเนินการของ I \ O ไปยัง DB หรือการโทรที่ถูกผูกไว้กับเครือข่ายโดยที่เธรดที่ประมวลผลการร้องขอจะถูกหยุดก่อนที่จะได้รับคำตอบจาก DB หรือการโทรที่ถูก จำกัด เครือข่าย เป็นวิธีที่ดีที่สุดที่คุณใช้รอกับพวกเขาและมันจะปรับปรุงการตอบสนองของแอปพลิเคชันของคุณได้จริง ๆ (เนื่องจากเธรด ASP input \ output น้อยลงจะถูกหยุดขณะรอ DB หรือการดำเนินการอื่น ๆ เช่นนั้น) ในทุกแอปพลิเคชันของฉันเมื่อใดก็ตามที่มีการโทรไปยังฐานข้อมูลที่จำเป็นมากฉันมักจะห่อไว้ด้วยวิธีการที่รวดเร็วและเรียกว่าด้วยawaitคำสำคัญ

อย่างที่คุณทราบ MVC สนับสนุนคอนโทรลเลอร์แบบอะซิงโครนัสและคุณควรใช้ประโยชน์จากมัน ในกรณีที่คอนโทรลเลอร์ของคุณทำการดำเนินการที่มีความยาว (อาจเป็นดิสก์ที่ใช้ I / o หรือการโทรผ่านเครือข่ายไปยังบริการระยะไกลอื่น) หากการร้องขอนั้นได้รับการจัดการแบบซิงโครนัสเธรด IIS จะยุ่งตลอดเวลา เป็นผลให้เธรดกำลังรอการดำเนินการที่มีความยาวให้เสร็จสมบูรณ์ สามารถใช้ประโยชน์ได้ดีขึ้นโดยให้บริการคำขออื่น ๆ ในขณะที่การดำเนินการที่ร้องขอในครั้งแรกอยู่ระหว่างดำเนินการ สิ่งนี้จะช่วยในการให้บริการคำขอที่เกิดขึ้นพร้อมกันมากขึ้น เว็บเซอร์ของคุณจะสามารถปรับได้สูงและจะไม่ทำงานได้อย่างง่ายดายในปัญหา C10k เป็นความคิดที่ดีที่จะใช้ async / await สำหรับการสืบค้น db และใช่คุณสามารถใช้หลาย ๆ ครั้งตามที่คุณเห็นสมควร

ลองดูคำแนะนำที่ดีเยี่ยมที่นี่

ประสบการณ์ของฉันคือวันนี้ผู้พัฒนาจำนวนมากใช้async/awaitเป็นค่าเริ่มต้นสำหรับตัวควบคุม

คำแนะนำของฉันจะเป็นใช้เฉพาะเมื่อคุณรู้ว่ามันจะช่วยให้คุณ

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

• ตัวควบคุมปริมาณสูง
• แบ็กเอนด์ที่ปรับขนาดได้

มันเป็นการดีที่จะใช้ async การกระทำทุกที่ใน ASP.NET MVC?

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

เกี่ยวกับวิธีการที่รอคอย: ฉันจะใช้ async / คอยคำสำคัญเมื่อฉันต้องการสอบถามฐานข้อมูล (ผ่าน EF / NHibernate / ORM อื่น ๆ )

ใช่เป็นการดีกว่าที่จะใช้ async สำหรับการดำเนินการฐานข้อมูลใด ๆ เท่าที่จะทำได้เพื่อหลีกเลี่ยงปัญหาด้านประสิทธิภาพในระดับกระบวนการของผู้ปฏิบัติงาน โปรดทราบว่า EF ได้สร้างทางเลือก async จำนวนมากสำหรับการทำงานส่วนใหญ่เช่น:

.ToListAsync()
.FirstOrDefaultAsync()
.SaveChangesAsync()
.FindAsync()

ฉันสามารถใช้คำหลักที่รอคอยเพื่อสืบค้นฐานข้อมูลแบบอะซิงโครนัสในวิธีการเดียวได้กี่ครั้ง

ท้องฟ้าเป็นข้อ จำกัด