การใช้ ThreadPool.QueueUserWorkItem ใน ASP.NET ในสถานการณ์ที่มีปริมาณการใช้งานสูง

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

นี่คือวิธีที่ฉันทำงานแบบอะซิงโครนัสขนาดเล็กจนถึงตอนนี้:

ThreadPool.QueueUserWorkItem(s => PostLog(logEvent))

และบทความนี้แนะนำให้สร้างเธรดอย่างชัดเจนแทนโดยคล้ายกับ:

new Thread(() => PostLog(logEvent)){ IsBackground = true }.Start()

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

คำถามของฉันคือคำแนะนำในบทความถูกต้องหรือไม่?

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

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

คำตอบอื่น ๆ ที่นี่ดูเหมือนจะไม่ตรงประเด็นที่สำคัญที่สุด:

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

ซึ่งใช้ได้กับทั้งเธรดฟรีที่สร้างโดยnew Thread(...)และเธรดผู้ปฏิบัติงานในเธรดThreadPoolที่ตอบสนองต่อQueueUserWorkItemคำร้องขอ

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

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

เวลาส่วนใหญ่ที่ฉันเห็นหรือได้ยินเกี่ยวกับโค้ดมัลติเธรดที่ถูกใช้อย่างไม่เหมาะสมใน ASP.NET ไม่ใช่สำหรับการจัดคิวงานที่ต้องใช้ CPU มาก สำหรับการจัดคิวงานที่ผูกกับ I / O และถ้าคุณต้องการทำงาน I / O คุณควรใช้เธรด I / O (I / O Completion Port)

โดยเฉพาะอย่างยิ่งคุณควรใช้การเรียกกลับแบบ async ที่รองรับโดยคลาสไลบรารีที่คุณใช้อยู่ วิธีการเหล่านี้จะมีป้ายกำกับชัดเจนเสมอ พวกเขาเริ่มต้นด้วยคำพูดและBegin Endในขณะที่Stream.BeginRead, Socket.BeginConnect, WebRequest.BeginGetResponseและอื่น ๆ

วิธีการเหล่านี้ทำใช้ThreadPoolแต่พวกเขาใช้ IOCPs ซึ่งจะไม่ยุ่งเกี่ยวกับการร้องขอ ASP.NET เป็นด้ายน้ำหนักเบาชนิดพิเศษที่สามารถ "ตื่น" ได้ด้วยสัญญาณขัดจังหวะจากระบบ I / O และในแอปพลิเคชัน ASP.NET โดยปกติคุณจะมีเธรด I / O หนึ่งเธรดสำหรับเธรดของผู้ปฏิบัติงานแต่ละรายการดังนั้นทุกคำขอเดียวจึงสามารถจัดคิวการดำเนินการ async ได้หนึ่งรายการ นั่นคือการดำเนินการ async หลายร้อยครั้งโดยไม่มีการลดประสิทธิภาพลงอย่างมีนัยสำคัญ (สมมติว่าระบบย่อย I / O สามารถรักษาได้) เป็นมากกว่าที่คุณต้องการ

เพียงแค่เก็บไว้ในใจว่า async ผู้ได้รับมอบหมายไม่ได้ทำงานด้วยวิธีนี้ - ThreadPool.QueueUserWorkItemพวกเขาจะสิ้นสุดการใช้ด้ายคนเช่นเดียวกับ เป็นเพียงวิธีการ async ในตัวของคลาสไลบรารี. NET Framework ที่สามารถทำสิ่งนี้ได้ คุณสามารถทำได้ด้วยตัวเอง แต่มันซับซ้อนและค่อนข้างอันตรายและอาจเกินขอบเขตของการสนทนานี้

คำตอบที่ดีที่สุดสำหรับคำถามนี้ในความคิดของฉันคืออย่าใช้อินสแตนซ์ThreadPool หรือพื้นหลังThreadใน ASP.NETASP.NET ไม่เหมือนกับการหมุนเธรดในแอปพลิเคชัน Windows Forms ที่คุณทำเพื่อให้ UI ตอบสนองและไม่สนใจว่าจะมีประสิทธิภาพเพียงใด ใน ASP.NET ความกังวลของคุณคือปริมาณงานและบริบททั้งหมดที่เปิดใช้งานเธรดของผู้ปฏิบัติงานทั้งหมดจะฆ่าปริมาณงานของคุณอย่างแน่นอนไม่ว่าคุณจะใช้ThreadPoolหรือไม่ก็ตาม

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

ตาม Thomas Marquadt จากทีม ASP.NET ที่ Microsoft การใช้ ASP.NET ThreadPool (QueueUserWorkItem) นั้นปลอดภัย

จากบทความ :

ถาม) หากแอปพลิเคชัน ASP.NET ของฉันใช้เธรด CLR ThreadPool ฉันจะไม่อด ASP.NET ซึ่งใช้ CLR ThreadPool เพื่อดำเนินการตามคำขอด้วยหรือไม่ ..

A) สรุปได้ว่าอย่ากังวลกับการอด ASP.NET ของเธรดและหากคุณคิดว่ามีปัญหาที่นี่โปรดแจ้งให้เราทราบและเราจะดูแลมัน

ถาม) ฉันควรสร้างเธรดของตัวเอง (เธรดใหม่) หรือไม่ สิ่งนี้จะไม่ดีกว่าสำหรับ ASP.NET เนื่องจากใช้ CLR ThreadPool

