ASP.NET 성능 모니터링 및 최적화 소개

요점:

• 인프라 측정항목은 애플리케이션 측정항목에 연결된 경우에만 가장 효과적입니다.

• 효율적인 성능 최적화의 핵심은 성능 데이터에 있습니다.

• 일부 APM 도구는 ASP.NET에 대한 기본 지원을 제공하므로 ASP.NET을 시작하려면 최소한의 초기 설정만 필요합니다.

• 코드 분석 도구는 프로그램 성능에 대한 가장 자세한 보기를 제공합니다.

• 경량 분석 도구는 웹 페이지 성능에 대한 실시간 보기를 제공하며 개발 및 프로덕션 환경 모두에서 사용할 수 있습니다.

"이 웹 페이지가 너무 느리게 열립니다!" 웹 사이트에 대한 이러한 불만은 특히 웹 응용 프로그램이 점차 데스크톱 응용 프로그램을 대체하기 시작한 이후 자주 발생합니다. 웹은 글로벌 전달과 같은 이상적인 기능을 제공하지만 성능 수준에서는 이에 상응하는 과제도 제시합니다.

데이터 수집 및 이용 기본원칙

사용자가 "느린" 웹페이지의 URL을 제공했는데 어떻게 해야 합니까? 느린 웹 페이지 열기 문제는 어디에서 발생합니까? 처음부터 이렇게 느린 걸까요? 모든 사용자에게 느린가요? 느린 웹 페이지 열기 문제를 해결하고 일주일 후에도 다시 느려지지 않도록 하기 위해 해결해야 할 이와 같은 문제가 많이 있습니다.

인터넷에서 일부 성능 최적화 정보를 검색할 수 있지만 일반적으로 Jit, 가비지 수집, SQL 쿼리 최적화, ORM 트랩 등과 같은 특정 주제에 관한 것입니다. 최적화 구현에 대한 매력적인 전망을 고려할 때 다음과 같은 질문이 제기됩니다. 선택한 최적화 방법이 실제로 현재 성능 문제에 대해 좋은 결과를 생성할 것인지 어떻게 알 수 있습니까?

이 작품에는 뭔가 빠진 것이 있다는 것은 의심의 여지가 없습니다. 지속적으로 성능 문제를 찾는 방법이 필요합니다. 이 접근 방식을 사용하면 시스템의 느린 부분을 식별하고 성능 문제 진단을 지원하는 실질적인 조치를 취할 수 있습니다. 성능 문제가 어디에 있는지 이해하면 성능 개선이 필요한지 여부를 추가로 판단하고 이 모든 것을 이해관계자에게 설명할 수 있습니다.

위에서 언급한 성능 문제가 발견되면 정확한 식별이 이를 처리하는 보다 효과적인 방법입니다. 문제는 애초에 웹페이지 로딩 속도가 느린 것이 아닐 수도 있습니다. 시간 초과가 있는 경우(예: 로드 밸런서가 연결을 서비스하기 전에 몇 초 동안 기다릴 수 있음) 교착 상태 문제인지 느린 응답 시간 문제인지 구분하는 것은 불가능합니다. 두 문제 모두 동일한 원인이 되기 때문입니다. 시간 초과. 문제의 실제 원인을 찾으려면 데이터가 필요합니다.

성능 문제를 정확하게 식별하는 것의 중요성을 설명하기 위해 웹 애플리케이션의 응답 속도를 저하시키는 몇 가지 가능한 문제 해결 지점은 다음과 같습니다.

• JavaScript가 느리게 반응합니다.

• 
  

• 리소스 로딩 중 차단이 발생합니다.

• 
  

• 클라이언트 측에 프록시가 있습니다.

• 
  

• DNS 문제

• 
  

• ISP 또는 네트워크 문제

• 
  

• 스위치 및 라우터

• 
  

• 로드 밸런서;

• 
  

• 애플리케이션 코드(타사 소프트웨어 라이브러리 포함)

• 
  

• HTTP 서버(예: 때때로 ASP.net 또는 IIS)

• 
  

• 제3자 서비스: 결제 서비스 제공업체, 지도 서비스 제공업체 등

• 
  

• SQL Server, Redis, Elasticsearch, Rabbit MQ 등을 포함한 하위 시스템

