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

หมายเลขบทความ (Article ID): 821268 - ผลิตภัณฑ์ที่เกี่ยวข้องในบทความนี้
แปลโดยคอมพิวเตอร์คลิกที่นี่เพื่อดูข้อจำกัดความรับผิดชอบของ KB ที่แปลโดยคอมพิวเตอร์
ขยายทั้งหมด | ยุบทั้งหมด

เนื้อหาบนหน้านี้

อาการ

เมื่อคุณทำการเรียกใช้บริการเว็บจากโปรแกรมประยุกต์ที่ Microsoft ASP.NET คุณอาจพบช่วงชิงงานบน ประสิทธิภาพ และการชะงักงัน อาจรายงานไคลเอนต์ที่ ร้องขอหยุดการตอบสนอง (หรือ "แฮงค์") หรือใช้เวลานานมากสำหรับการดำเนินการ ถ้ามีการล็อกตายสงสัย ขั้นตอนอาจนำกลับมาใช้ คุณอาจได้รับข้อความต่อไปนี้ในบันทึกเหตุการณ์ของโปรแกรมประยุกต์
  • ถ้าคุณกำลังใช้ Internet Information Services (IIS) 5.0 คุณได้รับข้อความต่อไปนี้ในบันทึกของโปรแกรมประยุกต์:

       Event Type:     Error
   Event Source:   ASP.NET 1.0.3705.0
   Event Category: None
   Event ID:       1003
   Date:           5/4/2003
   Time:           6:18:23 PM
   User:           N/A
   Computer:       <ComputerName>
   Description:
      aspnet_wp.exe  (PID: <xxx>) was recycled because it was suspected to be in a deadlocked state.
      It did not send any responses for pending requests in the last 180 seconds.

  • ถ้าคุณกำลังใช้ IIS 6.0 คุณได้รับข้อความต่อไปนี้ในบันทึกของโปรแกรมประยุกต์:

       Event Type:     Warning
   Event Source:   W3SVC-WP
   Event Category: None
   Event ID:       2262
   Date:           5/4/2003
   Time:           1:02:33 PM
   User:           N/A
   Computer:       <ComputerName>
   Description:
      ISAPI 'C:\Windows\Microsoft.net\Framework\v.1.1.4322\aspnet_isapi.dll' reported itself as
      unhealthy for the following reason: 'Deadlock detected'.

  • ถ้าคุณกำลังใช้ IIS 6.0 คุณได้รับข้อความต่อไปนี้ในบันทึกของระบบ:

       Event Type:     Warning
   Event Source:   W3SVC
   Event Category: None
   Event ID:       1013
   Date:           5/4/2003
   Time:           1:03:47 PM
   User:           N/A
   Computer:       <ComputerName>
   Description:
      A process serving application pool 'DefaultAppPool' exceeded time limits during shut down.
      The process id was '<xxxx>'.

นอกจากนี้คุณอาจได้รับข้อผิดพลาดต่อไปนี้ของข้อยกเว้นข้อความเมื่อใด คุณทำการเรียกวิธีHttpWebRequest.GetResponse :
" System.InvalidOperationException: ยังไม่มีเธรดที่ว่างเพียงพอในวัตถุ ThreadPool เพื่อให้เสร็จสมบูรณ์แบบ การดำเนินการ"
นอกจากนี้คุณอาจได้รับข้อความแสดงข้อยกเว้นข้อผิดพลาดต่อไปนี้ ในเบราว์เซอร์:
" HttpException (0x80004005): การร้องขอหมดเวลา ออก
หมายเหตุ นอกจากนี้บทความนี้ใช้กับโปรแกรมประยุกต์ที่ทำการร้องขอการHttpWebRequestโดยตรง
กลับไปด้านบน | ให้ข้อเสนอแนะ

สาเหตุ

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

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

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

