소프트웨어 성능 테스트, 분석 및 튜닝 연습으로가는 길 _ 읽기 노트 (2)

1 장 성능 테스트, 분석 및 튜닝 기본 사항

1.5 성능 분석 및 튜닝 모델

성능 지표를 얻는 것 외에도 성능 테스트는 성능 병목 현상과 성능 문제를 찾은 다음 성능 문제와 성능 병목 현상을 분석하고 최적화하는 것입니다. 기존 소프트웨어 모델과 인터넷 특성을 결합한 성능 튜닝 모델은 아래 그림과 같이 요약됩니다.

네트워크 분포

네트워크 배포는 빠르게 발전하는 인터넷 시대입니다. 일반적으로 네트워크 혼잡을 줄이고 사용자 요청에 신속하게 대응하기 위해 사용됩니다. 일반적으로 사용되는 기술은 네트워크 배포 CDN, 콘텐츠 네트워크 배포, 전 세계에 배포 된 에지 서버에 의존,로드 밸런싱입니다. 중앙 플랫폼을 통해., Origin 서버 콘텐츠 배포, 스케줄링 및 기타 기능 모듈을 통해 사용자가 원본 서버에 갈 때마다 응답을받는 대신 전 세계 사용자가 필요한 서비스를 근처에서 얻을 수 있습니다. 원 서버의 컨텐츠 업데이트는 전체 네트워크의 모든 네트워크 노드에 동기화됩니다. 동일한 리소스에 액세스하는 사람은 가장 가까운 에지 노드에 캐시되고 동기화됩니다. 해당 지역의 다른 사람이 리소스에 액세스하면 해당 리소스를 가져옵니다. CDN 캐시 서버에서 원본 서버에 대한 부담을 줄여 웹 사이트 성능을 향상시킵니다.

웹 서비스

웹 서버는 웹 서비스를 배포하는 데 사용되며 요청 응답 및 배포, 정적 리소스 처리를 담당합니다.

웹 캐시

Html, Css 및 이미지와 같은 정적 리소스 파일을 임시로 캐시하는 데 사용되는 웹 서버 캐시

응용 서비스

응용 프로그램은 외부 서비스를위한 핵심 프로그램 또는 서비스를 제공하기 위해 응용 프로그램 서버에 배포되며 응용 프로그램 서버는 Tomcat, WildFly, 일반 Java 응용 프로그램 등이며 응용 서비스는 사용자가 액세스 할 수있는 서비스를 제공하는 것입니다.

은닉처 

애플리케이션 캐싱, 애플리케이션 수준 캐싱 서비스는 일반적으로 Redis, MemCached 등을 포함합니다. 캐싱은 높은 동시성의 성능을 크게 향상시킬 수 있으며 분산 애플리케이션 아키텍처에서 자주 사용되는 기술입니다.

외부 시스템

대부분의 시스템은 외부 시스템 또는 내부 다중 모듈 상호 작용 또는 데이터 정보를 요청해야하는데, 이는 Http 연결 생성이 필요하고 서버 리소스를 소비하며 성능 분석의 초점이기도합니다.

데이터 베이스

데이터베이스는 시스템 성능의 병목 현상, 느린 쿼리 또는 잠금 스레드 작업 데이터베이스의 교착 상태 등이 될 가능성이 가장 높습니다.

1.6 성능 분석 및 튜닝 아이디어

1.6.1 계층화 분석

 계층 적 분석은 시스템 모델, 시스템 아키텍처, 호출 링크 계층에 따른 모니터링, 분석 및 문제 해결을 의미합니다. 계층 적 분석은 시스템 아키텍처 및 요청 처리 프로세스에 대한 지식이 필요합니다. 각 계층에서 ChekList를 설정해야합니다. 레이어 분석은 비효율적이지만 상향식 또는 하향식 일 수있는 더 많은 성능 문제가 발견 될 수 있습니다.

테스트 된 시스템에 대해 고려해야 할 질문 :