해결해야 할 시스템의 복잡성과 크기에 따라 추가 성능 문제 해결 지점이 나열될 수 있습니다. 너무 많은 시스템 구성 요소가 성능 최적화 문제에 영향을 미칠 수 있는 경우 성능 문제를 어떻게 진단할 수 있습니까? 그 대답은 데이터라는 한 단어로 요약될 수 있습니다. 모든 시스템 구성요소로부터 관련성 있고 의미 있는 데이터가 필요합니다. 느린 웹 애플리케이션 응답 문제의 경우 각 시스템 구성 요소가 문제에 영향을 미치는지 아니면 전혀 관련이 없는지 데이터를 통해 증명할 수 있습니다.

데이터를 손에 넣으면 정렬 트리에서 검색하는 것과 유사한 분석 아이디어에 따라 위 목록에서 문제 해결 지점을 추출할 수 있습니다. 트리에서 한 단계 아래로 내려갈 때마다 성능 문제의 세부 사항과 본질에 더 가까워집니다.

• 에 성능 문제가 있는지 확인하세요. 클라이언트 측, 서버 측 또는 그 사이 어딘가에 있습니까?

• 
  

• 느린 JavaScript, 렌더링 또는 리소스 차단?

• 
  

• 로드 밸런서, 웹 서버, 하위 시스템 또는 타사 소프트웨어?

이러한 트리에서 수준별로 아래로 내려갈수록 성능 문제가 점점 더 명확해집니다. 각 문제 해결 수준에서 성능 문제를 찾는 데 필요한 데이터는 해당 문제의 정확성과 일치해야 합니다. 이때 성능 분석 도구나 SQL 실행 계획 등의 도구를 활용하는 것이 필요하다.

시간을 효율적으로 사용하려면 암달의 법칙을 반복해야 합니다:

작업이 아무리 개선되더라도 개선의 이점을 얻지 못하는 작업 부분은 이론적 작업 속도 향상을 제한합니다.

예를 들어 웹 요청의 경우 서버 처리 시간은 100ms, SQL 쿼리 시간은 5초가 소요된다고 가정합니다. 서버 처리 시간을 1밀리초 미만으로 최적화할 수 있더라도 전체 응답 시간의 개선 효과는 5.1초에서 5초로 작습니다. SQL 처리를 개선하는 데 필요한 5초는 잠재적인 이득이 가장 큰 최적화입니다.

건축 문제

최적화 문제를 계층별로 명확히 하는 이러한 하향식 방법은 단일 페이지로 제한된 최적화 문제에 좋은 영향을 미칩니다. 그렇다면 여러 페이지에 걸쳐 있는 최적화 문제에 적용하면 어떤 영향이 있을까요? 예를 들어, 일부 페이지가 간헐적으로 느리게 열리는 문제는 하위 시스템이 전체 작업 리듬을 따라갈 수 없거나 시스템을 다시 시작한 후 더 이상 작동하지 않는 오래된 네트워크 스위치가 있기 때문에 발생합니다.

이 경우 애플리케이션 중심 모니터링 접근 방식은 한계를 보여줍니다. 이를 위해서는 시스템의 각 구성 요소를 평가하기 위해 더 많은 소프트웨어 수준 및 하드웨어 수준 지표가 필요합니다.

하드웨어 수준에서 가장 먼저 떠오르는 것은 웹 서버와 데이터베이스 서버이지만 이는 빙산의 일각에 불과합니다. 시스템의 모든 하드웨어 구성 요소를 식별하고 모니터링해야 합니다. 여기에는 서버, 네트워크 스위치, 라우터, 로드 밸런서, 방화벽, SAN 등이 포함됩니다.

시스템 관리자의 정규 업무가 하드웨어 모니터링이라는 점을 고려하면 위의 모든 지표는 시스템 관리자에게 분명할 수 있습니다. 그러나 여기에 중요한 주의 사항이 있습니다. 이러한 모든 하드웨어 지표의 대부분은 소프트웨어 지표와 별도로 취급되는 경우 성능 관점에서 쓸모가 없습니다. 즉, 지표는 적절한 환경에 배치된 경우에만 가장 잘 작동할 수 있습니다.