แหล่งที่มีศักยภาพอื่นของการช่วงชิงงานบนพารามิเตอร์maxconnectionที่System.Net namespace ใช้เพื่อจำกัดจำนวนการเชื่อมต่อ อยู่ โดยทั่วไป ขีดจำกัดนี้ทำงานตามที่คาดไว้ อย่างไรก็ตาม ถ้าโปรแกรมประยุกต์จำนวนมากพยายามที่จะทำให้มาก การร้องขอไปยังที่อยู่ IP เดียวในเวลาเดียวกัน เธรดอาจจะต้องรอจนกว่า เชื่อมต่อที่มีพร้อมใช้งาน
กลับไปด้านบน | ให้ข้อเสนอแนะ

การแก้ไข

เมื่อต้องการแก้ไขปัญหาเหล่านี้ คุณสามารถปรับแต่งพารามิเตอร์ต่อไปนี้ในแฟ้ม Machine.config ให้เหมาะสมกับสถานการณ์ของคุณ:
  • maxWorkerThreads
  • minWorkerThreads
  • maxIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads
  • maxconnection
  • executionTimeout
เมื่อต้องการให้แก้ไขปัญหาเหล่านี้เสร็จเรียบร้อยแล้ว ทำการดำเนินการต่อไปนี้:
  • จำกัดจำนวนของการร้องขอ ASP.NET ที่สามารถดำเนินการที่ ในครั้งเดียวกันเป็น 12 โดยประมาณสำหรับแต่ละ CPU
  • อนุญาตการเรียกกลับของบริการเว็บได้อย่างอิสระใช้เธรดในการ ThreadPool
  • เลือกค่าเหมาะสมสำหรับพารามิเตอร์maxconnections ยึดสิ่งที่คุณเลือกหมายเลขของที่อยู่ IP และ AppDomains ที่ใช้
หมายเหตุ คำแนะนำในการจำกัดจำนวนของการร้องขอ ASP.NET เป็น 12 สำหรับแต่ละ CPU มีเองเล็กน้อย อย่างไรก็ตาม ขีดจำกัดนี้มีการแก้ปัญหาการทำงานได้ดี โปรแกรมประยุกต์ส่วนใหญ่

maxWorkerThreadsและmaxIoThreads

ASP.NET ใช้การตั้งค่าการตั้งค่าคอนฟิกสองต่อไปนี้ เมื่อต้องการจำกัดจำนวนสูงสุดของเธรดของผู้ปฏิบัติงานและเธรดที่เสร็จสมบูรณ์ที่อยู่ ใช้: 
<processModel maxWorkerThreads="20" maxIoThreads="20">
พารามิเตอร์maxWorkerThreadsและmaxIoThreadsพารามิเตอร์จะถูกเพิ่มโดยอัตโนมัติคูณ ด้วยจำนวนของ Cpu สำหรับ ตัวอย่าง ถ้าคุณมีตัวประมวลผลสองตัว หมายเลขสูงสุดของเธรดของผู้ปฏิบัติงานคือ ต่อไปนี้:
2 * maxWorkerThreads

minFreeThreadsและminLocalRequestFreeThreads

ASP.NET ยังประกอบด้วยการกำหนดค่าต่อไปนี้ ตั้งค่าที่กำหนดจำนวนเธรดตัวทำงานและความสมบูรณ์พอร์ตเธรด ต้องมีการเริ่มต้นการร้องขอระยะไกลหรือการร้องขอภายในเครื่อง:
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
ถ้าไม่มีไม่เพียงพอสำหรับเธรด มีการจัดคิวการร้องขอ จนกว่าจะเพียงพอสำหรับเธรดที่ ว่างเพื่อทำให้การร้องขอ ดังนั้น ASP.NET จะ ไม่ถูกต้องมากกว่าหมายเลขต่อไปนี้ของการร้องขอในเวลาเดียวกัน:
(maxWorkerThreads*หมายเลขของ Cpu) -minFreeThreads
หมายเหตุ พารามิเตอร์minFreeThreadsและminLocalRequestFreeThreadsพารามิเตอร์จะไม่นัยคูณ ด้วยจำนวนของ Cpu

minWorkerThreads