1. CPU 사용량은 얼마입니까? 자주 변동합니까? 컨텍스트 전환이 자주 발생합니까? 하드 인터럽트가 너무 많습니까?
2. 메모리 사용량은 얼마입니까? 느린 상승이 있습니까? 출시 될 예정입니까? 얼마나 많은 가상 메모리가 사용됩니까?
3. I / O 소비가 높습니까? I / O 대기가 있습니까?
4. 네트워크 대역폭은 무엇입니까? 네트워크 처리량은 얼마입니까?
5. 캐시 : 캐시 적중률? 캐시 에이징 시간? 충분한 메모리가 있습니까? 연결이 충분합니까? 연결이 유출 되었습니까? 전체 로그? redis 느린 로그
6. 데이터베이스 : 느린 쿼리? 데이터베이스 사무실이 기다리고 있습니까? 데이터베이스 캐시 적중? 데이터베이스 연결은 몇 개입니까? 연결이 유출 되었습니까? 연결 풀에 충분한 연결이 있습니까? 데이터베이스 테이블 모니터링, 쿼리가 전체 테이블 스캔입니까? 아니면 인덱스 쿼리? 데이터베이스가 스레드 경합을 실행합니까?
7. 애플리케이션 서비스 : 스레드로부터 안전합니까? 스레드 상태가 항상 실행 중입니까? 스레드가 차단 되었습니까? 교착 상태가 있습니까? gc는 정상입니까? 전체 GC가 빈번합니까? 연결이 몇 개이고 연결이 얼마나 오래 해제됩니까? 누출 될까요?
8. 서비스로드 밸런싱이 균등하게 분산되어 있습니까? 얼마나 많은 TCP 연결이 있습니까? 연결은 언제까지 해제됩니까?
9. 외부 서비스 응답이 비동기식입니까 아니면 동기식입니까? 시뮬레이션 장비를 사용하십니까?

1.6.2 과학적 논증

문제-문제 가설-예측-검증 및 논증-분석-문제 찾기

이것은 성능 문제를 분석하고 추측을 검증하고

1.6.3 문제 추적 및 요약

문제 추적 :이 테스트의 성능에 이전보다 큰 변화가있는 경우 시스템 또는 환경의 최근 변화를 추적해야합니다. 일반적으로 온라인 생산 버전 또는 환경 변화로 인한 성능 문제에 사용됩니다. 일반적으로 다운 스트림 추적을 통해 문제를 찾을 수 있습니다.

유도 및 요약 : 특정 성능 병목 현상 또는 성능 문제가 발생하면 과거에 요약 된 지식과 경험을 바탕으로 하나씩 확인합니다.

1.7 성능 조정 기술

1.7.1 캐시 조정

빠른 인터넷 개발 시대에 사용자 접근 요청의 응답 시간을 향상시키기 위해 캐싱 사용은 많은 대형 시스템이나 전자 상거래 웹 사이트에서 사용되는 핵심 기술이되었습니다. 합리적인 캐싱 설계는 동시 작업과 직접 관련이 있습니다. 시스템 또는 웹 사이트의 액세스 기능 및 사용자 경험. 캐시는 저장 위치에 따라 클라이언트 측 캐시와 서버 측 캐시로 나뉩니다.

캐시는 일반적으로 mysql 및 oracle보다 훨씬 빠른 메모리의 데이터를 읽습니다. 캐시는 쿼리 전에 데이터베이스에 도달하지 않습니다.

캐시 튜닝의 요점 :

1. 캐시 적중률을 높이는 방법은 무엇입니까?
2. 캐시 침투를 방지하는 방법은 무엇입니까?
3. 캐시의 에이징 시간을 제어하는 ​​방법은 무엇입니까?
4. 느린 로그 분석, 연결 번호 모니터링, 메모리 사용량 모니터링 등 캐시 모니터링 및 분석 방법
5. 캐시 눈사태를 방지하는 방법은 무엇입니까? 캐시 눈사태는 캐시 서버의 가동 중지 시간을 의미하며 캐시의 모든 데이터가 손실되어 데이터베이스에서 직접 데이터를 가져와야하는 많은 요청이 발생하여 과도한 압력으로 인해 데이터베이스가 중단됩니다. 데이터베이스.
6. 캐시 고장?

1.7.2 동기-비동기 응답