예를 들어, 어떤 경우에는 데이터베이스 서버에서 CPU 사용량이 평균 50%인 것이 완전히 정상일 수 있지만 다른 서버의 경우 이는 시한폭탄입니다. 사용량이 가장 많은 시간대에 CPU 사용량이 50%라는 것은 더 많은 작업을 실행할 수 있는 공간이 여전히 많다는 것을 의미합니다. 그러나 유휴 기간 동안 50%의 CPU 사용량이 자주 발생하는 경우 이는 애플리케이션이 들어오는 요청의 갑작스러운 급증을 견딜 수 없음을 의미합니다.

요점은 시스템 상태를 평가하려면 CPU, 메모리, 디스크와 같은 시스템 전반의 지표가 애플리케이션 지표와 상관 관계가 있어야 한다는 것입니다. 시스템 상태에 대한 보다 완전한 보기를 제공하기 위해 요청 처리량과 같은 애플리케이션 메트릭과 CPU 사용률과 같은 시스템 메트릭을 시각화할 수 있습니다.

애플리케이션 성능 관리(APM) 도구

APM 도구는 데이터 수집, 데이터 저장, 데이터 시각화와 같은 기본 작업을 제공합니다. 일반적으로 에이전트는 데이터를 수집하여 데이터 저장소로 보내고, 웹 인터페이스를 사용하여 웹 요청에 초점을 맞춘 대시보드에서 데이터를 시각화하는 일을 담당합니다.

​APM은 다음 용도로 사용할 수 있습니다.

• 웹 애플리케이션 성능에 대한 전반적인 시각화 제공

• 
  

• 특정 웹 요청 성능을 시각화합니다.

• 
  

• 웹 애플리케이션 성능이 저하되거나 여러 오류가 발생하면 자동으로 알림을 보냅니다.

• 
  

• 비즈니스 규모가 큰 경우, 애플리케이션의 응답 모드를 확인하십시오.

여기에 예가 나와 있습니다.

다음은 기본적으로 ASP.NET 및 IIS를 지원하는 APM 도구의 전체 목록입니다.

• 뉴렐릭 APM

• 
  

• 애플리케이션 인사이트

• 
  

• 앱다이내믹스

• 
  

• 스택파이

인프라 모니터링 도구

인프라 모니터링 도구는 성능을 보다 완전하게 반영할 수 있는 호스트 수준에서 지표를 수집합니다. 이러한 측정항목은 하드웨어 및 소프트웨어 수준에서 수집됩니다.

• 데이터독

• 
  

• OpServer - 오픈 소스

​경량 분석 도구

경량 분석 도구는 특정 웹 요청에 대한 높은 수준의 지표를 제공하고 개발자가 웹 페이지를 탐색할 때 실시간 피드백을 제공합니다. 이러한 도구는 모든 환경 유형(개발 환경, QA 검증, 스테이징 환경, 프로덕션 환경 등 포함)에서 사용할 수 있으므로 특정 페이지 성능을 빠르게 평가하는 데 이상적입니다.

해당하는 모든 기능을 갖춘 분석 도구와 비교할 때 경량 분석 도구의 근본적인 차이점은 프로세스에 연결되지 않는다는 것입니다. 즉, 경량 분석 도구를 사용할 때 발생하는 오버헤드에 대해 걱정할 필요가 없습니다.

개발 환경에서는 경량 분석 도구가 현재 작성 중인 코드에 대한 실시간 피드백을 제공합니다. 응답 시간은 항상 페이지 모서리에 표시되므로 N+1 또는 느린 응답 시간과 같은 문제를 발견하는 데 매우 유용합니다.

• 오픈 소스 MiniProfiler

• 
  

• 오픈소스 살펴보기

성능 카운터로 공백 메우기

Windows 시스템의 성능 카운터는 하드웨어 및 소프트웨어 수준에서 다양한 표시기를 제공합니다. 모니터링 도구는 일반적으로 CPU 및 메모리 사용량과 같은 성능 카운터를 보고합니다. 그러나 가비지 수집 시간 등과 같은 일부 유용한 카운터가 누락되는 경우가 많습니다. 시작하는 가장 실용적인 방법은 기본 목록을 사용하고 반복에 필요한 관련 카운터를 추가하는 것입니다. 또한 perfmon을 사용하면 성능 카운터를 실시간으로 수집하고 시각화할 수 있습니다. 많은 경우 사용자 정의 지표나 플러그인을 APM 도구와 통합하는 것도 가능합니다.

