Các hồ bơi ứng dụng riêng biệt cho các ứng dụng ASP.net trong IIS

Question

Tôi đã đọc các khuyến nghị rằng chúng ta nên tạo các hồ bơi ứng dụng riêng biệt cho từng ứng dụng asp.net trên máy chủ Win2008 của chúng tôi.

Chúng tôi có khoảng 20 ứng dụng sẽ nằm trên cùng một máy chủ. Tôi biết điều này sẽ tạo ra 20 quy trình công nhân riêng biệt mà dường như rất lãng phí.

Thực tiễn tốt là tạo các hồ bơi ứng dụng riêng biệt cho từng ứng dụng?

Answer 1

đăng lại từ ServerFault, "Why add additional application pools in IIS?"

• AppPools có thể chạy bản sắc như khác nhau, vì vậy bạn có thể giới hạn quyền theo cách này.
• Bạn có thể chỉ định một danh tính khác nhau cho mỗi nhóm ứng dụng để khi bạn chạy trình quản lý tác vụ, bạn biết w3wp.exe là cái nào.
• Bạn có thể tái chế/khởi động lại một nhóm ứng dụng mà không ảnh hưởng đến các trang web đang chạy trong các nhóm ứng dụng khác nhau.
• Nếu bạn có một trang web có rò rỉ bộ nhớ hoặc nói chung là hành vi sai trái, bạn có thể đặt nó trong một hồ bơi ứng dụng để nó không ảnh hưởng đến các trang web khác
• Nếu bạn có trang web chuyên sâu về CPU (Ví dụ như bạn có nhiều trang web có cơ sở dữ liệu SQL riêng, bạn có thể sử dụng xác thực thư mục hoạt động thay vì lưu trữ tên người dùng/mật khẩu. trong web.config.

Answer 2

Nếu ứng dụng của bạn ổn định và không sử dụng nhiều bộ nhớ, thì tôi sẽ nói rằng bạn nên đặt chúng trong cùng một hồ bơi ứng dụng. App Pools cung cấp cho bạn sự cách ly giữa các ứng dụng của bạn.

Answer 3

Một lý do chính tôi xem xét khi tạo hồ bơi ứng dụng là quản lý quy trình. Có những lý do khác như bảo mật, vv .. Khi một ứng dụng được lưu trữ trên máy chủ IIS, nó cũng làm mất quá trình lưu trữ của nó. Trong các phiên bản trước của IIS, điều này có nghĩa là tất cả các hoạt động web đều gặp sự cố. Với các nhóm ứng dụng, bạn có thể tách biệt các ứng dụng của mình với nhau. Nếu một người bị rò rỉ bộ nhớ và tiếp tục gặp sự cố, các ứng dụng khác của bạn sẽ tiếp tục hoạt động.

Answer 4

Lợi ích chính của việc tạo các nhóm ứng dụng khác nhau là bạn có thể cung cấp cho mỗi nhóm các thông tin đăng nhập khác. 20 ứng dụng của bạn có thể giao tiếp với 20 cơ sở dữ liệu khác nhau mà tất cả đều cần đăng nhập khác. Cách tốt nhất là chạy từng ứng dụng bằng một tài khoản dịch vụ khác.

Tôi sẽ không lo lắng quá nhiều về hiệu suất. Hầu hết thời gian có thể sẽ được chi tiêu bên trong mỗi ứng dụng web, bất kể quy trình của từng ứng dụng là gì.

Answer 5

Điều này thực sự phụ thuộc vào ứng dụng, mô hình bảo mật và mức độ tin cậy của ứng dụng.

Dưới đây là một số điều tôi luôn khuyên mọi người xem xét khi làm việc với các hồ bơi ứng dụng.

• Sử dụng các hồ bơi ứng dụng riêng biệt nếu mỗi ứng dụng cần quyền truy cập khác nhau vào tài nguyên hệ thống. (Có thể sử dụng nhiều tài khoản quy trình)
• Nếu ứng dụng là tài nguyên, nhiệm vụ quan trọng hoặc "không xác định", tốt nhất nên đặt nó vào hồ bơi riêng để tách biệt khỏi phần còn lại của hệ thống

Answer 6

có, đó là một ý tưởng hay ngay cả đối với 20 ứng dụng.

1. Bảo mật. Các hồ bơi ứng dụng khác nhau chạy trong các tài khoản khác nhau.
2. Cách ly. Một ứng dụng bị lỗi sẽ không gỡ xuống các ứng dụng khác.
3. Bộ nhớ (nếu bạn đang chạy 32 bit). Mỗi nhóm ứng dụng sẽ có không gian địa chỉ riêng. Vì vậy, bạn có thể giải quyết nhiều bộ nhớ hơn tối đa khoảng 2,7GB dung lượng có thể sử dụng cho 1 quy trình.
4. Bạn có thể chọn định kỳ khởi động lại một ứng dụng không hoạt động tốt mà không ảnh hưởng đến các ứng dụng khác.

Answer 7

Tách ứng dụng trong hồ bơi là một việc tốt cần làm khi có lý do và có một số lý do chính đáng được liệt kê ở trên. Tuy nhiên, có lý do chính đáng để không chia ứng dụng thành các nhóm khác nhau.

Ứng dụng sử dụng cùng quyền truy cập, phiên bản .NET, v.v. sẽ chạy hiệu quả hơn trong một hồ bơi duy nhất và dễ bảo trì hơn. Khó chịu nhất, IIS sẽ giết các nhóm ứng dụng không hoạt động, yêu cầu hồ bơi phải được tạo lại trên mỗi lần sử dụng. Nếu bạn cô lập các ứng dụng không thường xuyên sử dụng, bạn sẽ áp đặt chi phí khởi động không cần thiết cho người dùng. Kết hợp các ứng dụng này thành một nhóm đơn lẻ sẽ giúp người dùng hạnh phúc hơn khi họ không trả chi phí khởi động, máy chủ vui vẻ hơn khi họ không cung cấp bộ nhớ cho nhiều quy trình và lát CPU cho họ và quản trị viên vui vẻ hơn khi họ quản lý ít ứng dụng hơn hồ bơi.

Answer 8

Tôi đã từng có 58 trang web .Net và 17 trang web ASP cổ điển cũ trên cùng một máy chủ IIS7.5 sử dụng các hồ bơi ứng dụng riêng biệt cho từng trang web. Tôi nhận thấy rằng quá trình nén IIS bắt đầu không liên tục, khiến cho các trang mẫu bị hỏng khoảng 5% thời gian. Nhìn vào nhiệm vụ mamanger trên máy chủ, tôi có thể thấy rằng máy chủ đang tiếp cận giới hạn ram 4GB của nó - mỗi quá trình w3wp.exe đã lấy bất cứ thứ gì lên đến 100 MB bộ nhớ tùy thuộc vào lưu lượng truy cập mà trang web nhận được. Sau đó tôi chuyển tất cả các trang web thành 2 hồ bơi ứng dụng (một cho các trang web .net 4 và một cho các trang web ASP cổ điển cũ) và tổng bộ nhớ được sử dụng sau khi thực hiện điều đó giảm từ 3.8GB xuống dưới 2.8 GB - tiết kiệm hơn 1GB bộ nhớ không gian trên máy chủ. Sau khi thay đổi (và để máy chủ chạy trong vài giờ để trở lại mức lưu lượng truy cập bình thường), quy trình w3wp đang sử dụng 300MB cho tất cả các trang web .net và 20MB cho các trang web ASP cổ điển. Tôi có thể mở lại IIS nén một lần nữa mà không có vấn đề gì.

Sử dụng các nhóm ứng dụng riêng biệt là một ý tưởng tuyệt vời cho nhiều lý do được đề cập bởi các bài viết khác ở trên, nhưng nó cũng theo kinh nghiệm của tôi gây ra chi phí bộ nhớ cao hơn nhiều nếu bạn đang lưu trữ số lượng trang web trên cùng một máy chủ.

Tôi đoán đó là sự cân bằng giữa các giới hạn phần cứng và bảo mật cho dù bạn có muốn sử dụng các hồ bơi ứng dụng riêng biệt hay không. Đó là một ý tưởng tốt nếu bạn có các nguồn lực để làm điều đó.