เป็นของ ASP.NET การ 1.0 Service Pack 3 และ ASP.NET 1.1 ASP.NET ยังประกอบด้วยการตั้งค่าต่อไปนี้ตั้งค่าคอนฟิกที่กำหนดวิธี เธรดตัวทำงานหลายอาจมอบทันทีเพื่อให้บริการแบบรีโมท การร้องขอ 
<processModel minWorkerThreads="1">
เธรด ที่มีควบคุม โดยที่นี่คุณสามารถสร้างการตั้งค่าที่มากอัตราเร็วกว่า เธรดตัวทำงานที่สร้างขึ้นจากการปรับของ CLR ค่าเริ่มต้น "เธรดแต่ง" ความสามารถด้าน การตั้งค่านี้เปิดใช้งาน ASP.NET การร้องขอการบริการที่ไม่ถูกต้อง การกรอกข้อมูลในคิวการร้องขอ ASP.NET เนื่องจากเป็น slow-down บน back end อย่างฉับพลัน เซิร์ฟเวอร์ burst เกี่ยวกับสุขภาพของการร้องขอจากไคลเอ็นต์สิ้นสุด หรือที่คล้ายคลึง ที่จะทำให้เกิดการเพิ่มขึ้นเกี่ยวกับสุขภาพในหมายเลขของการร้องขอในคิว ที่ ค่าเริ่มต้นสำหรับพารามิเตอร์minWorkerThreadsคือ 1 เราขอแนะนำว่า คุณได้ตั้งค่าสำหรับพารามิเตอร์minWorkerThreadsเป็นค่าต่อไปนี้ 
minWorkerThreads = maxWorkerThreads / 2
โดยค่าเริ่มต้นminWorkerThreadsพารามิเตอร์ไม่อยู่ในแฟ้ม Web.config หรือ แฟ้ม Machine.config การตั้งค่านี้ถูกเพิ่มโดยอัตโนมัติคูณ ด้วยจำนวนของ Cpu

maxconnection

พารามิเตอร์maxconnectionเป็นตัวกำหนดจำนวนการเชื่อมต่อสามารถทำได้ ที่อยู่ IP เฉพาะ พารามิเตอร์ปรากฏเป็นดังนี้:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://65.53.32.230" maxconnection="12">
</connectionManagement>
ถ้ารหัสแอพลิเคชันของการอ้างอิงแอพลิเคชัน โดยใช้ชื่อโฮสต์แทนที่อยู่ IP พารามิเตอร์ควรปรากฏเป็นดังนี้:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname" maxconnection="12">
</connectionManagement>
ในตอนท้าย ถ้าแอพลิเคชันที่เป็นโฮสต์บนพอร์ตอื่นนอกเหนือจาก 80 พารามิเตอร์มีการรวมกับพอร์ตมาตรฐานใน URI คล้ายกับต่อไปนี้:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname:8080" maxconnection="12">
</connectionManagement>
การตั้งค่าสำหรับพารามิเตอร์ที่มีการกล่าวถึงก่อนหน้าในบทความนี้มีทั้งหมดในระดับกระบวนการ อย่างไรก็ตาม การตั้งค่าพารามิเตอร์maxconnectionใช้ไปยังระดับ AppDomain โดยค่าเริ่มต้น เนื่องจากการตั้งค่านี้ใช้เป็นระดับ AppDomain คุณสามารถสร้างได้สูงสุด เชื่อมต่อสองไปยังที่อยู่ IP เฉพาะจากแต่ละ AppDomain ในของคุณ ขั้นตอน

executionTimeout

ASP.NET ใช้การตั้งค่าการตั้งค่าคอนฟิกต่อไปนี้เมื่อต้องการ ขีดจำกัดเวลาการดำเนินการร้องขอ: 
<httpRuntime executionTimeout="90"/>
คุณยังสามารถกำหนดข้อจำกัดนี้ได้ โดยใช้คุณสมบัติServer.ScriptTimeout

หมายเหตุ ถ้าคุณเพิ่มค่าของพารามิเตอร์executionTimeoutคุณอาจต้องปรับเปลี่ยนการ processModel responseDeadlockIntervalตั้งค่าพารามิเตอร์

คำแนะนำ

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

