ASP.NET APP의 성능을 향상시키는 12가지 팁 – 2부

이 게시물은 ASP.NET 애플리케이션의 성능을 개선하기 위한 6가지 팁에 대해 논의한 이전 게시물의 두 번째 부분입니다. 이 게시물에서는 응용 프로그램 성능을 위한 또 다른 부스터가 될 수 있는 6가지 팁에 대해 더 논의할 것입니다. 이전 게시물에 대한 링크는 다음과 같습니다.

ASP.NET 애플리케이션의 성능을 획기적으로 향상시키기 위한 12가지 팁 – 1부

7. 페이지를 비동기식으로 만들기

IIS는 CLR 스레드 풀을 사용하여 응용 프로그램에 들어오는 요청을 처리하는 스레드를 가져옵니다. 예를 들어, 현재 풀에 사용 가능한 스레드가 20 개라면 20 개의 요청 만 병렬로 제공 할 수 있으며 요청 처리에 시간이 걸리는 경우 몇 밀리 초 내에 수백 개의 홀수 요청이 폭격을 받으면 재해가 될 수 있습니다. 이 경우 일부 요청은 시간이 매우 오래 걸릴 수 있으며 일부 요청은 404 상태 코드를 반환할 수 있습니다. 모든 요청의 경우 데이터베이스로 이동하여 파일을 가져오거나 읽기/쓰기, 웹 서비스 호출 등과 같이 요청이 현재 범위를 벗어날 때 시간의 상당 부분이 사라집니다. 이 기간 동안 현재 스레드는 응답이 반환될 때까지 계속 대기합니다. 따라서 페이지를 비동기식으로 만들고 시간이 많이 걸리는 호출을 비동기적으로 처리하면 처리량을 상당히 늘릴 수 있습니다. 페이지를 비동기적으로 처리하려면 페이지에 async 지시문을 다음과 같이 추가합니다.

또한 이제 async 및 await 키워드의 도입으로 비동기 코드를 작성하는 것이 매우 쉬워졌습니다. 비동기 메서드를 작성할 수 있으며 페이지의 RegisterAsyncTask 메서드를 사용하여 사용할 수 있습니다.

8. 응용 프로그램 풀 일시 중단

이 기능은 Windows Server 2012 R2 및 .NET 4.5.1에서 도입되었습니다. IIS는 기본적으로 20분으로 설정되는 응용 프로그램 풀에 대한 유휴 시간 제한 설정을 제공합니다. 즉, 20분 동안 요청이 없으면 서버 리소스를 절약하기 위해 작업자 프로세스(w3wp.exe)가 중지됩니다. 그러나 작업자 프로세스가 현재 중지되어 있기 때문에 서비스를 제공하는 동안 작업자 프로세스를 다시 시작하고 초기화해야 하기 때문에 다음 요청이 희생양이 된다는 부작용이 있습니다. 작업자 프로세스 재시작은 프로세스 시작, 구성 초기화, asp.net 초기화, 메모리에 바이너리 로드 등과 같은 많은 작업을 포함하기 때문에 비용이 많이 들고 시간이 많이 걸리는 프로세스입니다.

이 기능을 사용하면 프로세스를 중지하는 대신 일시 중지 할 수 있습니다.  일시 중단 후에는 대부분의 CPU와 메모리를 해제하여 동일한 서버에서 호스팅되는 다른 사이트에서 사용할 수 있게 됩니다. 그러나 요청이 오면 빠르게 활성화되고 요청을 처리하기 시작하는 상태로 유지됩니다. 활성 앱과 일시 중단된 앱의 개념이 있는 Windows 앱의 일시 중단과 비슷합니다.  그것은 두 가지 측면에서 도움이되는데, 첫째는 더 많은 응용 프로그램을 추가하여 더 최적으로 서비스를 제공 할 수 있으며 시간 초과 후에 오는 요청조차도 활성 요청과 큰 차이없이 빠르게 제공됩니다. 모든 앱 풀에서 다음과 같이 구성 할 수 있습니다.

Select application pool -> advanced settings

9. Global.asax에서 메소드 제거

