[자격증] 정보처리기사 실기 : 20강 애플리케이션 테스트 관리 (애플리케이션 성능 개선하기)

 정보

• 업무명     : 정보처리기사 실기 : 20강 애플리케이션 테스트 관리 (애플리케이션 성능 개선하기)

• 작성자     : 이상호

• 작성일     : 2020-05-11

• 설   명      :

• 수정이력 :

 

 

 내용

[애플리케이션 성능 분석]

[1] 애플리케이션 성능 점검의 개요

• 애플리케이션 성능이란 사용자의 요구 기능을 해당 애플리케이션이 최소의 자원을 사용하면 서 얼마나 빨리, 많은 기능을 수행하는가를 육안 또는 도구를 통하여 점검하는 것을 말한다. 

• 1. 애플리케이션의 성능을 측정하기 위한 지표 

  • (1) 처리량(Throughput)

    • 애플리케이션이 주어진 시간에 처리할 수 있는 트랜잭션의 수로, 웹 애플리케이션의 경우 시간당 페이지 수로 표현하기도 한다. 

  • (2) 응답 시간(Response Time)

    • 사용자 입력이 끝난 후, 애플리케이션의 응답 출력이 개시될 때까지의 시간으로, 웹 애플리케이션의 경우 메뉴 클릭 시 해당 메뉴가 나타나기까지 걸리는 시간을 말한다. 

  • (3) 경과 시간(Turnaround Time)

    • 애플리케이션에 사용자가 요구를 입력한 시점부터 트랜잭션 처리 후 그 결과의 출력이 완료할 때까지 걸리는 시간을 말한다. 

  • (4) 자원 사용률(Resource Usage)

    • 애플리케이션이 트랜잭션 처리하는 동안 사용하는 Cpu 사용량, 메모리 사용량, 네트워크 사용량을 말한다. 

• 2. 유형별 성능 분석 도구 

  • 성능 분석 도구는 애플리케이션의 성능을 점검하는 도구와 시스템 자원 사용량을 모니터 링하는 도구로 분류할 수 있다. 

    •  (1) 성능/부하/스트레스(Performance/Load/Stress) 점검 도구 

      • 애플리케이션의 성능 점검을 위해 가상의 사용자를 점검 도구 상에서 인위적으로 생 성한 뒤, 시스템의 부하나 스트레스를 통해 성능 측정 지표인 처리량, 응답 시간, 경과 시간 등을 점검하기 위한 도구이다. 

    • (2) 모니터링(Monitoring) 도구 

      • 모니터링 도구는 애플리케이션 실행 시 자원 사용량을 확인하고 분석 가능한 도구로, 성능 모니터링, 성능 저하 원인 분석, 시스템 부하량 분석, 장애 진단, 사용자 분석, 용 량 산정 등의 기능을 제공하여, 시스템의 안정적 운영을 지원하는 도구이다. 

[2] 애플리케이션 성능 저하 원인 분석

• 애플리케이션의 성능이 저하되는 원인은 크게 DB 연결 및 쿼리 실행, 내부적인 요인과 외부적인 요인, 그리고 기타 환경 설정이나, 네트워크 등의 문제로 구분할 수 있다. 

