IIS 7.x 응용 프로그램 풀 모범 사례


24

새 서버에 여러 사이트를 배포하려고합니다. 응용 프로그램 풀에 대해 다음과 같은 질문이 있습니다.

  1. 웹 사이트 당 하나의 응용 프로그램 풀을 갖는 것이 좋습니다. 이 접근법에 대한주의 사항이 있습니까? 하나의 응용 프로그램 풀이 모든 CPU, 메모리 등을 혼용합니까?

  2. 응용 프로그램 풀에서 여러 작업자 프로세스를 언제 허용해야합니까? 언제하지 말아야합니까?

  3. 하나의 응용 프로그램 풀이 다른 응용 프로그램 풀을 방해하지 못하도록 개인 메모리 제한을 사용할 수 있습니까? 너무 낮게 설정하면 유효한 요청을받지 않고 유효한 요청이 응용 프로그램 풀을 재활용해야합니까?

  4. 개인용 메모리와 가상 메모리 제한의 차이점은 무엇입니까?

  5. 사이트 당 하나의 응용 프로그램 풀을 실행하지 않아야하는 강력한 이유가 있습니까?


첫 번째 질문 :이 웹 사이트 (예 : .htm / .js) 또는 웹 응용 프로그램 (예 : .aspx / .php)입니까?
코딩 고릴라

대부분 .Net 3.5 응용 프로그램. 하나는 타사 PHP 응용 프로그램입니다.
Eric Burcham

1
이 주제는 광범위한 주제입니다-주제 (@CodingGorilla의 답변)는 흥미롭지 만 SF의 Q-and-A 스타일에 가장 적합하지 않을 수도 있습니다
voretaq7

답변:


20

1) 웹 사이트 당 응용 프로그램 풀을 갖는 것이 좋습니다. 이 접근법에 대한주의 사항이 있습니까? 예를 들어 하나의 응용 프로그램 풀이 모든 CPU, 메모리, 기타 등을 숨길 수 있습니까?

이것은 꽤 좋은 접근법입니다. 다른 "사이트"(응용 프로그램)가 동일한 풀을 공유한다고 생각할만한 이유는 없습니다. 그들이 어떤 종류의 단일 자원을 공유 할 필요가 없다면. 하나의 응용 프로그램은 이론적으로 많은 CPU 또는 메모리를 사용할 수 있지만 응용 프로그램이 풀링되는 방식을 변경해도 큰 영향을 미치지는 않습니다.

2) 응용 프로그램 풀에서 여러 작업자 프로세스를 허용해야하는시기 언제하지 말아야합니까?

기본 설정을 사용하는 것이 가장 좋습니다. 실제로 무엇을하고 있는지 알지 못하면 실제로 웹 사이트 / 애플리케이션에 부정적인 영향을 줄 수 있습니다.

3) 하나의 응용 프로그램 풀이 다른 응용 프로그램 풀을 방해하지 않도록 개인 메모리 제한을 사용할 수 있습니까? 너무 낮게 설정하면 유효한 요청을받지 않고 유효한 요청이 응용 프로그램 풀을 재활용해야합니까?

a) 이론적으로

b) 예, 낮게 설정하면 부정적인 영향을 줄 수 있습니다. 다시 말하지만, 특정한 필요가없고,하고있는 일을 알지 못한다면, 그냥 내버려 두십시오.

4) 개인 메모리와 가상 메모리 제한의 차이점은 무엇입니까?

매우 복잡합니다. 여기에 도움이 될만한 빠른 게시물이 있습니다. http://cybernetnews.com/cybernotes-windows-memory-usage-explained/

5) 사이트 당 하나의 응용 프로그램 풀을 실행하지 않아야하는 강력한 이유가 있습니까?

다시 한 번, 내가 생각할 수있는 유일한 이유는 여러 응용 프로그램에 필요한 일종의 "공유 리소스"가있는 경우 동일한 프로세스에서 실행하려는 것입니다.

범용 응용 프로그램 및 웹 사이트의 경우 IIS는 기본값으로 설정되어 있습니다.

****최신 정보****

# 2에 대한 추가 정보 요청과 관련하여 특별한 요구가없는 한이 작업을 수행해서는 안됩니다. 시간이 오래 걸리는 서버 작업의 경우에도 여러 스레드를 사용하여 요청이 처리되며 "비동기 요청"을 사용하여 오래 실행되는 작업 (다른 요청을 처리하기 위해 스레드 풀 스레드를 해제)을 처리하려고합니다. 실제로 단일 풀에 대해 여러 프로세스를 허용해야 할 이유는 없습니다.

여러 프로세스를 이야기하기 시작하면 프로세스 1에서 세션이 활성 상태이므로 세션 상태가 손실되지만 요청은 프로세스 2에서 처리되고 있습니다. 또는 더 나쁜 방법은 프로세스 간 의사 소통을하는 것은 정말 고통스러운 일입니다.