Global.asax는 첫 번째 요청에서 한 번 실행되는 응용 프로그램 수준 메서드를 제공하고 다른 일부는 각 요청에서 실행됩니다. 대부분의 경우 이 파일에는 빈 메서드가 있으므로 내부에 코드가 없더라도 asp.net 해당 메서드를 실행하도록 합니다. 각 요청에서 ASP.NET Global.asax에서 사용할 수 있는 메서드가 있는지 확인하고 있는 경우 그에 따라 로드하고 실행합니다. 따라서 가장 먼저 빈 메서드를 제거해야 하며 페이지 수명 주기의 다른 위치에 코드를 배치하여 거기에서 일부 메서드를 제거할 수 있더라도 도움이 될 것입니다.

10. SqlDataSource를 사용하지 마십시오.

GridView와 같은 데이터 컨트롤의 데이터 원본으로 SqlDataSource를 사용하지 마세요. GridView의 경우 페이징을 사용하도록 설정하면 페이지 번호를 클릭할 때 데이터베이스에서 모든 레코드를 가져온 다음 자체적으로 페이징을 적용합니다. 정렬도 마찬가지입니다. 대신 ASP.NET 4.5에 도입된 모델 바인딩을 사용하여 IQueryable 쿼리를 사용하고 select 메소드 등을 사용하여 항목 목록을 반환할 수 있습니다. IQueryable은 모든 레코드 대신 10개의 레코드와 같이 데이터베이스에서 필요한 데이터만 가져오거나 데이터베이스 수준에서 데이터를 정렬하는 SQL 쿼리를 스마트하게 최적화 및 생성합니다. 따라서 페이징 및 정렬이 매우 효율적입니다. 마찬가지로 QueryableDataSource 또는 ObjectDataSource도 사용할 수 있습니다.

11. HTTP 연결 유지 사용

응답 헤더에 상주하고 웹 응용 프로그램의 성능을 크게 향상시키는 데 도움이 되는 또 다른 숨겨진 보석입니다. 이 응답 헤더는 특정 기간 동안 클라이언트 및 서버 연결을 열어 두며 여러 요청에서 사용됩니다. 연결이 열려 있는 경우 새 연결을 만드는 시간이 절약되어 서버가 응답을 매우 빠르게 보낼 수 있습니다. 기본적으로 활성화되어 있으며 연결은 120초 동안 열려 있습니다. 사용하지 않도록 설정하면 연결당 하나의 요청만 허용되는 HTTP 1.0으로 동작합니다. IIS에서 다음과 같이 구성 할 수 있습니다.

IIS로 이동 -> 원하는 웹 사이트 선택 - > HTTP 응답 헤더 열기 -> 오른쪽의 작업 탭에서 공통 헤더 설정을 클릭하십시오.

기본적으로 활성화되어 있습니다(원으로 둘러싸인 영역 참조). 애플리케이션이 이 기능을 활용하고 있는지 여부를 확인하려면 확인합니다.

주 – IIS 7.5 이상의 경우 이 헤더 태그는 응답 헤더에서 제거되고 기본적으로 설명된 대로 활성화되지만 반대의 경우 다른 헤더 태그가 있습니다. 비활성화 된 경우 응답 헤더에 Connection: close로 사용할 수있는 새 헤더가 있습니다. 요청 후 연결이 닫혔음을 의미합니다.

12. Remove ETag

하나의 HTTP 응답 헤더를 살펴보겠습니다

여기에서 ETag (빨간색 원 참조)와 같은 요소가 있음을 알 수 있습니다. 그것이 사용되는 방식을 이해하려고 노력합시다. 클라이언트 캐시에서 응답을 제공하는지 여부는 Cache-Control 및 Expires 속성과 ETag의 두 항목에 따라 달라집니다. ETag는 각 콘텐츠에 대해 웹 서버에 생성되는 해시 코드이며, 파일의 내용이 변경되는 경우 해시가 변경되어 캐시가 무효화됩니다. 웹 팜 시나리오에서는 해시도 서버에 따라 달라지기 때문에 콘텐츠가 동일하더라도 다른 서버에서 생성된 해시가 다릅니다. 따라서 요청이 다른 웹 서버로 이동하는 경우 콘텐츠가 동일하더라도 캐시에서 요청이 제공되지 않습니다. 따라서 응용 프로그램이 웹 팜에서 호스팅되는 경우 클라이언트 캐시를 더 잘 사용하기 위해 이 태그 자체를 제거하는 것이 좋습니다.