ถ้า คุณทำหนึ่งเว็บบริการโทรไปยังที่อยู่ IP เดียวจากแต่ละหน้า ASPX Microsoft ขอแนะนำให้ คุณใช้การตั้งค่าคอนฟิกการตั้งค่าต่อไปนี้:
  • ตั้งค่าค่าของพารามิเตอร์maxWorkerThreadsและmaxIoThreadsพารามิเตอร์เป็น100
  • ตั้งค่าของพารามิเตอร์เป็นmaxconnection12 *N (ตำแหน่ง N คือหมายเลขของ Cpu ที่ คุณได้)
  • ตั้งค่าของพารามิเตอร์เป็นminFreeThreads88 *N และพารามิเตอร์เป็นminLocalRequestFreeThreads76 *N.
  • ตั้งค่า ค่าของminWorkerThreadsถึง50 อย่าลืมminWorkerThreadsไม่ได้อยู่ในแฟ้มการกำหนดค่าโดยค่าเริ่มต้น คุณต้องเพิ่มดังกล่าว
บางอย่าง ของคำแนะนำเหล่านี้เกี่ยวข้องกับสูตรง่าย ๆ ที่เกี่ยวข้องกับหมายเลข ของ Cpu บนเซิร์ฟเวอร์ ตัวแปรที่แสดงถึงหมายเลขของ Cpu ในตัว สูตรคือ N. สำหรับการตั้งค่าเหล่านี้ ถ้าคุณมีการเปิดใช้งาน การไฮเปอร์เธรดดิง คุณต้องใช้หมายเลขของ Cpu แบบลอจิคัลได้แทนที่เป็นหมายเลขของ Cpu ที่มีอยู่จริง ตัวอย่างเช่น ถ้าคุณมีเซิร์ฟเวอร์ตัวประมวลผลสี่กับไฮเปอร์เธรดดิงในการเปิดใช้งาน จากนั้น ค่าของ N ในสูตรจะเป็น8แทน4

หมายเหตุ เมื่อคุณใช้การตั้งค่าคอนฟิกนี้ คุณสามารถเรียกใช้ได้สูงสุด 12 ASP.NET ขอต่อ CPU ในเวลาเดียวกันได้เนื่องจาก100-88 = 12 ดังนั้น 88 น้อย *N ผู้ปฏิบัติงาน เธรดและ 88 *N มีเธรดพอร์ตเสร็จสมบูรณ์ พร้อมใช้งานสำหรับอื่น ๆ ใช้ (เช่นการเรียกกลับในบริการเว็บ)

ตัวอย่างเช่น คุณมีเซิร์ฟเวอร์ที่ มีตัวประมวลผลที่ 4 และไฮเปอร์เธรดดิง เปิดใช้งาน ขึ้นอยู่กับสูตรเหล่านี้ คุณจะต้องใช้ค่าต่อไปนี้สำหรับการ ตั้งค่าคอนฟิกที่กล่าวถึงในบทความนี้ 
<system.web>
	<processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50"/>
	<httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608"/>
</system.web>

<system.net>
	<connectionManagement>
		<add address="[ProvideIPHere]" maxconnection="96"/>
	</connectionManagement>
</system.net>

นอกจากนี้ เมื่อคุณใช้การตั้งค่าคอนฟิกนี้ 12 การเชื่อมต่อจะพร้อมใช้งาน สำหรับแต่ละ CPU สำหรับแต่ละที่อยู่ IP สำหรับแต่ละ AppDomain ดังนั้น ในต่อไปนี้ เกิดสถานการณ์สมมติ การช่วงชิงงานบนเพียงเล็กน้อยมากขึ้นเมื่อกำลังรอการร้องขอ การเชื่อมต่อ และ ThreadPool ไม่หมด:
  • เว็บโฮสต์แอพลิเคชันเดียวเท่านั้น (AppDomain)
  • แต่ละคำขอเพจที่มี ASPX ทำให้การร้องขอบริการเว็บหนึ่ง
  • คำขอทั้งหมดไปยังที่อยู่ IP เดียวกันได้