• 1. 데이터베이스 연결 및 쿼리 실행 시 발생되는 성능 저하 원인

  • 일반적으로 DB에 연결하기 위해 Connection 객체를 생성하거나 쿼리를 실행하는 애플리케이션 로직에서 성능 저하 또는 장애가 많이 발견된다. 

    • (1) 데이터베이스 락(DB Lock) :대량의 데이터 조회, 과도한 업데이트, 인덱스 생성 시 발생하는 현상이며, 요청한 작 업은 Lock의 해제 시까지 대기하거나 타임아웃된다. 

    • (2) 불필요한 데이터베이스 페치(DB Fetch) :실제 필요한 데이터보다 많은 대량의 데이터 요청이 들어올 경우, 또는 결과 세트에서 마지막 위치로 커서를 옮기는 작업이 빈번한 경우 응답 시간 저하 현상이 발생한다. 

    • (3) 연결 누수(Connection Leak) / 부적절한 커넥션 풀 크기(Connection Pool Size) 

      • (가) 연결 누수(Connection Leak) DB 연결과 관련한 JDBC 객체를 사용 후 종료하지 않을 경우 발생한다. 

      • (나) 부적절한 커넥션 풀 크기(Connection Pool Size) 너무 작거나 크게 설정한 경우 성능 저하 현상이 발생할 가능성이 있다. 

    • (4) 기타 트랜잭션이 확정(Commit)되지 않고 커넥션 풀에 반환되거나, 잘못 작성된 코드로 인해 불필요한 Commit가 자주 발생하는 경우 성능이 저하될 가능성이 존재한다.

• 2. 내부 로직으로 인한 성능 저하 원인 

  • (1) 웹 애플리케이션의 인터넷 접속 불량 웹 애플리케이션의 실행 시 인터넷 접속 불량으로 서버 소켓(Server Socket) 쓰기는 지속되나, 클라이언트에서 정상적 읽기가 수행되지 않아 성능이 저하될 가능성이 있다.

  • (2) 특정 파일의 업로드, 다운로드로 인한 성능 저하 대량의 파일을 업로드하거나 다운로드할 경우 처리시간이 길어져 애플리케이션의 성 능이 저하될 가능성이 있다. 

  • (3) 정상적으로 처리되지 않은 오류 처리로 인한 성능 저하 오류 처리 로직과 실제 처리 로직 부분을 분리하지 않고 코딩하거나 예외가 발생할 경우에 제대로 처리되지 않아 행이 걸리는 상황이 발생하여 성능이 저하될 가능성이 있다. 

• 3. 외부 호출(HTTP, 소켓 통신)로 인한 성능 저하 원인 임의의 트랜잭션이 수행되는 동안 외부 트랜잭션(외부 호출)이 장시간 수행되거나, 타임아 웃이 일어나는 경우 성능 저하 현상이 발생할 수 있다. 

• 4. 잘못된 환경 설정이나 네트워크 문제로 인한 성능 저하 원인 

  • (1) 환경 설정으로 인한 성능 저하 

    • 스레드 풀(Thread Pool), 힙 메모리(Heap Memory)의 크기를 너무 작게 설정하면 Heap Memory Full 현상 발생으로 성능이 저하될 가능성이 있다. 

  • (2) 네트워크 장비로 인한 성능 저하 

    • 라우터, L4 스위치 등 네트워크 관련 장비 간 데이터 전송 실패 또는 전송 지연에 따른 데이터 손실 발생 시 애플리케이션의 성능 저하 또는 장애가 발생할 수 있다. 

 

[수행-애플리케이션 성능 분석하기]

[1] 애플리케이션 성능 점검을 위한 도구의 유형 정리

• 애플리케이션 성능 점검을 위한 성능 테스트 도구 및 시스템 모니터링 도구의 유형을 파악하고 그 특징을 간략하게 정리한다. 

• 1. 성능 테스트 도구의 유형에 대해 파악한다. 

  • 성능 테스트 도구의 도구 명, 도구 설명, 지원 환경, 지원 홈페이지 등의 정보를 파악하고 정리한다.

• 2. 시스템 모니터링 도구의 유형에 대해 파악한다.

  • 시스템 모니터링 도구의 도구 명, 도구 설명, 지원 환경, 개발 도구 지원 여부, 지원 홈페 이지 등의 정보를 파악하고 확인한다.

 

[2] 애플리케이션 성능 점검 계획서 작성