이 팁은 응용 프로그램의 성능에 상당한 영향을 줄 수 있는 몇 가지 매우 중요한 구성 변경 내용입니다.

ᅡ.       앞에서 IIS가 CLR 스레드 풀을 사용하여 요청을 처리한다고 설명했습니다. 예를 들어 응용 프로그램이 동시에 100개의 요청을 수신하고 이 수의 스레드를 스레드 풀에서 사용할 수 없는 경우 그 중 일부는 기다려야 합니다. CLR은 각 요청을 할당하기 위해 새 스레드를 만들기 시작합니다. 새 스레드를 만드는 것은 꽤 무거운 프로세스이며 이전 버전의 .net에서는 스레드 생성 속도가 스레드 당 2 초였던 반면 최신 버전에서는 약 0.5 초였습니다. 스레드당 0.5초를 고려하면 80개의 스레드를 만드는 데 40초가 걸리므로 응답 시간이 최소 1-40초가 다르다는 것을 이해할 수 있습니다. 요청 수가 500 또는 1000으로 가는 상황을 상상할 수 있습니다.

​machine.config 에는 기본적으로 다음과 같은 설정이 하나 있습니다.

다음과 같이 변경할 수 있습니다.

  maxWorkerThreads = "200" />

​minWorkerThread 수를 100으로 설정했으므로 각 스레드를 만드는 데 소요되는 시간이 줄어들고 IIS는 요청을 신속하게 처리 할 준비가됩니다. 위의 설정은 코어 CPU별로 적용됩니다.

나.      applicationHost에서 사용할 수 있는 또 다른 중요한 설정이 있습니다. 최신 버전의 maxConcurrentRequestsPerCPU (IIS 7+에서 사용 가능)가 5000이므로 구성 (응용 프로그램 풀 수준에서 설정할 수 있음)은 요구 사항에 따라 조정할 수 있습니다. 이름에서 알 수 있듯이 애플리케이션에서 처리할 수 있는 동시 요청 수의 제한을 설정합니다.

c.        맥스커넥션 또 다른 매우 중요한 구성입니다. 다른 시스템에 만들 수 있는 연결 수를 제한합니다. 기본값은 이전 버전 of.NET 에서 2였습니다. 웹 서버가 데이터베이스 / WCF 서비스 등과 같은 네트워크의 다른 시스템을 호출 할 때 그림에 나타납니다. 이는 한 시점에 연결이 양호한 고급 서버가 있더라도 두 개의 연결만 만들 수 있음을 의미합니다. 기계 수준 또는 응용 프로그램 수준에서 다음과 같이 변경할 수 있습니다.

여기서 우리는 그것을 100으로 변경했습니다. 요구 사항에 따라 늘리거나 줄일 수 있지만 적당한 수를 유지하는 것이 좋습니다. 그렇지 않으면 과잉이 될 수 있습니다. 그 외에도 IP 주소 또는 도메인 정보와 같은 보다 구체적인 세부 정보를 제공하여 네트워크의 특정 서버로 제한할 수 있습니다.

결론

이 시리즈에서는 다음 12가지 팁에 대해 논의했으며, 그 중 대부분은 웹 애플리케이션의 성능을 크게 향상시킬 수 있는 코드 변경 없이 쉽게 적용할 수 있습니다. 이것들은:

1. 커널 모드 캐시
2. Pipeline mode
3. Remove unused modules
4. runAllManagedModulesForAllRequests
5. Don’t write in wwwroot
6. 사용하지 않는 뷰 엔진 및 언어 제거
7. 페이지를 비동기식으로 만들기
8. 응용 프로그램 풀 일시 중단
9. Global.asax에서 메서드 제거
10. SqlDataSource를 사용하지 마십시오.
11. HTTP 연결 유지 사용
12. Remove ETag

나는 일반적으로 무시되는 팁에 대해 논의하려고 노력했지만 엄청난 성능 향상 잠재력을 가지고 있으며 빠르게 적용 할 수 있습니다. 번들링 및 축소, IIS 압축, ViewState, 클라이언트 캐싱과 같은 몇 가지 일반적인 트릭은 매우 중요하지만 시리즈에 포함되지 않은 것으로 잘 알려져 있습니다.