ตัวควบคุม Async ใน ASP.NET MVC: ข้อดีจริง / เป็นอย่างไร

ฉันทำงานผ่านบทความเกี่ยวกับวิธีการควบคุมแบบอะซิงโครนัสใน ASP.NET MVC ( http://visualstudiomagazine.com/articles/2013/07/23/async-actions-in-aspnet-mvc-4.aspx ) และฉันคิดว่า ฉันอาจจะพลาดจุดนี้

ลองใช้วิธีนี้ที่ฉันเขียนซึ่งคล้ายกับตัวอย่างจากบทความ:

[HttpGet]
[AsyncTimeout(8000)]
[HandleError(ExceptionType = typeof(TimeoutException), View = "TimedOut")]
public async Task<ActionResult> Index(CancellationToken cancellationToken)
{
    WidgetPageViewModel model = new WidgetPageViewModel()
    {
        toAdd = new Widget()
    };
    model.all = await _repo.GetAllAsync(cancellationToken);
    return View(model);
}

เมื่อฉันเข้าใจสิ่งต่าง ๆ นี่คือสิ่งที่จะเกิดขึ้นในรันไทม์:

1. เธรด ASP.NET จะถูกสร้างขึ้นสำหรับคำขอ HTTP ขาเข้า

2. หัวข้อนี้จะ (มีการทำงานเบื้องต้นที่จำเป็นบางอย่างสันนิษฐาน) เข้าสู่ดัชนีของฉัน () วิธีการด้านบน

3. การดำเนินการจะไปถึงคำสำคัญ "รอ" และเริ่มกระบวนการเก็บข้อมูลในเธรดอื่น

4. เธรด "ASP.NET" ดั้งเดิมจะส่งคืนรหัสที่เรียกว่าเมธอดตัวจัดการของฉันพร้อมกับอินสแตนซ์ของคลาส Task เป็นค่าส่งคืน

5. รหัสโครงสร้างพื้นฐานที่เรียกว่าวิธีการจัดการของฉันจะดำเนินการต่อในเธรด "ASP.NET" ดั้งเดิมจนกว่าจะถึงจุดที่จำเป็นต้องใช้วัตถุ ActionResult จริง (เช่นเพื่อแสดงหน้า)

6. ผู้เรียกจะเข้าถึงวัตถุนี้โดยใช้สมาชิก Task.Result ซึ่งจะทำให้เกิด (เช่นเธรด "ASP.NET") เพื่อรอเธรดที่สร้างขึ้นโดยนัยในขั้นตอน # 3 ด้านบน

ฉันไม่เห็นสิ่งที่สิ่งนี้สำเร็จเมื่อเทียบกับสิ่งเดียวกันโดยไม่รอ / async ยกเว้นสองสิ่งที่ฉันเห็นว่าเป็นขี้ประติ๋ว:

• เธรดผู้โทรและเธรดผู้ทำงานที่สร้างขึ้นโดยการรอคอยสามารถทำงานพร้อมกันเป็นระยะเวลาหนึ่ง (ส่วน "จนถึง" ของ # 5 ด้านบน) ลางสังหรณ์ของฉันคือช่วงเวลานั้นค่อนข้างเล็ก เมื่อโครงสร้างพื้นฐานเรียกใช้เมธอดคอนโทรลเลอร์ฉันคิดว่าโดยทั่วไปแล้วมันต้องการ ActionResult ที่แท้จริงของการเรียกคอนโทรลเลอร์ก่อนที่มันจะทำอะไรได้มากกว่านี้ (ถ้ามี)

• มีโครงสร้างพื้นฐานใหม่ที่เป็นประโยชน์บางอย่างที่เกี่ยวข้องกับการหมดเวลาและการยกเลิกการดำเนินงานคอนโทรลเลอร์แบบอะซิงโครนัสที่ใช้เวลานาน

วัตถุประสงค์ของการเพิ่มวิธีการควบคุม async คาดว่าจะทำให้เธรด ASP.NET ผู้ปฏิบัติงานนั้นว่างเพื่อตอบคำขอ HTTP จริง ๆ เธรดเหล่านี้เป็นทรัพยากรที่มี จำกัด น่าเสียดายที่ฉันไม่เห็นว่ารูปแบบที่แนะนำในบทความนั้นทำหน้าที่ช่วยอนุรักษ์กระทู้เหล่านี้อย่างไร และแม้ว่ามันจะเป็นเช่นนั้นและก็ช่วยลดภาระในการจัดการการร้องขอไปยังเธรดที่ไม่ใช่ ASP.NET บางส่วนสิ่งใดที่ทำให้สำเร็จ เธรดที่มีความสามารถในการจัดการการร้องขอ HTTP ที่แตกต่างจากเธรดโดยทั่วไปหรือไม่

ASP.Net ที่ไม่ได้ใช้ Task Parallel Library (TPL) ถูก จำกัด ในจำนวนคำขอที่สามารถจัดการพร้อมกันโดยจำนวนเธรดในเธรดพูล ASP.Net ที่ใช้ TPL นั้นถูก จำกัด โดย CPU / หน่วยความจำ / IO ของการร้องขอการจัดการเครื่อง

Task Parallel Library (TPL) ไม่ใช้เธรดในแบบที่คุณคิด งานไม่ใช่เธรด แต่เป็นตัวหุ้มรอบการคำนวณบางหน่วย ตัวกำหนดตารางเวลางานมีหน้าที่รับผิดชอบในการดำเนินงานแต่ละงานบนเธรดใด ๆ ที่ไม่ว่าง ที่รันไทม์การรองานไม่ได้บล็อกเธรดเพียงหยุดสถานะการดำเนินการเพื่อให้สามารถดำเนินการได้ในภายหลัง

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