• 1. 성능 점검 계획서에 포함될 항목에 대해 검토한다. 애플리케이션 성능을 측정하기 위한 성능 점검 계획서의 각 항목에 대해 정의한다. 

  • (1) 성능 점검 목적 및 용어를 정의한다.

    • 해당 시스템의 성능 점검을 수행하는 목적 및 성능 점검 시 활용할 용어에 대해 정의 한다. 

  • (2) 성능 점검 수행 전략을 수립한다. 

    • (가) 대상 시스템의 구성도를 파악한다. 

      • 전체 시스템 중 성능을 점검해야 할 시스템을 파악하여 대상 구성도를 작성한다. 

    • (나) 대상 서버의 정보를 파악한다.

      • 대상 서버의 서버 명, IP주소, 설치된 운영 체제, CPU, 메모리, 설치된 솔루션 정보 를 파악하여 작성한다. 

    • (다) 성능 점검 수행 도구를 결정한다. 

      • 성능 점검을 위한 오픈소스 또는 상업용 수행 도구를 결정하여 작성한다. 

    • (라) 성능 점검 환경을 구성한다. 

      • 성능 점검을 위한 점검 팀을 확정하고, 부하 발생 장비, 부하 발생 환경에 대하여 확인한다. 

  • (3) 성능 점검 수행 일정 및 절차에 대해 확정한다. 

    • (가) 성능 점검 수행 일정에 대해 확정한다. 

      • 계획 수립, 설계 및 개발, 테스트 환경 구축, 테스트 수행, 결과 분석, 보고서 작성 등에 대한 성능 점검 수행 일정에 대해 확정한다.

    • (나) 성능 점검 수행 절차에 대해 확정한다. 

      • 테스트 계획 수립, 테스트 시나리오 작성, 테스트 케이스 작성, 워크로드(Workload) 설계, 레코딩, 테스트 수행, 결과 분석 등 성능 점검 수행 절차를 확정한다. 

    • (다) 성능 개선 절차에 대해 확정한다. 

      • 기본 성능 자료를 도출하고, 성능 테스트 결과를 분석하고, 개선안을 적용하고, 검증하여 성능 개선을 검증하는 절차에 대해 확정한다. 

    • (라) 성능 점검 역할별 수행 인력을 확정한다. 

      • 성능 팀, 공통 테스트 팀, 업무 개발 팀의 팀별 수행 인력을 확정한다.

  • (4) 성능 점검 수행 방안에 대해 작성한다. 

    • (가) 각 시스템의 단위 성능 테스트 방법에 대해 결정한다. 

      • 성능 테스트의 경우 가상 인원이 몇 명인지, Think Time(서버로부터 응답 후, 다음 동작 때까지 대기하는 시간)의 경우 몇 초로 테스트할 것인지를 결정한다.

    • (나) 시스템 성능 목표를 설정한다. 

      • 각 시스템별 테스트 유형과 대상 업무, 목표 부하, 테스트 시간 등을 확정하고 시 스템의 성능 목표를 설정한다.

    • (다) 모니터링 및 성능 지표 수집 방안에 대해 결정한다. 

      • 측정 대상을 구분하고 측정 목적, 시스템 명, 부하량, 배치 작업 소요 시간, SQL 등 의 모니터링 방안, 모니터링 측정 항목에 대해 설정한다. 

    • (라) 성능 테스트 시나리오를 작성한다. 

      • Ramp-Up Model, Ramp-Down Model, Think Time Model 등 다양한 성능 테스트 모 델별 성능 테스트 시나리오를 작성한다.

• 2. 성능 테스트 계획서를 작성한다. 성능 점검 개요, 성능 점검 수행 전략, 성능 점검 수행 일정 및 절차, 성능 점검 수행 방 안 등 결정된 항목을 포함하여 성능 테스트 계획서를 작성한다.  

 

[3] 애플리케이션 성능 테스트 수행

• 애플리케이션 성능 점검 목표에 따라 성능 테스트를 수행한다.