SQL 도구

데이터베이스는 많은 애플리케이션에서 일반적으로 사용되므로 지속성 계층(예: SQL 데이터베이스)은 성능 병목 현상이 발생하는 경우가 많습니다. SQL 모니터링을 위한 전문 도구는 리소스 사용량 메트릭뿐만 아니라 대기 시간, 초당 컴파일 등과 같은 특정 메트릭도 제공할 수 있습니다.

다음 데이터를 제공하면 일부 유형의 문제를 발견하고 성능을 향상할 수 있습니다.

• 하나 이상의 쿼리에 대한 과도한 처리량

• 
  

• 쿼리 문제 또는 인덱스 누락을 시사하는 과도한 CPU 사용량. 캐시할 수 있는 처리량이 높은 쿼리입니다.

• SQL 모니터링 도구에는 다음이 포함됩니다.
  

• RedGate SQL 모니터

• SQLSentry 성능 조언자

• 기타 지속성 시스템
  

  모든 하위 시스템을 어느 정도 모니터링해야 합니다. 처리량이 낮거나 중요하지 않은 시스템의 경우 간단한 데이터 수집 및 시각화로 충분합니다. 다른 경우에는 더욱 발전된 전문적인 모니터링이 필요합니다.
• 코드 분석 도구
  특정 페이지나 코드 조각이 느린 것으로 식별되면 코드 분석 도구는 성능 문제 식별을 위해 가능한 가장 자세한 보기를 제공할 수 있습니다. 코드 분석 도구는 데이터베이스 쿼리 및 웹 요청과 같은 외부 호출에 대한 정확한 보기도 제공합니다.

분석 도구:

레드게이트 개미

• JetBrains dotTrace

• 메모리 분석 도구
  

  메모리 모니터링 및 가비지 수집 지표는 잠재적인 문제를 감지하는 데 도움이 됩니다. 그러나 이러한 지표는 문제가 있음을 보여주지만 문제가 어디에 있는지 알려주지 않는 경우가 많습니다. 메모리 및 가비지 수집 문제를 더 자세히 조사해야 하는 경우 메모리 분석 도구가 유용할 수 있습니다.
• 분석 도구:

JetBrains dotMemory

• RedGate Ants 메모리 프로파일러

• 클라이언트 분석 도구
  

  성능 문제는 프런트 엔드에서도 발생할 수 있습니다. 이 문제는 요즘 JavaScript로 구동되는 단일 페이지 애플리케이션의 확산으로 인해 매우 일반적입니다. 모든 주요 브라우저에는 코드 분석 및 메모리 분석과 같은 도구가 내장되어 있습니다. 이벤트 및 요청의 순서를 표시하는 도구는 문제가 프런트 엔드에서 발생하는지 백엔드에서 발생하는지 한눈에 판단하는 데 도움이 됩니다.
• 도구:

Google 크롬 타임라인

• 파이어폭스

• 페이지 분석 도구
  

  고급 클라이언트 도구는 성능 문제를 식별하고 해결하기 위한 편리한 시작점을 제공합니다. 이러한 도구는 응답 시간 문제의 근본 원인에 대한 높은 수준의 보기를 제공하고 이에 상응하는 몇 가지 권장 사항을 제공할 수 있습니다. 예를 들어 Google의 PageSpeed ​​​​Insights는 무료 도구입니다.
• 시스템 성능과 관련된 요소와 도구가 너무 많아서 복잡해 보일 수도 있습니다. 하지만 이는 데이터라는 한 단어로 요약될 수 있습니다. 시스템을 명확하고 정확하게 파악하면 성능 문제를 추론하는 것이 가능해집니다. 또한 성능 지표와 그래프를 통해 시스템 성능에 정확히 영향을 미치는 요소를 발견할 수 있으므로 즉석에서 성능 문제를 해결하는 방법을 배울 수 있습니다.

위 내용은 ASP.NET 성능 모니터링 및 최적화 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!