1.디자인 패턴 꼭 써야 한다
2.도대체 GC는 언제 발생할까?
3. 내가 만든 프로그램의 속도를 알고 싶다
* APM (Application Performance Management) Tool (운영용)
> 장애상황 모니터링이 주목적
: 서버 사용자 수 or 리소스 모니터링
: 실시간 모니터링
> 프로파일링 툴에 비해 가격이 비싸다
: 보통 CPU 수를 기반으로 가격 책정
* Profiling Tool (개발용)
> 소스 레벨 분석
: App 내 세부 응답시간 분석 (Method or Line 단위, 실제 소요시간, CPU 시간, 대기시간)
- 실제 소요시간 (Clock Time) = CPU 시간 + 대기 시간
: 메모리를 object, class, line 단위로 분석 가능 (for Memory leak)
> APM 대비 저렴하다
: 사용자 수 기반으로 가격 책정
* 성능측정용 라이브러리
> JMH (Java Microbenchmark Harness)
: Open JDK 에서 만든 라이브러리
> Caliper
> JUnitPerf
> JUnitBench
> ContiperF
4. 왜 자꾸 String을 쓰지 말라는 거야?
5. 어디에 담아야하는지....
6. 지금까지 사용하던 for 루프를 더 빠르게 할 수 있다고 ?
* Loop 성능 개선
> for (int i = 0; i < v.size(); i++)
: 매 Loop 마다 v.size() 를 호출하여 비효율적이다. size 변수를 이용하거나 For-each 를 사용하는 것이 좋다
> Loop 내에 불필요한 Code 는 제거하는 것이 좋다
* 조건문
> 내부를 empty block 으로 두는 경우, Compiler 에 따라서 해당 조건문을 아예 무시해버리는 경우가 있을 수 있다
7. static 제대로 한번 써 보자
* Static
> Heap 이 아닌 Method Area 에 저장됨
: GC 에 의해 정리되지 않으므로 Memory Leak 을 주의해야 한다
8. 클래스 정보 어떻게 알아 낼수 있을까?
* Class 의 Meta Data 정보
> JVM 의 Perm 영역에 저장
* instance of 와 Reflection
> Reflection 이 더 느리다
9. synchronized는 제대로 알고 써야 한다.
* 동기화
> 동기화를 적절하기 사용하지 않는 경우 성능이 악화된다
> 자바에서는 아래 항목들을 제공한다
: Lock
: Executors
: Concurrent Collection
: Atomic Variable
10. I/O에서 발생하는 병목현상
* 기존 Java I/O (~ Java 3)
1. App -> JVM
2. JVM -> OS Kernel
3. OS Kernel -> Disk
: Disk 내용을 Kernel Buffer 에 Copy
4. OS Kernel -> JVM
5. JVM -> App
> 2~4 과정에서 대기시간이 발생한다
* NIO (New Java I/O; Java4 ~)
> Buffer 도입
> Channel 도입
> 문자열의 encoder, decoder 도입
> Perl 스타일의 정규 표현식에 기초한 패턴 매칭 방법 제공
> 파일을 잠그거나 Memory 맵핑이 가능한 File Interface 제공
> 서버를 위한 복합적인 Non-blocking I/O 제공
* ByteBuffer.allocateDirect()
> OS Memory 에 할당된 메모리를 natvie 한 JNI로 처리하는 DirectByteBuffer 객체 생성
: DirectByteBuffer 클래스의 생성자에는 Bits.reserveMemory() 를 호출하여 JVM 에 할당되어 있는 메모리보다
더 많은 메모리를 요구하는 경우, System.gc() 를 호출하도록 되어 있다
(따라서, 이 객체를 이용하는 경우 신중해야 한다)
* 파일 처리 응답 속도 비교
> 10MB 파일 처리 시,
: (Fast) OS Memory (FileChannel.transferTo()) 사용 < MappedByteBuffer < BufferedReader (Slow)
11. 로그는 반드시 필요한 내용만 찍자
* Log 최적화
> Level 을 활용하여 필요한 Log 만 찍는다
: (High Risky) SERVERE > WARNING > INFO > CONFIG > FINE > FINGER > FINEST
> e.printStackTrace() -> e.getMessage() 로 대체
12. JSP와 서블릿, Spring에서 발생할 수 있는 여러 문제점
* JSP include 기능
> Life Cycle 중 JSP 페이지 번역 및 Compile 단계에서 필요한 JSP 를 읽어서 메인 JSP의 자바 소스 및 class 에 포함시키는 방식
> 정적방식 (Fast)
: <%@include file = "relative URL" %>
> 동적방식 (Slow)
: <jsp:include page = "relative URL" />
* Java Beans
> 과다하게 성능에 영향을 미침
: TO (Transfer Object) 패턴 검토가 필요
* Tag Library
> 대용량의 Data 를 사용할때는 사용 자제
* Spring Framework 의 Core 기술
> Dependency Injection
> Aspect Oriented Programming
> Portable Service Abstraction
13. DB를 사용하면서 발생 가능한 문제점들
* DB 성능 향상 방법
> Close 잘하기
: ResultSet -> Statement -> Connection
> setAutoCommit() 은 필요한 경우에만 사용
> 배치성 작업은 executeBatch() 사용
> 한번에 가져오는 열의 개수가 정해져 있을 때는 setFetchSize 사용
> AutoClosable Interface (Java 7 ~)
: try-with-resources 문장으로 관리되는 객체에 대해서 자동적으로 close() 처리
14. XML과 JSON도 잘 쓰자
* XML (eXtensible Markup Language)
> 누구나 Data 의 구조를 정의하고 그 정의된 구조를 공유하므로써 일관된 데이터 전송 및 처리를 할 수 있다
* Markup Language
> 태그 기반의 Text 로 된 언어
* JAXP (Java API for XML Processing)
> 자바에서 XML Parsing 을 위해 제공
> SAX, DOM, XSLT (Xml Stylesheet Language for Transformations) 에서 사용하는 기본 API 를 제공
* SAX (Simple API for XML)
> 각 XML 의 노드를 순차적으로 처리
> 메모리 적재 사용
* DOM (Document Object Model)
> 모든 XML 을 읽어 Tree 를 만든 후 처리
> 메모리를 많이 사용
> 노드 추가/수정/삭제 쉬움
* JSON Parser
> JackJSON, google-gson
* SAX vs DOM vs JacksonJSON
> 응답속도&메모리
: (Fast) JaksonJSON < SAX < DOM (Slow)
> JSON 데이터는 Serialization & Deserialization 성능이 좋지 않음
15. 서버를 어떻게 세팅해야 할까?
* 서버 설정
> Apache Web Server
: MPM (Multi-Processing Module) 설정
> Web Server
: Keep Alive 설정
> DB Connection Pool 및 Thread 개수
> WAS 인스턴스 개수 설정
> Session Timeout 설정
16. 안드로이드 개발하면서 이것만은 피하자.
* Android 빌드 과정
> Java code -> (javac 명령 : compile) -> Java Byte code -> (dex compiler : compile) -> Dalvik Byte code
> 가상 메모리를 제공하지 않는다
* Android 성능 향상 팁
> String -> StringBuilder/StringBuffer 를 사용
> Integer -> int 배열을 사용
> 다차원 배열 -> 1차원 배열
> static 을 적절히 사용
> 상수는 static final 사용
: static 으로 선언할 때와 다르게 저장 및 참조 위치가 달라진다
> class 내부에서 getter 및 setter 사용을 피하자
> for-each 가 for loop 보다 빠르다 (단, ArrayList 는 전통 Loop 가 더 빠르다)
> Inner Class 에서 Outer Class 의 private member 접근을 피하자
: Compiler 가 자동으로 getter, setter 메서드를 생성한다 (즉, 속도가 느리다)
> 소수점 연산을 피하자
: 사용하더라도 double 대신 float 사용
> 제공되는 Library 를 잘 활용하자
> System.arrayCopy() 를 이용하라
* 분석 Tool
> adb
: Android Device <-> PC 간 연동을 돕는 툴
> DDMS (Dalvik Debug Monitor Server)
: adb 를 통해서 안드로이드 기기와 상호작용하는 정보를 그래픽 UI로 나타냄
> LogCat
: 로그 확인 툴
> Lint
: 정적으로 코드를 분석하는 툴
> Hierarchy Viewer
: UI 의 레이어 처리 시에 발생하는 성능 저하를 확인할 수 있는 툴
> Traceview
: 앱의 성능 저하가 발생하는 부분이 어디인지를 확인할 수 있는 툴
> dmtracedump
: 호출 관계를 그림으로 보여줌
> systrace
> Tracer for Open GL ES
: ES (Embedded System) 을 위한 Open GL 을 프로파일링 하는 툴
> Monkey
: Stress Test 툴
> Uiautomator
: UI 자동화 테스트를 쉽게 수행할 수 있도록 도와주는 툴
> ProGuard
: unused class, variable, method 등을 제거하는 기능 제공
: decompile 을 어렵게 해준다
> Zipalign
: apk 파일의 크기를 효과적으로 줄여주고, 압축되지 않은 이미지 및 원본 파일들을 최적화한다
17. JVM은 도대체 어떻게 구동될까?
18. 도대체 GC는 언제 발생할까?
19. GC 튜닝을 항상 할 필요는 없다.
* GC 분석 Tool
> jvmstat
: Sun 에서 제공하는 무료 툴
- jps : JVM 프로세스의 목록을 보여주는 툴
- jstat : JVM 통계 수치를 모니터링하는 툴
- jstatd : 원격으로 JVM 을 모니터링하기 위해 사용
> Java 수행 시, -verbosegc 옵션 사용
> GC Analyzer
: Sun 에서 제공하는 GC 분석 툴
> Visual GC
* GC 튜닝
> 필요한 경우에만 하고 최적의 안을 찾아야 한다
1. GC 상황 모니터링 및 결과 분석
2. GC 방식 지정 + 메모리 크기 설정
: JVM 시작 시 Heap 영역 크기 (-Xms)
: 최대 Heap 영역 크기 (-Xmx)
: New 영여과 Old 영역의 비율 (-XX:NewRatio)
: New 영역의 크기 (-XX:NewSize)
: Eden 영여고가 Survivor 영역의 비율 (-XX:SurvivorRatio)
3. GC 튜닝 및 결과 분석
* Heap Size 에 따른 GC 성능
> Heap 이 크면
: GC 의 횟수가 감소하지만 수행시간이 길어진다
> Heap 이 작으면
: GC 의 횟수가 증가하지만 수행시간이 짧아진다
20. 모니터링 API인 JMX
* JMX (Java Management eXtension)
> 자바 기반의 모든 App 을 모니터링하기 위해 만든 기술
21. 반드시 튜닝 해야 하는 대상은?
> 자주 이용되는 화면
22. 어떤 화면이 많이 쓰이는지 알고 싶다.
* Web Log (= Access Log)
> 서버에 어떤 사용자가 어떤 요청을 하였고, 그 결과는 어떠한지를 파일에 한줄씩 쌓아준다
> Tool 종류
: Analog, AWStats, Webalizer
23. 튜닝의 절차는 그때 그때 달라요.
* Amdahl (암달) 의 법칙
> 1 core 에서 20시간 소요되는 작업 중 1시간은 절대 개선할 수 없다면, 20배이상의 성능 향상은 불가능하다
> 성능개선율 = 1 / ((1-p) + p/s)
: P = 개선 가능한 비율 (0~1)
: S = 개선된 정도
* 성능 튜닝 절차
1. 원인 파악
2. 목표 설정
3. 튜닝 실시
4. 개선율 확인
5. 결과 정리 및 반영
24. 애플리케이션에서 점검해야 할 대상들
* 패턴과 아키텍처는 잘 구성되어 있는가?
> 과다한 패턴 사용 지양
> 데이터 전송을 위해 TO 패턴을 사용하였는가?
> Look up 작업 시, Service Locater 패턴을 사용했는가?
* 기본적인 App 코딩은 잘 되어 있는가?
> 명명 규칙을 잘 지켰는가?
> 필요한 부분에 예외처리는 되어 있는가?
> 예외화면은 지정되어 있는가?
> e.printStackTrace() 는 필요한 경우에만 사용
> System.gc() 메소드가 소스에 포함되어 있지 않은가?
> System.exit() 메서드가 소스에 포함되어 있지 않은가?
> 문자열을 계속 더하는가?
: Java 5 이상에서는 자동으로 StringBuilder 로 변환해준다
(Loop 안에서 더하지 않도록 주의)
> StringBuffer 나 StringBuilder 클래스도 제대로 사용했는가?
: 잘못된 사용의 예 - sb.append("AAA" + "BBB")
> 무한 루프가 작동할만한 코드가 없는가?
> static 을 남발하지 않았는가?
> synchronized 는 필요한 경우에만 사용한다
> 불필요한 I/O 를 줄인다
> 불필요한 로그 제거를 하거나, 로그 레벨을 적절히 설정한다
> Debug 를 위한 System.out.println() 제거
* Web 관련 코딩은 잘 되어 있는가?
> JSP 의 include 는 동적으로 했는가? 아니면 정적으로 했는가?
> Java Beans 는 너무 많이 사용하지 않았나?
> Tag Library 는 적절하게 사용했나?
> EJB 는 적절하게 사용했나?
> 이미지 서버를 사용할 수 있는 환경인가?
> 사용중인 프레임워크는 검증 되었는가?
* DB 관련 코딩은 잘 되어 있는가?
> 적절한 JDBC 드라이버를 사용하는가?
> DB Connection, Statement, ResultSet은 잘 닫았는가?
> DB Connection Pool 은 잘 사용하고 있는가?
> 자동 commit 모드에 대한 고려는 하였는가?
> ResultSet.last() 메서드를 사용하였는가?
: 응답시간이 느려짐
> Prepared Statements 를 사용하였는가?
: 동적으로 변경이 필요한 경우를 제외하고 사용하기를 권장
(Query 수행시마다 SQL query 를 compile 하는 것은 DB 에 부하를 줌)
* 서버의 설정은 잘 되어 있는가?
> 자바 VM 관련 옵션들은 제대로 실행되어 있는가?
> 메모리는 몇 MB 로 설정해 놓았는가?
> GC 설정은 어떻게 되어 있는가?
> 서버가 운영모드이지 개발모드인지 확인하였는가?
> WAS 의 인스턴스가 몇 개 기동되고 있는가?
> JSP precompile 옵션은 지정해 놓았는가?
> DB connection pool 개수와 스레드 개수는 적절한가?
> Session Time out 시간은 적절한가?
> 검색 서버에 대한 설정 및 성능 테스트를 하였는가?
* 모니터링은 어떻게 하고 있는가?
> Web Log 는 남기고 있는가?
> verbosegc 옵션은 남기고 있는가?
> 각종 로그 파일에 대한 규칙은 있는가?
> 서버 시스템 사용률은 로그로 남기고 있는가?
> 모니터링 툴은 사용 중인가?
> 모니터링 툴에 대한 설정은 적절하게 되어 있는가?
> 서버가 갑자기 Core Dump 를 발생시키지 않는가?
> 응답시간이 너무 느리지 않은가?
* 이미지 출처 : http://blog.daum.net/creazier/
'SW > SW 서적' 카테고리의 다른 글
| ★ 안드로이드 앱 성능 최적화 / 더그 실라스 / 로드북 (0) | 2020.03.08 |
|---|---|
| 완벽한 IT 인프라 구축을 위한 Docker / Asa Shiho / 정보문화사 (0) | 2020.01.13 |
| ★ 안드로이드 비동기 프로그래밍 / 스티브 릴리 / 에이콘출판 (0) | 2019.09.29 |
| ★ 인프라 엔지니어의 교과서 / 사노 유타카 / 길벗 (0) | 2019.08.12 |
| ★ Efficient Android Threading / 안데르스 에란손 / 한빛미디어 (0) | 2019.08.11 |