• 1. 애플리케이션 성능 테스트 케이스를 작성한다. 애플리케이션 성능 측정을 위한 테스트 케이스를 아래 항목을 포함하여 작성한다. 

  • (1) 테스트 목표 및 목표 값을 설정하여 작성한다.

    • 테스트 상황 및 사용자 수, 호출 간격, TPS(Transaction Per Second), 응답 시간 등 목 표 값을 설정한다. 

  • (2) 측정 항목을 기술하여 작성한다. 

    • TPS, 응답 시간, 시스템 사용률, 거래 성공 비율 등 측정 항목에 대해 기술한다. 

  • (3) 테스트 시나리오를 작성한다. 

    • 성능 테스트에 대한 구체적인 방법 및 절차에 대해 작성한다.

  • (4) 사전 확인 사항에 대해 작성한다. 

    • 테스트 시작 시간, 종료 시간, 스크립트 수행 횟수, 부하 발생기 상태 확인, 데이터베이스 상태 확인, 투입인력 확인, 테스트 환경 설정, 테스트 데이터 등에 대해 작성한다

• 2. 애플리케이션 성능 테스트를 수행한다. 작성된 테스트 케이스 및 테스트 시나리오에 따라 애플리케이션 성능 테스트를 수행한다. 

  • (1) 선정된 성능 테스트 도구를 설치한다. 

    • 대상 시스템에 선정된 테스트 도구를 설치한다.  

  • (2) 테스트 도구의 테스트 환경을 설정한다. 

    • 해당 시스템의 운영 체제, DBMS 버전, 네트워크 상태 등에 대해 설정한다. 

  • (3) 성능 테스트를 위한 시나리오를 생성한다. 

    • 테스트 목적에 맞는 Load Type, 파라미터, 사용자 수, Ramp-up load, Periodic load, 수 행 시간, 모티터링 결과 장 파일 등의 정보를 설정한다. 

  • (4) 시나리오를 실행하면서 테스트 상황을 모니터링한다. 

    • 성능 테스트를 수행하면서 테스트 상황을 도구를 통해 모니터링한다

 

[4] 성능 테스트 결과 분석을 통해 성능 저하 요인 발견

• 애플리케이션의 성능 테스트 결과를 분석하여 성능 저하 요인을 발견한다. 

• 1. 애플리케이션의 성능 테스트 결과를 분석한다. 애플리케이션 성능 목표 대비 결과를 분석한다. 

  • (1) 사용자 수 증가에 따른 트랜잭션 성공 비율에 대해 추이를 분석한다. 

  • (2) TPS, 응답 시간에 대해 분석한다. 

  • (3) 시스템 자원 사용률에 대해 분석한다. CPU 사용률, 메모리 사용률, DB 사용률에 대해 분석한다. 

• 2. 애플리케이션의 성능 저하 요인을 발견하고, 분석한다. 응답 시간이 목표 이하로 발생되는 애플리케이션의 성능 저하 요인을 분석한다. 

  • (1) 애플리케이션 성능 부하 테스트 분석 결과에서 성능 저하 요인을 발견한다. 

    • 각 애플리케이션별 가상 사용자, TPS, 목표 TPS, 응답 시간 평균, 응답 시간 90% 등의 데이터에서 목표를 달성하지 못한 애플리케이션을 발견하고, 저하 요인을 분석한다. 

  • (2) 응답 시간 측정 및 분석 결과에서 성능 저하 요인을 발견한다. 

    • 대상 업무별 응답 시간 평균, 응답 시간 90% 측정 결과 성능 목표 미달성 애플리케이 션의 성능 저하 요인을 분석한다. 

 

• (3) 장애 또는 성능 저하 요인에 대해 원인을 분석한다. 시스템 장애, 응답 시간 저하 등의 원인에 대해 분석한다. 

 

 

[애플리케이션 성능 개선]

 

[1] 소스 코드 최적화의 이해