동기 요청은 요청을받은 후 요청이 처리되지 않은 경우 결과가 반환되지 않고 처리가 완료 될 때까지 응답 결과가 반환되지 않음을 의미합니다. 프로세서가 요청을 수신 한 후 결과를 반환하기 전에 비즈니스 1 및 비즈니스 2가 완료 될 때까지 기다립니다.

 

비동기 요청은 시스템이 요청을 수신 한 후 요청이 처리 된 직후 호출자에게 요청을 성공적으로 반환 한 다음 요청이 처리 된 후 비동기 적으로 호출자에게 푸시하거나 호출자에게 요청 결과를 다시 가져 오도록 요청하는 것을 의미합니다. 일정 시간이 지나면.

동기 대 비동기는 주로 동기 요청을 차단하고 대기하는 문제를 해결하는 것입니다. 차단되고 대기중인 요청으로 인해 요청 연결을 빠르게 해제 할 수없는 경우가 많아 동시성이 높은 처리 중에 연결이 충분하지 않게됩니다. 요청 프로세서는 대기열을 통해 비동기 적으로 요청을 수신 한 후 분산 병렬 처리를 수행하여 처리를 수행합니다. 용량 확장 및 네트워크 연결도 신속하게 해제 할 수 있습니다. 현재 일반적인 처리 방법은 수신 된 메시지를 먼저 Kafka 메시지 미들웨어로 보낸 다음 클라이언트 메시지에 비동기 적으로 응답 한 다음 Kafka 메시지를 비동기 적으로 사용하여 비즈니스를 처리하는 것입니다.

1.7.3 분할

분할은 시스템의 복잡한 업무 호출을 여러 개의 간단한 응용 프로그램으로 분할하는 것을 말합니다. 일반적으로 다음 원칙을 따릅니다.

1. 동시성이 높은 비즈니스 요청 및 호출의 경우 단일 하위 시스템 애플리케이션으로 개별적으로 분할됩니다.
2. 동시 방문이 유사한 기업의 경우 제품 사업에 따라 분할 할 수 있으며 동일한 유형의 사업이 백엔드 서비스입니다.

참고 사항 : 마이크로 서비스를 분할하려면 신중한 생각이 필요합니다. 분할과 관련된 서비스에는 데이터 교환, 내부 통신, 상호 의존성 등이 포함되므로 운영 및 유지 관리 비용과 개발 및 유지 관리 비용이 많이 증가합니다. 분할도 너무 많아서는 안됩니다. 상세하지만 고려하는 팀은 조직 구조, 관리 모드 등입니다.

위의 그림과 같이 동시성이 높은 비즈니스를 하위 시스템에서 별도로 처리하면 유사한 비즈니스를 병합하여 시스템의 동시성을 향상시킬 수 있습니다.이 분할의 장점은 높은 동시성 비즈니스가 성능에 영향을 미치지 않는다는 것입니다. 낮은 동시성 비즈니스의 경우, 시스템이 하드웨어로 확장되면 자원 낭비를 피하기 위해 목표 한 방식으로 확장 할 수 있습니다. 동시에 시스템에는 서로 다른 서비스를 구별하고 서비스 요청을 다양한 하위 시스템에 배포하기위한 통합 입구 역할을하는 라우팅 서비스도 필요합니다. 라우팅 서비스는 또한 통합 비즈니스 인증 서비스와 통합 요청, 응답 처리 또는 비즈니스 통계 및 기타 기능을 구현하여 하위 시스템의 공용 처리를 피하고 하위 시스템이 비즈니스 관련 문제에 집중할 수 있도록하고 하위 시스템의 처리 기능을 개선 할 수 있습니다.

1.7.4 작업 분해 및 병렬 컴퓨팅

작업 분해 및 병렬 컴퓨팅은 작업을 여러 하위 작업으로 분할 한 다음 여러 하위 작업에 대해 병렬로 계산 처리를 수행하고, 마지막으로 병렬 계산 결과를 병합하여 반환하기 만하면되므로 처리의 목적은 병렬 계산 방법을 통해 수행하는 것입니다. 처리 성능을 향상시킵니다. 멀티 스레딩은 병렬 컴퓨팅을 달성하고 동시 처리 기능을 향상시키는 데 사용되지만 데이터를 공유하는 스레드의 스레드 안전성에주의를 기울일 필요가 있습니다.