อย่างไรก็ตาม เมื่อคุณใช้การตั้งค่าคอนฟิกนี้ สถานการณ์ที่เกี่ยว อย่างใดอย่างหนึ่งต่อไปนี้อาจจะใช้การเชื่อมต่อมากเกินไป:
  • คำขอรับ ip แอดเดรสหลาย
  • การร้องขอถูกเปลี่ยนเส้นทาง (สถานะ 302 รหัส)
  • คำขอจำเป็นต้องมีการรับรองความถูกต้อง
  • มีการร้องขอจากหลาย AppDomains
ในสถานการณ์เหล่านี้ เป็นความคิดที่ดีที่จะใช้สำหรับค่าต่ำ พารามิเตอร์maxconnectionและค่าที่สูงกว่าสำหรับพารามิเตอร์minFreeThreadsและพารามิเตอร์minLocalRequestFreeThreads
กลับไปด้านบน | ให้ข้อเสนอแนะ

สถานะ

นี้ การทำงานที่เกิดจากการออกแบบ
กลับไปด้านบน | ให้ข้อเสนอแนะ

ข้อมูลเพิ่มเติม

ถ้าคุณพบกับประสิทธิภาพและการช่วงชิงงานบนบน IIS 7.0 ร่วมกับ ASP.NET ไป Microsoft บล็อกต่อไปนี้:
การใช้งานของเธรด ASP.NET ใน IIS 7.5, IIS 7.0 และ IIS 6.0
(http://blogs.msdn.com/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx)


แฮ ASP.net ใน IIS 7.0
(http://blogs.msdn.com/webtopics/archive/2009/02/13/asp-net-hang-in-iis-7-0.aspx)
กลับไปด้านบน | ให้ข้อเสนอแนะ

ข้อมูลอ้างอิง

สำหรับข้อมูลเพิ่มเติม ไปเว็บไซต์ Microsoft Developer Network (MSDN) ต่อไปนี้:
ปรับปรุงประสิทธิภาพของ ASP.NET
(http://msdn2.microsoft.com/en-us/library/ms998549.aspx)
กลับไปด้านบน | ให้ข้อเสนอแนะ

คุณสมบัติ

หมายเลขบทความ (Article ID): 821268 - รีวิวครั้งสุดท้าย: 6 กุมภาพันธ์ 2556 - Revision: 4.0
ใช้กับ
  • Microsoft .NET Framework 2.0
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
Keywords: 
kbprb kbmt KB821268 KbMtth
แปลโดยคอมพิวเตอร์
ข้อมูลสำคัญ: บทความนี้แปลโดยซอฟต์แวร์การแปลด้วยคอมพิวเตอร์ของ Microsoft แทนที่จะเป็นนักแปลที่เป็นบุคคล Microsoft มีบทความที่แปลโดยนักแปลและบทความที่แปลด้วยคอมพิวเตอร์ เพื่อให้คุณสามารถเข้าถึงบทความทั้งหมดในฐานความรู้ของเรา ในภาษาของคุณเอง อย่างไรก็ตาม บทความที่แปลด้วยคอมพิวเตอร์นั้นอาจมีข้อบกพร่อง โดยอาจมีข้อผิดพลาดในคำศัพท์ รูปแบบการใช้ภาษาและไวยากรณ์ เช่นเดียวกับกรณีที่ชาวต่างชาติพูดผิดเมื่อพูดภาษาของคุณ Microsoft ไม่มีส่วนรับผิดชอบต่อความคลาดเคลื่อน ความผิดพลาดหรือความเสียหายที่เกิดจากการแปลเนื้อหาผิดพลาด หรือการใช้บทแปลของลูกค้า และ Microsoft มีการปรับปรุงซอฟต์แวร์การแปลด้วยคอมพิวเตอร์อยู่เป็นประจำ
ต่อไปนี้เป็นฉบับภาษาอังกฤษของบทความนี้:821268
(http://support.microsoft.com/kb/821268/en-us/ )
กลับไปด้านบน | ให้ข้อเสนอแนะ

ให้ข้อเสนอแนะ

 
กลับไปด้านบนกลับไปด้านบน