• 소스 코드 최적화는 읽기 쉽고 변경 및 추가가 쉬운 클린 코드를 작성하는 것으로, 소스 코드 품질을 위해 기본적으로 지킬 원칙과 기준을 정의하고 있다. 

• 1. 나쁜 코드(Bad Code) 

  • (1) 개요 

    • 다른 개발자가 로직(Logic)을 이해하기 어렵게 작성된 코드이다. 대표적인 사례로 처리 로직의 제어가 정제되지 않고 서로 얽혀 있는 스파게티 코드, 변수나 메소드에 대한 이름 정의를 알 수 없는 코드, 동일한 처리 로직이 중복되게 작성된 코드 등이 있다.

  • (2) 문제점 

    • 스파게티 코드의 경우 잦은 오류가 발생할 가능성이 있다. 소스 코드 이해가 안 되어 계속 덧붙이기할 경우 코드 복잡도가 증가한다. 

• 2. 클린 코드(Clean Code) 

  • (1) 개요 

    • 잘 작성되어 가독성이 높고, 단순하며, 의존성을 줄이고, 중복을 최소화하여 깔끔하게 잘 정리된 코드를 말한다. 

  • (2) 효과성 

    • 중복 코드 제거로 애플리케이션의 설계가 개선된다. 가독성이 높으므로 애플리케이션의 기능에 대해 쉽게 이해할 수 있다. 버그를 찾기 쉬워지며, 프로그래밍 속도가 빨라진다.

 

[2] 소스 코드 품질 분석 도구의 이해

• 소스 코드에 대한 코딩 스타일, 설정된 코딩 표준, 코드의 복잡도, 코드 내에 존재하는 메 모리 누수 현황, 스레드의 결함 등을 발견하기 위하여 사용하는 분석 도구이며, 정적 분석 도구와 동적 분석 도구가 있다.

• 1. 정적 분석 도구

  • 작성된 소스 코드를 실행시키지 않고, 코드 자체만으로 코딩 표준 준수 여부, 코딩 스타일 적정 여부, 잔존 결함 발견 여부를 확인하는 코드 분석 도구이다. 

    • (1) 정적 분석 도구의 유형 

      • 사전에 결함을 발견하고 예방하는 도구, 코딩 표준 준수 여부를 분석하는 도구, 소스 코드의 복잡도를 계산하는 도구 등이 있다. 

• 2. 동적 분석 도구 

  • 애플리케이션을 실행하여 코드에 존재하는 메모리 누수 현황을 발견하고, 발생한 스레드의 결함 등을 분석하기 위한 도구이다. 

 

[수행-애플리케이션 성능 개선하기]

[1] 애플리케이션 성능 개선 방안 검토. 

• 성능 테스트 결과를 분석하고, 성능 저하 요인별 성능 개선 방안을 계획한다. 

• 1. 성능 저하 요인별 성능 개선 방안을 검토한다. 

  • (1) DB 연결 및 쿼리 실행 단계의 성능 개선 방안을 검토한다. 

    • DB Lock, 불필요한 DB Fetch, 네트워크 연결 오류 등에 대해 성능 개선 방안을 검토한다.

  • (2) 메모리 누수, 아키텍처 조정, 호출 순서 변경, 동기화 등 내부 로직 변경으로 인한 성능 개선 방안을 검토한다

• 2. 애플리케이션 성능 개선 계획서를 작성한다.

  • (1) 성능 개선 계획서의 필수 항목을 결정한다. 성능 개선 개요, 성능 개선 수행 전략, 성능 개선 수행 일정 및 절차, 성능 개선 수행 방안에 대해 설정한다. 

  • (2) 선정된 항목을 토대로 성능 개선 계획서를 작성한다.

 

[2] 코드 최적화 기법을 통한 성능 개선 방안을 작성한다.

• 나쁜 코드 형식으로 작성된 소스 코드를 클린 코드로 수정하여 성능을 개선할 수 있는 다 양한 방안에 대해 검토하고 정리한다. 