작업 분해 방법 1 :

작업 분류 2 :

 

1.7.5 인덱스 및 하위 데이터베이스 하위 테이블

인덱스는 응용 프로그램을 의미하므로 질의시 데이터베이스 인덱스 질의를 사용하십시오. 데이터베이스 테이블 생성시 질의 조건 필드에 적합한 인덱스를 설정하십시오. 여기서 강조하는 것은 적합한 인덱스 여야합니다. 인덱스가 설정되지 않은 경우 질의 효율성에 영향을 미치지 않을뿐만 아니라 도움말은 인덱스가 설정되어 데이터 삽입시 데이터베이스 속도를 늦추고 데이터 삽입시 데이터베이스가 자동으로 인덱스를 업데이트하여 데이터를 증가시킵니다. 데이터베이스 삽입시 자원 소비. 예를 들어 데이터베이스의 필드는 status이고 status 값은 0,1,2뿐입니다. status에 대한 인덱스를 작성하면이 값에는 0의 세 값만 있기 때문에 쿼리 효율성에 도움이되지 않습니다. , 1,2, 그리고 값 범위가 너무 작습니다. 인덱싱 후 상태에 따라 검색 할 때 스캔해야하는 데이터의 양이 여전히 매우 큽니다.

올바른 인덱스는 쿼리 효율성을 매우 향상시킬 수 있지만 테이블의 데이터가 매우 커서 수억 수준에 도달하면 인덱스 쿼리도 이때 매우 느리고 데이터 삽입도 매우 느립니다. 이때 데이터를 테이블 또는 서브 데이터베이스, 서브 데이터베이스로 구분해야한다는 것은 일반적으로 데이터베이스의 저장 용량이 이미 매우 크고 질의 및 삽입시 I / O 사용량이 매우 크다는 것을 의미합니다. 시간이 지나면 읽기 및 쓰기 중 I / O를 줄이기 위해 데이터베이스를 두 개의 라이브러리로 분할해야합니다.

하위 데이터베이스 하위 테이블의 일반적인 방법은 다음과 같습니다.

• 핫 데이터와 콜드 데이터 분리 방법에 따르면 사용 빈도가 높은 데이터를 핫 데이터라고하고 쿼리 빈도가 낮은 데이터를 콜드 데이터라고합니다. 콜드 데이터와 핫 데이터를 분리 한 후 핫 데이터는 별도로 저장되므로 데이터의 양이 줄어들고 데이터가 쿼리 될 것이라는 점을 알 수 있습니다. 성능은 자연스럽게 향상되며 핫 데이터에 대해서는 I / O 성능 튜닝을 별도로 수행하는 것이 더 편리합니다.
• 시간 차원에 따라 : 실시간 데이터와 과거 데이터는 데이터베이스와 테이블로 나뉘며, 연 / 월 시간 간격에 따라 데이터베이스와 테이블로 나눌 수 있으므로 각 데이터베이스 테이블의 데이터 양을 다음과 같이 줄일 수 있습니다. 가능한 많이
• 데이터베이스 운영 방법에 따르면 : 데이터베이스 읽기 및 쓰기 분리, 별도의 쿼리 작업 및 쓰기 작업, 읽기 및 쓰기 분리는 마스터 서버에서 수정하는 것이며, 데이터는 슬레이브 서버에 동기화되며 슬레이브 서버는 읽기 데이터 만 제공 할 수 있습니다. , 데이터를 쓰지 않고 백업을 달성하는 동시에 데이터베이스 성능의 최적화와 향상된 서버 보안을 실현했습니다.

데이터베이스 하위 데이터베이스 하위 테이블 이후의 또 다른 이점 : 단일 쿼리에서 여러 하위 테이블을 쿼리해야하는 경우 다중 스레드 병렬 방식으로 여러 하위 테이블을 쿼리하고 마지막으로 각 하위 테이블의 쿼리 결과를 병합 할 수 있습니다. 즉, 쿼리를보다 효율적으로 만들 수 있습니다.