Câu trả lời:
Tại Tech Ed 2003, người trình bày đã được hỏi câu hỏi này và câu trả lời là họ muốn có một chu kỳ bất thường để ngăn nó xảy ra trên ranh giới hàng ngày (ví dụ: để phân biệt với các tác vụ hàng ngày khác được lên lịch trên máy chủ / miền).
Các trang web ở đây (Liên kết chết) suy đoán:
... (29 là) số nguyên tố đầu tiên sau 24, cho phép nó có ít cơ hội nhất xảy ra trong một mẫu thông thường với bất kỳ quy trình máy chủ nào khác; giảm bớt việc điều tra các vấn đề
Một trang web khác xuất hiện để xác nhận điều này:
( Wade Hilmo ) đã đề xuất 29 giờ vì lý do đơn giản đó là số nguyên tố nhỏ nhất trên 24. Anh ta muốn một mô hình so le và không lặp lại không xảy ra thường xuyên hơn một lần mỗi ngày
OK, điều này đã làm tôi khó chịu, vì vậy tôi đã tìm hiểu kỹ và cuối cùng đã tìm thấy bài đăng này từ một người rõ ràng thuộc nhóm IIS:
Lý do IIS6 tái chế cứ sau 29 giờ theo mặc định (và chúng tôi có lý do
Lý do IIS6 tái chế cứ sau 29 giờ theo mặc định (và chúng tôi có lý do chọn 29 giờ làm giá trị mặc định) là vì nhiều khả năng, ứng dụng web chạy trên nó không đáng tin cậy và thực sự cần phải khởi động lại thường xuyên.
Do đó, IIS6 được xây dựng dựa trên tiền đề (được thừa nhận là hoài nghi) rằng ứng dụng web của người dùng sẽ không chạy quá 24 giờ liền kề, các tính năng được lên kế hoạch phù hợp và mặc định được chọn. Quá trình công nhân tái chế cứ sau 29 giờ, quá trình khởi động và tắt máy được theo dõi, quy trình được ping liên tục để đảm bảo nó đang chạy, xử lý quá trình được theo dõi và báo hiệu khi nó kết thúc bất ngờ, v.v.
Nhận thấy rằng tái chế là một phần hoạt động bình thường, IIS6 cũng đảm bảo cách ly việc tái chế đó với người dùng cuối - kết nối TCP của người dùng cuối không bao giờ chấm dứt trong quá trình tái chế, do một số phép thuật ở chế độ nhân. Kết hợp với ứng dụng chế độ người dùng lưu trữ ngoài quy trình trạng thái phiên (như Dịch vụ trạng thái phiên ASP.Net), một ứng dụng hầu như được đảm bảo thời gian hoạt động đáng tin cậy mà không mất dữ liệu người dùng, ngay cả khi ứng dụng web gặp sự cố sau khi xử lý mỗi lần yêu cầu người dùng.
Điều này tốt như IIS6 có thể làm cho nó - được cung cấp một ứng dụng web không đáng tin cậy, làm cho nó có vẻ đáng tin cậy cho người dùng cuối và thực hiện nó mà không yêu cầu bất kỳ sửa lỗi nào của ứng dụng web không đáng tin cậy.
Tất nhiên, không phải tất cả các ứng dụng không đáng tin cậy đều có thể trở nên đáng tin cậy - nếu vậy, thì tất cả chúng ta đều mất việc! - nhưng IIS6 chắc chắn sẽ cố gắng nhiều hơn nữa để có khả năng phục hồi.
Trong trường hợp của bạn, điều đó chỉ xảy ra là việc resiliancy có tác dụng phụ đối với trạng thái người dùng không kiên trì, nhưng nó có thể dễ dàng điều chỉnh.
Giả sử ứng dụng web của bạn không bao giờ gặp sự cố và vẫn ở trạng thái phiên đang xử lý, bạn sẽ muốn thay đổi các mặc định này: 1. Tắt tái chế định kỳ 29 giờ 2. Tắt thời gian chờ 20 phút không sử dụng
Điều này sẽ ngăn chặn mất trạng thái phiên bất ngờ.
Tất nhiên, nếu bạn từng sử dụng một ứng dụng có trạng thái phiên ngoài quy trình, bạn có thể để mọi thứ là mặc định và không bao giờ nhận thấy sự khác biệt về chức năng cũng như độ tin cậy.