• 1. 클린 코드를 작성하기 위한 원칙에 대해 파악한다. 클린 코드의 작성 원칙에 대해 파악하고 아래의 원칙에 대해 정의한다.

  • (1) 가독성 

    • 누구든지 읽기 쉽게 코드를 작성한다. 

  • (2) 단순성 

    • 소스 코드는 복잡하지 않고 간단하게 작성한다.

  • (3) 의존성 

    • 다른 모듈에 미치는 영향을 최소화하도록 작성한다. 

  • (4) 중복성

    • 중복을 최소화할 수 있는 코드를 작성한다.

  • (5) 추상화 

    • 상위 클래스/메소드/함수를 통해 애플리케이션의 특성을 간략하게 나타내고, 상세 내용 은 하위 클래스/메소드/함수에서 구현한다. 

 

[3] 클린 코드 작성 원칙

• 가독성 

  • - 이해하기 쉬운 용어를 사용한다. 

  • - 코드 작성 시 들여쓰기 기능을 사용한다. 

• 단순성 

  • - 한 번에 한 가지 처리만 수행한다. 

  • - 클래스/메소드/함수를 최소 단위로 분리한다. 

• 의존성 

  • - 영향도를 최소화한다. 

  • - 코드의 변경이 다른 부분에 영향이 없게 작성한다. 

• 중복성 

  • - 중복된 코드를 제거한다. 

  • - 공통된 코드를 사용한다. 

• 추상화 

  • - 클래스/메소드/함수에 대해 동일한 수준의 추상화를 한다. 

  • - 상세 내용은 하위 클래스/메소드/함수에서 구현한다. 

 

• 2. 소스 코드 최적화 기법의 유형에 대해 파악한다. 

  • 클래스/메소드의 분할, 배치, 느슨한 결합(Loosely coupled), 다형성, 코딩 작성 표준 준수, 좋은 이름 사용, 적절한 주석문 사용 등에 대해 파악하고 정리한다. 

    • (1) 클래스 분할 배치 기법을 파악한다. 

      • 클래스는 하나의 역할, 책임만 수행할 수 있도록 응집도를 높이고, 크기를 작게 작성 한다. 

    • (2) 느슨한 결합(Loosely Coupled) 기법을 파악한다. 

      • 클래스의 자료 구조, 메소드를 추상화할 수 있는 인터페이스 클래스를 이용하여, 클래 스 간의 의존성을 최소화해야 한다. 

    • (3) 코딩 형식 기법을 파악한다. 

      • 줄바꿈으로 개념을 구분, 종속(개념적 유사성 높음) 함수를 사용, 호출하는 함수를 먼 저 배치하고 호출되는 함수는 나중에 배치, 변수 선언 위치를 지역 변수는 각 함수 맨 처음에 선언할 때 사용하는 등의 형식을 취한다.

    • (4) 좋은 이름 사용 방법을 파악한다. 

      • 기억하기 좋은 이름, 발음이 쉬운 용어, 접두어 사용 등 기본적인 명명 규칙(Naming Rule)을 정의하고 정의된 이름을 사용한다. 

    • (5) 적절한 주석문 사용 방법을 파악한다. 

      • 소스 코드 작업 시 앞으로 해야 할 일을 기록하거나, 소스상의 중요한 부분을 강조할 때 사용한다.

• 3. 소스 코드 최적화 기법을 통해 애플리케이션의 성능을 개선한다. 

  • 애플리케이션 개발 프레임워크의 코딩 표준을 설정하고, 인터페이스 클래스를 이용하여 느슨한 결합(Loosely coupled) 코드를 구현한다. 

  • (1) 통합 개발 프레임워크 Eclipse의 JAVA Code Style의 Formatter를 설정한다.

• (2) 인터페이스를 통해 추상화된 자료 구조를 구현하여 의존성을 최소화한다.

 

