เหตุใด IIS จึงใช้ค่าเริ่มต้นในการรีไซเคิลกลุ่มแอพลิเคชันทุก ๆ 1740 นาที

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

ใช่เหตุผลที่ค่าเริ่มต้นวันละครั้งหมดกังวลว่าเว็บแอพอาจมีหน่วยความจำรั่ว ข้อเสียที่ใหญ่ที่สุดในการรีไซเคิลแอพ IIS บ่อยครั้งคือมันจะทำให้การอ่าน web.config การโหลดแอสเซมบลีและการคอมไพล์เพจ asp.net อีกครั้งและ (หากคุณไม่เชื่อในการรวบรวมล่วงหน้า) โค้ดที่อยู่ด้านหลัง นี่เป็นกระบวนการที่ค่อนข้างหนักและจะไม่เกิดขึ้นจนกว่าคำขอถัดไปสำหรับหน้าเว็บหลังจากที่กลุ่มแอพรีไซเคิลแล้วทำให้การร้องขอนั้นช้าลงอย่างมาก ตอนนี้ IIS7 มีโมดูลที่คุณสามารถดาวน์โหลดชื่อว่าApplication Warm Upเพื่อช่วย "จัดการ" กับปัญหานี้

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

1740 นาทีคือ 29 ชั่วโมง:

ย้อนกลับไปเมื่อมีการพัฒนา IIS 6 ซึ่งเป็นเวอร์ชันที่นำเสนอกลุ่มแอปพลิเคชัน - ค่าเริ่มต้นที่จำเป็นสำหรับการกำหนดช่วงเวลาปกติเมื่อกลุ่มแอปพลิเคชันถูกนำกลับมาใช้ใหม่โดยอัตโนมัติ

เวดแนะนำให้29 ชั่วโมงด้วยเหตุผลง่ายๆว่ามันเป็นหมายเลขที่เล็กที่สุดใน 24ชั่วโมง เขาต้องการรูปแบบที่เซและไม่ซ้ำซึ่งไม่เกิดขึ้นบ่อยกว่าวันละครั้ง ในคำพูดของ Wade:“ คุณไม่ได้รับรูปแบบเสียงสะท้อน” ค่าเริ่มต้นคือ 1740 นาที (29 ชั่วโมง) นับตั้งแต่!

http://weblogs.asp.net/owscott/archive/2013/04/06/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes.aspx

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

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

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

มีตัวเลือกอื่น ๆ เช่นการตรวจสอบเวลาที่ไม่มีกิจกรรมซึ่งอาจเป็นทางออกที่ดีกว่าสำหรับสถานการณ์ของคุณ

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

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