여러 프로세스의 이유와 관련하여 무엇을 가져가더라도 다른 프로세스를 실행하는 대신 프로세스를 처리하는 더 좋은 방법이 기꺼이 내기 것입니다.


신중한 답변을 주셔서 감사합니다. # 2에 대한 더 구체적인 정보가 있다면 감사하겠습니다. "최고의 혼자 남겨 두는 것"은 현명한 조언이지만, 여러 작업자 프로세스를 사용하는 경우를 아는 것도 좋을 것입니다. 큰 보고서, 큰 게시물을 허용하는 웹 서비스 등과 같이 응답을 반환하는 데 시간이 오래 걸리는 서버 작업이있는 경우 더 관련성이 있다고 가정합니다. 또한 모든 일반 스레드 동시성 항목이 적용된다고 가정합니까?
Eric Burcham

추가하기 : 앱이 제대로 재생되지 않을 것으로 예상되는 경우 IIS의 설치 대화 상자는 Windows 시스템 리소스 관리자를 설치하고 사용하여 앱 풀의 CPU 및 메모리 사용을 제한 할 수 있습니다.
TristanK

@TristanK, 팁 주셔서 감사합니다. 그것은 매우 도움이되었습니다.
Eric Burcham

@Coding Gorilla-통찰력에 다시 한번 감사드립니다. 나는 "웹 ​​가든을 사용하는 이유"에 대해 진지하게 조사하기로 결정했고 몇 가지 응답을 내놓았다. 언급 한 모든주의 사항, 특히 다양한 캐시 및 사용자 세션과 같은 공유 리소스에 대한 비동기 액세스를 처리 할 때 적용됩니다. 웹 가든 기능은 본질적으로 코어 이상의 서버가있는 단일 서버에서 요청을로드 밸런스합니다. 따라서 요청 라우팅을 제외하고는로드 밸런싱 시나리오에서 일반적으로 다루는 모든 경고를 처리해야합니다.
Eric Burcham

@Coding Gorilla-계속 ... 여러 작업자 프로세스 기능을 사용하는 가장 좋은 이유는 성능을 높이는 것입니다. iis-aid.com/articles/performance_testing/… 링크를 확인하십시오 . 물론 대부분의 웹 사이트는 (최소한 시작하여) 단일 작업자 스레드를 실행하기 때문에 웹 사이트를 고려하지 않는 프로그래밍의 모든 비동기 측면에서 수행하는 작업을 잘 알고 있습니다. 내 질문에 대한 짧은 대답은 다음과 같습니다. 성능 문제가있는 경우 시도하십시오.
Eric Burcham

4

항상 웹 사이트 전용 응용 프로그램 풀을 구성합니다. 저렴한 웹 사이트 호스팅 시나리오는 응용 프로그램 풀당 많은 수의 사이트를 갖는 것이 합리적입니다.

메모리 제한은 실제로 사이트가 모든 시스템 리소스를 사용하지 못하도록하는 기본 안전 임계 값일뿐입니다. x86 응용 프로그램의 자연스러운 2GB 메모리 상한이 있기 때문에 이것은 IIS 6.0 x86보다 Windows 2008 R2 x64에서 잠재적 인 문제입니다. IIS 7.5에서는 메모리 누수가있는 응용 프로그램이 방대한 양의 메모리를 사용하는 것이 훨씬 쉽습니다.

나는 또한 응용 프로그램 풀을 재활용하는 팬이 아닙니다. 응용 프로그램 풀이 있고 실행중인 유일한 응용 프로그램 인 경우 코드에 아무런 문제가 없으면 응용 프로그램 풀을 재활용 할 필요가 없습니다. 응용 프로그램에 결함이있는 경우 궁극적으로 적절한 조치는 코드를 수정하는 것입니다.


메모리에서 32 비트 캡을 지적 해 주셔서 감사합니다. 나는 이런 것들을 어떻게 잊는 지 모른다. 또한 응용 프로그램 풀에 충돌을 일으킬 정도로 결함이있는 응용 프로그램이있는 경우 올바른 접근 방식은 코드에 액세스 할 수 있다고 가정하고 수정하는 것입니다. 조언을 주셔서 감사합니다!
Eric Burcham

우리는 우리 자신의 테스트를했습니다. 응용 프로그램 풀을 실행하면 동일한 응용 프로그램 풀에서 응용 프로그램을 모두 실행하는 것보다 앱 풀당 약 64K의 오버 헤드가있는 것 같습니다. 메모리 사용량을 모니터하기 위해 성능 모니터를 사용하여 샘플 시간이 12 시간 이상입니다. 이것은 64 비트 서버에있었습니다. 이 간단한 테스트가 올바른 것으로 판명되면 응용 프로그램 당 하나의 앱 풀의 리소스 비용은 기본적으로 최신 하드웨어에서 무시할 수 있다고 생각합니다.
Eric Burcham
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.