[3] 아키텍처 조정을 통한 성능 개선 방안을 작성한다

• 소프트웨어 아키텍처 기법 중 사용자 화면 계층(User Interface Layer)의 Spring MVC의 구 조 및 각 컴포넌트에 대해 파악하고, 아키텍처 기법인 생성과 사용의 분리 작업을 통해 애플리케이션의 성능을 개선한다. 

• 1. Spring MVC(Model View Controller)의 구조와 각 컴포넌트의 역할에 대해 조사하고 정리한다. 

  • (1) Spring MVC(Model View Controller)의 구조 및 동작 순서에 대해 정리한다.

• (2) Spring MVC의 각 컴포넌트에 대해 정리한다. 

  • (가) DispatcherServlet(디스패처 서블릿) 

    • Spring MVC 프레임워크의 Front Controller, 웹 요청과 응답의 수명주기(Life Cycle) 를 주관하는 컴포넌트이다. 

  • (나) HandlerMapping(핸들러매핑)

    • 웹 요청 시 해당 URL에 매핑되는 컨트롤러를 검색, 결정하는 컴포넌트이다.

  • (다) Controller(컨트롤러) 

    • 비즈니스 로직을 수행하고 결과를 ModelAndView에 반영하는 컴포넌트이다. 

  • (라) ModelAndView 

    • 수행 결과와 반영하는 모델 데이터 객체, 이동할 페이지 정보 및 뷰로 이루어져 있다. 

  • (마) View Resolver(뷰 리졸버) 

    • 결과를 표시할 어떤 뷰를 선택할지 결정한다. 

  • (바) View 

    • 결과 데이터인 모델 객체를 표현(Display)한다

• 2. 아키텍처 조정을 통한 성능 개선 방안을 수행한다. 

  • 객체의 생성과 사용을 분리함으로써 소프트웨어의 의존성을 최소화하기 위하여 팩토리 메소드(Factory Method) 패턴을 이용하여 성능 개선 방안을 수행한다. 

 

[4] 프로그램 호출 순서 조정을 통한 성능 개선 방안 작성

• 서로 연관된 내용은 세로로 가깝게 작성함으로써 밀집도를 높이고, 유사성이 높은 함수나 코드끼리 가깝게 배치한다. 또한 호출하는 함수를 먼저 작성하고, 호출되는 함수는 나중에 배치한다. 

• 1. 프로그램 호출 순서를 조정하여 성능 개선 방안을 수행한다. 호출하는 함수를 먼저 코딩하고, 호출되는 함수는 나중에 배치하여 애플리케이션의 성능을 개선한다.

 

[5] 소스 코드 품질 분석 도구를 활용하여 애플리케이션 성능 개선.

• 1. 메모리 사용 최소화를 통해 성능을 개선한다. 

  • (1) String 클래스를 StringBuffer 또는 StringBuilder 클래스로 수정하여 코딩한다. 

    • String 클래스는 연산 시마다 new 객체를 생성하여 Heap 메모리 사용량이 증가함에 따라 속도 저하의 가능성이 있지만, StringBuffer 또는 StringBuilder 클래스가 기존 객 체의 크기를 증가시키면서 이를 처리한다. 

  • (2) 루프 내 불필요한 메소드의 호출이 반복되지 않도록 코딩한다. 

    • 루프 내에서 메소드(함수)의 호출이 반복되는 코드를 루프 진입 전에 호출하도록 소스 코드를 수정하여 성능을 개선한다. 

• 2. 입출력 발생 최소화를 통하여 성능을 개선한다. 문자 입력 스트림 또는 파일 정보를 읽어올 때 버퍼(Buffer)를 사용하거나, BufferedReader를 사용하여, 입출력 발생 최소화를 통해 애플리케이션 성능을 개선한다.