A) กรุณาอย่า หรือจะใส่แบบอื่นไม่ !!! ถ้าคุณฉลาดจริงๆ - ฉลาดกว่าฉันมากคุณก็สร้างชุดข้อความของคุณเองได้ ไม่อย่างนั้นอย่าแม้แต่จะคิดถึงมัน นี่คือสาเหตุบางประการที่คุณไม่ควรสร้างเธรดใหม่บ่อยๆ:

1. มีราคาแพงมากเมื่อเทียบกับ QueueUserWorkItem ... อย่างไรก็ตามถ้าคุณสามารถเขียน ThreadPool ได้ดีกว่า CLR ฉันขอแนะนำให้คุณสมัครงานที่ Microsoft เพราะเรากำลังมองหาคนแบบคุณอย่างแน่นอน!.

เว็บไซต์ไม่ควรไปรอบ ๆ หัวข้อการวางไข่

โดยทั่วไปคุณจะย้ายฟังก์ชันนี้ออกไปยังบริการ Windows ที่คุณติดต่อสื่อสารด้วย (ฉันใช้ MSMQ เพื่อพูดคุยกับพวกเขา)

- แก้ไข

ฉันอธิบายการใช้งานที่นี่: การประมวลผลพื้นหลังตามคิวใน ASP.NET MVC Web Application

- แก้ไข

หากต้องการขยายว่าเหตุใดจึงดีกว่าเธรดเพียงอย่างเดียว:

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

นอกจากนี้ยังช่วยให้คุณสามารถประมวลผลงานที่คุณพยายามทำ (ส่งอีเมล / อะไรก็ได้)

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

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

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

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

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

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

http://blogs.msdn.com/tmarq/archive/2010/04/14/performing-asynchronous-work-or-tasks-in-asp-net-applications.aspx

ขอบคุณโทมัส

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

การใช้ ThreadPool ใน ASP.NET จะไม่รบกวนเธรดของผู้ปฏิบัติงาน ASP.NET ใช้ ThreadPool ได้ดี

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

การใช้เธรดใหม่สำหรับทุกข้อความนั้นเกินความจำเป็นอย่างแน่นอน

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

ฉันจะบอกว่าบทความนี้ไม่ถูกต้อง หากคุณใช้งานร้านค้า. NET ขนาดใหญ่คุณสามารถใช้พูลได้อย่างปลอดภัยในหลาย ๆ แอพและหลาย ๆ เว็บไซต์ (โดยใช้แอพพูลแยกกัน) โดยใช้คำสั่งเดียวในเอกสารThreadPool :

มีเธรดพูลหนึ่งตัวต่อหนึ่งกระบวนการ เธรดพูลมีขนาดดีฟอลต์ 250 เธรดผู้ปฏิบัติงานต่อโปรเซสเซอร์ที่มีอยู่และเธรดการเสร็จสิ้น 1,000 I / O จำนวนเธรดในเธรดพูลสามารถเปลี่ยนแปลงได้โดยใช้เมธอด SetMaxThreads แต่ละเธรดใช้ขนาดสแต็กเริ่มต้นและทำงานตามลำดับความสำคัญเริ่มต้น

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

1. มีการร้องขอสำหรับบางเพจ
2. Html จะถูกส่งกลับ
3. Html บอกให้ไคลเอ็นต์สร้างคำขอเพิ่มเติม (js, css, รูปภาพ ฯลฯ .. )
4. ข้อมูลเพิ่มเติมจะถูกส่งกลับ

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

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

เธรดและกระบวนการ

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

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

ที่มา

ฉันไม่เห็นด้วยกับบทความอ้างอิง (C # feeds.com) สร้างเธรดใหม่ได้ง่าย แต่อันตราย จำนวนเธรดที่แอ็คทีฟที่เหมาะสมที่สุดในการรันบนคอร์เดียวนั้นต่ำมากอย่างน่าตกใจ - น้อยกว่า 10 เป็นวิธีที่ง่ายเกินไปที่จะทำให้เครื่องเสียเวลาในการสลับเธรดหากเธรดถูกสร้างขึ้นสำหรับงานเล็กน้อย เธรดเป็นทรัพยากรที่ต้องมีการจัดการ สิ่งที่เป็นนามธรรมของ WorkItem มีไว้เพื่อจัดการกับสิ่งนี้

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

ในที่สุดบทความก็มีข้อความที่ค่อนข้างกว้างเกี่ยวกับอันตรายของการใช้ ThreadPool แต่จริงๆแล้วมันต้องการบางอย่างที่เป็นรูปธรรมในการสำรองข้อมูล

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

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

คุณสามารถใช้ Parallel For หรือ Parallel ForEach และกำหนดขีด จำกัด ของเธรดที่เป็นไปได้ที่คุณต้องการจัดสรรเพื่อให้ทำงานได้อย่างราบรื่นและป้องกันการอดอาหารของพูล

อย่างไรก็ตามการทำงานในพื้นหลังคุณจะต้องใช้สไตล์ TPL ที่แท้จริงด้านล่างในแอปพลิเคชันเว็บ ASP.Net

var ts = new CancellationTokenSource();
CancellationToken ct = ts.Token;

ParallelOptions po = new ParallelOptions();
            po.CancellationToken = ts.Token;
            po.MaxDegreeOfParallelism = 6; //limit here

 Task.Factory.StartNew(()=>
                {                        
                  Parallel.ForEach(collectionList, po, (collectionItem) =>
                  {
                     //Code Here PostLog(logEvent);
                  }
                });