곧 1000 개 이상의 요청/초를 가진 고성능 ASP.NET Json API를 작성합니다. 내 모든 논리와 처리는 IHttpHandler에서 수행됩니다. 나는 Stopwatch Class를 통해 측정했고 핸들러는 0,1 - 0.5 밀리 세컨드 (millisecond) 내로 요청을 끝낸다.고성능 ASP.NET 사이트 (> 1000 Request/Second)
하지만 IIS 및/또는 다른 HTTPHandlers (모듈?)이 많은 성능을 사용하고있는 것으로 보입니다. 어떻게 든 측정 할 수 있을까요? 최상의 성능을 위해 구성된 경우 IIS에서 요청의 오버 헤드는 얼마나됩니까?
HTTPHandlers 도움말을 모두 제거 하시겠습니까? 아니면 속도를 높이기위한 다른 트릭이 있습니까? 세션 외에도 많은 ASP.NET 애트리뷰트가 필요하지 않습니다 (상당한 성능 향상을 제공한다면 해결할 수도 있습니다).
웹 서버의 성능 측정은 간단한 작업이 아닙니다. 고려해야 할 몇 가지 사항은 다음과 같습니다.
참고 1 : 도구를 알고 있어야합니다. ASP.NET은 자체 스레드에서 각 요청을 실행합니다. 스레드 교환은 프로세스 교환보다 빠르지 만 여전히 시간이 필요합니다. 다른 처리기가 요청 체인에 있기 때문에 시간이 걸리는 경우이를 비활성화하는 것이 좋습니다.
참고 2 : stackoverflow의 원래 부수적 목표 중 하나는 최대 2 대의 서버에서 뛰어난 성능을 발휘하고 시간당 1Mln 방문자를 처리 할 수있는 ASP.NET 사이트를 만드는 것이 었습니다. 그들은 그 일을 처리했습니다. 나는 그들이 그것에 blogposts를 썼다라고 생각한다. 그러나 나는 그들이 어디에 있는지 기억하지 않는다.
아주 좋은 질문입니다. 내가 응답 시간의 1 밀리 초 범위에 도달하면 같은 것을 보았습니다. ASP.NET 오버 헤드가 눈에 띄기 시작합니다. 당신의 관찰을 확인할 수 있습니다.
내가 성공적으로 수행 한 작업은 IIS 관리자를 사용하여 등록 된 HttpModules을 찾아서 제거 할 수있는 모든 기능을 해제하는 것입니다. 표준 ASP.NET 파이프 라인에는 많은 모듈과 기능이 구성되어 있습니다.
궁극적 인 성능이 필요한 경우 물론 작은 HTTP 서버 라이브러리를 사용하여 거의 모든 오버 헤드를 제거 할 수 있습니다. 이것은 매우 빠를 것입니다.
실제로, _tiny_ 서버는 대형 HTTP 서버보다 많은 요청을 처리 할 수있는 황금률이 아닙니다. 그 반대가 더 일반적입니다. – Abel
이것은 작고 큰 것이 아닙니다. 요청 당 실행되는 코드의 양입니다. 우리는 OP가 많은 코드가 실행 중이라고 언급 한 대기 시간으로부터 알 수 있습니다. HTTP 헤더를 파싱하고 소켓을 사용하는 것보다 훨씬 더. – usr
은 사용 가능한 모듈을 제거하는 것에 동의합니다. Failed Event Tracing (100-999 응답)을 사용하고 호출 된 모든 모듈을 살펴보십시오. 그런 다음 필요없는 모듈을 모두 제거하십시오. - 나는 작은 서버 아이디어에 동의하지 않는다. (그러나 나는 당신을 어쨌든 upvoted :)) – RickAndMSFT
'비공식적으로'비동기이며 자체 호스팅 될 수 있으므로 (IIS에서 실행되지 않도록 할 수 있음) ASP.NET 웹 API (MVC4에 기본 제공되지만, 사용 가능한 독립형). 나는 Henrik의 블로그에서 좋은 점을 배웠다 @ http://blogs.msdn.com/b/henrikn/ –
FWIW, 질문의 표현은 대기 시간/대역폭을 섞어 놓은 것처럼 조금 이상하다. (네트워크 용어 사용).특정 요청을 처리하기위한 대기 시간은 효율적이고 동시에 제공 할 수있는 능력에 비해 중요하지는 않습니다 (최종 사용자 환경 외에도 확장성에 직각입니다). IOW, 모든 요청에 서비스를 제공하는 데 1000ms가 걸렸지 만 한 번에 2000 명을 지원할 수 있다면 여전히 괜찮을 것입니다. –
만들고있는 API에 얼마만큼 적용 할 지 모르지만 캐시 할 수있는 것이 있으면 꼭 확인하십시오. 그리고 무국적자라면 ARR을 사용하고 필요할 경우 확장 할 수 있습니다. –