Nhóm ứng dụng IIS 7.x Thực tiễn tốt nhất

Chúng tôi sắp triển khai một loạt các trang web đến một số máy chủ mới. Tôi có các câu hỏi sau đây về nhóm ứng dụng:

1. Có vẻ như nên có một nhóm ứng dụng cho mỗi trang web. Có bất kỳ cảnh báo cho phương pháp này? Một nhóm ứng dụng sẽ hog tất cả CPU, Bộ nhớ, Vv ...?

2. Khi nào bạn nên cho phép nhiều tiến trình worker trong một nhóm ứng dụng? Khi nào bạn không nên?

3. Có thể sử dụng giới hạn bộ nhớ riêng để ngăn một nhóm ứng dụng can thiệp vào một nhóm khác không? Việc đặt nó quá thấp sẽ khiến các yêu cầu hợp lệ tái chế nhóm ứng dụng mà không nhận được phản hồi hợp lệ?

4. Sự khác biệt giữa giới hạn bộ nhớ riêng và ảo là gì?

5. Có lý do thuyết phục KHÔNG chạy một nhóm ứng dụng trên mỗi trang không?

1) Có vẻ nên có một nhóm ứng dụng cho mỗi trang web. Có bất kỳ cảnh báo cho phương pháp này? Chẳng hạn, một nhóm ứng dụng có thể hog tất cả CPU, Bộ nhớ, Vv ... không?

Đây là một cách tiếp cận khá tốt; không có bất kỳ lý do chính đáng nào mà tôi có thể nghĩ đến để có các "trang web" (ứng dụng) khác nhau chia sẻ cùng một nhóm. Trừ khi họ cần chia sẻ một nguồn tài nguyên nào đó. Về mặt lý thuyết, một ứng dụng có thể chứa rất nhiều CPU hoặc bộ nhớ, nhưng việc thay đổi cách các ứng dụng được gộp lại sẽ không thực sự ảnh hưởng đến điều này.

2) Khi nào bạn nên cho phép nhiều quy trình công nhân trong một nhóm ứng dụng. Khi nào bạn không nên?

Điều này là tốt nhất để lại một mình, sử dụng các thiết lập mặc định. Trừ khi bạn thực sự biết những gì bạn đang làm điều này thực sự có thể tác động tiêu cực đến trang web / ứng dụng của bạn.

3) Có thể sử dụng giới hạn bộ nhớ riêng để ngăn một nhóm ứng dụng can thiệp vào một ứng dụng khác không? Việc đặt nó quá thấp sẽ khiến các yêu cầu hợp lệ tái chế nhóm ứng dụng mà không nhận được phản hồi hợp lệ?

a) Về mặt lý thuyết

b) Có, đặt nó xuống thấp hơn có thể có tác động tiêu cực. Một lần nữa, trừ khi bạn có nhu cầu cụ thể, và biết những gì bạn đang làm, hãy để những thứ này một mình.

4) Sự khác biệt giữa giới hạn bộ nhớ riêng và ảo là gì?

Điều đó rất phức tạp, đây là một bài đăng nhanh mà tôi thấy có thể giúp ích: http://cybernetnews.com/cybernotes-windows-memory-usage-explained/

5) Có lý do thuyết phục KHÔNG chạy một nhóm ứng dụng trên mỗi trang không?

Một lần nữa, lý do duy nhất tôi có thể nghĩ đến là nếu có một loại "tài nguyên chia sẻ" nào đó mà nhiều ứng dụng cần, thì bạn sẽ muốn chạy chúng trong cùng một quy trình.

Đối với các ứng dụng và trang web cho mục đích chung, IIS được thiết lập khá tốt với các giá trị mặc định của nó.

**** CẬP NHẬT ****

Liên quan đến yêu cầu của bạn về thông tin bổ sung về # 2, bạn không nên làm điều này trừ khi bạn có nhu cầu cụ thể để làm điều đó. Ngay cả với các hành động máy chủ mất nhiều thời gian, các yêu cầu vẫn được cung cấp bằng cách sử dụng nhiều luồng và bạn sẽ muốn sử dụng "Yêu cầu Async" để xử lý các tác vụ chạy dài (giải phóng một chuỗi nhóm luồng để xử lý các yêu cầu khác). Thực tế, tôi không thể nghĩ ra bất kỳ lý do chính đáng nào để cho phép nhiều quy trình cho một nhóm.

Khi bạn bắt đầu nói nhiều quy trình, thì bạn có khả năng gặp phải những vấn đề như: mất trạng thái phiên vì phiên còn tồn tại trong quy trình 1, nhưng yêu cầu đang được xử lý bởi quy trình 2. Hoặc thậm chí tệ hơn, bạn phải tìm ra cách để làm một số giao tiếp giữa các quá trình, đó là một nỗi đau thực sự.

Bất kể bạn đi kèm với lý do gì cho nhiều quy trình, tôi sẽ sẵn sàng đặt cược rằng có một cách tốt hơn để giải quyết nó (thay vì khởi động một quy trình khác).

Tôi luôn cấu hình một nhóm ứng dụng dành riêng cho một trang web. Kịch bản lưu trữ trang web chi phí thấp là nơi có số lượng lớn các trang web trên mỗi nhóm ứng dụng có ý nghĩa.

Các giới hạn bộ nhớ thực sự chỉ là ngưỡng an toàn nguyên thủy để ngăn chặn một trang web tiêu thụ tất cả tài nguyên hệ thống. Lưu ý rằng đây là vấn đề tiềm ẩn trên Windows 2008 R2 x64 so với IIS 6.0 x86, vì các ứng dụng x86 có trần bộ nhớ 2 GB tự nhiên. IIS 7.5 dễ dàng hơn nhiều đối với một ứng dụng bị rò rỉ bộ nhớ để tiêu thụ một lượng lớn bộ nhớ.

Tôi cũng không phải là một fan hâm mộ lớn của các nhóm ứng dụng tái chế. Nếu tôi có nhóm ứng dụng và tôi là ứng dụng duy nhất đang chạy, nếu không có gì sai với mã của chúng tôi, có lẽ không cần phải tái chế nhóm ứng dụng. Và nếu có lỗi trong ứng dụng, hành động thích hợp cuối cùng sẽ là sửa mã.