Tại sao IIS mặc định để Tái chế Nhóm ứng dụng cứ sau 1740 phút?

Tại sao IIS mặc định để tái chế nhóm ứng dụng sau một thời gian nhất định? Có một số lý do cụ thể khác ngoài có lẽ hầu hết các ứng dụng web không quản lý bộ nhớ một cách thận trọng? Cho rằng bạn đang quản lý bộ nhớ ứng dụng của mình đúng cách, liệu có an toàn để tiếp tục và tắt cái này không? Một số mặt trái tiềm năng, tăng lợi ích để tắt tái chế hoặc giữ nó là gì?

Có, lý do nó mặc định mỗi ngày một lần là do lo lắng rằng ứng dụng web có thể bị rò rỉ bộ nhớ. Nhược điểm lớn nhất của việc thường xuyên tái chế các nhóm ứng dụng IIS là nó sẽ gây ra việc đọc web.config, tải lắp ráp và biên dịch lại các trang asp.net và (nếu bạn không tin vào việc biên dịch trước chúng) mã phía sau. Đây là một quá trình khá nặng nề và nó không xảy ra cho đến khi yêu cầu tiếp theo cho một trang sau khi nhóm ứng dụng được tái chế, làm chậm rất nhiều yêu cầu cụ thể đó. IIS7 hiện có một mô-đun mà bạn có thể tải xuống có tên là Ứng dụng khởi động để giúp "giải quyết" vấn đề này.

Cá nhân tôi thích sử dụng mức tối đa dựa trên bộ nhớ cùng với việc đăng nhập vào ứng dụng bắt đầu hơn là lên lịch tái chế. Điều này cho phép tôi giả sử ứng dụng của mình không bị rò rỉ bộ nhớ và được chứng minh là sai khi nhóm ứng dụng tái chế.

1740 phút là 29 giờ:

Quay lại khi IIS 6 đang được phát triển, đây là phiên bản giới thiệu nhóm ứng dụng, một mặc định cần thiết được đặt cho Khoảng thời gian thông thường khi các nhóm ứng dụng được tự động tái chế.

Wade đề nghị 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 mà không xảy ra thường xuyên hơn một lần mỗi ngày. Theo cách nói của Wade: Bạn không nhận được mô hình cộng hưởng. Mặc định là 1740 phút (29 giờ) kể từ đó!

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

Tính năng là một sự tiếp quản từ những ngày cổ điển của ASP khi mọi thứ bị rò rỉ bộ nhớ và bạn phải làm điều đó. Hầu hết mọi người đã có một khởi động lại theo lịch trình trên máy chủ web qua đêm. IIS6 tự động hóa điều này với việc tắt nhóm ứng dụng cứ sau 1740 phút (hoặc nếu ứng dụng không hoạt động trong 20 phút). IIS7 tiếp tục truyền thống.

Lời khuyên tôi nhận được từ microsoft trở lại trong những ngày đó là điều này là không cần thiết trừ khi bạn có một ứng dụng cũ với rò rỉ bộ nhớ đã biết. Vì vậy, nếu bạn đang chạy mã được quản lý hoàn toàn, bạn sẽ ổn.

Tắt nó và theo dõi các nhóm ứng dụng. Hầu hết các ứng dụng doanh nghiệp phức tạp sử dụng rất nhiều mã kế thừa và phần lớn mã đó bị rò rỉ. Vì vậy, đối với hầu hết các cài đặt thỉnh thoảng khởi động lại nhóm ứng dụng không phải là ý tưởng tồi.

Có những lựa chọn khác như theo dõi thời gian không hoạt động có thể là một giải pháp tốt hơn cho tình huống của bạn.

Việc quay vòng một nhóm ứng dụng có thể mất một chút thời gian và làm cho ứng dụng ít phản hồi hơn vì vậy việc duy trì chúng có thể giúp thực hiện.

Thật vậy, điều này hoàn toàn là để làm sạch các tài nguyên bị rò rỉ mà (có thể) có mặt. 1740 phút cũng không phải là sự kiện kích hoạt duy nhất. Nó cũng xảy ra sau một số lượng yêu cầu tối đa cụ thể hoặc sau khi vượt quá một lượng bộ nhớ quy trình công nhân cụ thể. Nó là tài liệu khá tốt trong thư viện MSDN. Thật không may, chính sách này phá vỡ những thứ như trạng thái phiên và số liệu thống kê như singletons. Ứng dụng của bạn sẽ cần đủ mạnh để xác thực lại người dùng và / hoặc khởi tạo lại các singletons khi cần để tránh làm phiền trải nghiệm người dùng của bạn. Nó buộc chúng tôi phải quản lý các phiên xác thực trong cơ sở dữ liệu thay vì trong phiên ASP.NET. Mặt khác, người dùng của chúng tôi đã được khởi động trở lại trang đăng nhập của chúng tôi bất cứ khi nào máy chủ tái chế do một trong những kích hoạt này.