• 3. System.out.println()을 사용하지 않음으로써 성능을 개선한다. 파일, 콘솔에 로그를 남기면 애플리케이션 대기 시간이 발생된다. 이에 대응하여 Log4j 로 거를 사용함으로써 성능을 개선한다.

 

[6] 애플리케이션 성능 현황 관리

• 1. 성능 현황판(Q-Board)을 작성한다. 

  • (1) 성능 테스트 수행 단계를 기록한다. 

    • 성능 테스트 계획, 성능 테스트 수행 단계, 성능 개선 단계로 나누어 기록한다. 

  • (2) 업무 기능별로 할 일, 진행 중, 완료 항목을 준비한다. 

    • 수행 단계의 업무 기능별로 앞으로 테스트를 수행할 단위 업무명, 현재 진행 중인 테스트 단위 업무명, 이미 테스트를 완료한 단위 업무명을 작성한다. 

  • (3) 성능 테스트 단계와 각 업무 기능별 매트릭스를 작성한다. 

    • 가령 ‘xx응용체계 개발 프로젝트’의 성능 테스트를 진행한다 했을 때, 테스트 대상 을 건강/인사관리, OO관리, 교육훈련관리, 종합OOO 등 업무 기능별로 나누고 할 일, 진행 중, 완료 항목에 접착 메모지 등을 이용하여 기록하고 관리한다. 

  • (4) 소멸 차트를 작성한다. 

    • 가로축은 날짜를 기록하고, 세로축은 남은 작업량을 기록하여 정해진 날짜가 되었을 때 남은 작업량이 0이 되도록 관리한다. 

• 2. 성능 현황판을 이용하여 애플리케이션 성능을 개선한다. 성능 관리자는 성능 현황판을 이용하여, 성능 테스트 분석 결과 및 성능 저하 원인을 개 발자에게 전달함으로써 애플리케이션 성능을 개선하도록 관리한다.  

 

[연습문제]

• 애플리케이션의 성능을 측정하기 위한 지표가 잘못된 것은?

  • (1) 처리량(Throughput) : 애플리케이션이 주어진 시간에 처리할 수 있는 트랜잭션의 수로, 웹 애플리케이션의 경우 시간당 페이지 수로 표현하기도 한다. 

  • (2) 응답 시간(Response Time) : 사용자 입력이 끝난 후, 애플리케이션의 응답 출력이 개시될 때까지의 시간으로, 웹 애플리케이션의 경우 메뉴 클릭 시 해당 메뉴가 나타나기까지 걸리는 시간을 말한다. 

  • (3) 경과 시간(Turnaround Time)  : 애플리케이션에 사용자가 요구를 입력한 시점부터 트랜잭션 처리 후 그 결과의 출력이 시작할 때까지 걸리는 시간을 말한다. 

  • (4) 자원 사용률(Resource Usage) : 애플리케이션이 트랜잭션 처리하는 동안 사용하는 Cpu 사용량, 메모리 사용량, 네트워크 사용량을 말한다

• 클린 코드 작성 원칙이 잘못된 것은?

  • 1)가독성 

    • - 이해하기 쉬운 용어를 사용한다. 

    • - 코드 작성 시 들여쓰기 기능을 사용한다. 

  • 2)단순성 

    • - 한 번에 한 가지 처리만 수행한다. 

    • - 클래스/메소드/함수를 최소 단위로 분리한다. 

  • 3)의존성 

    • - 영향도를 최대화한다. 

    • - 코드의 변경이 다른 부분에 영향이 없게 작성한다. 

  • 4)중복성 

    • - 중복된 코드를 제거한다.

    • - 공통된 코드를 사용한다. 

 

 참고 문헌

[논문]

• 없음

[보고서]

• 없음

[URL]

• 없음

 

 문의사항

[기상학/프로그래밍 언어]

• sangho.lee.1990@gmail.com

[해양학/천문학/빅데이터]

• saimang0804@gmail.com

 

 

 

 

 

 

 

 

 

 

 

본 블로그는 파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있음