왜?
성능테스트를 하면서 많은 시간과 에너지를 소진했다. 힘겹게 마무리를 하고 난 시점에 우연히 책장에서 책을 발견했다. 15년 전 책이 아직도 있었네. 그런데 혹시 내가 놓친 것은 없었을까? 궁금한 마음에 보게 되었다.
후기
- 밑줄 그어 놓은 것들을 보니 당시에 책을 읽으면서 가졌던 생각들이 떠오른다. 15년 전 책이지만, 여전히 유용한 부분들이 있었다.
- 쓰지 말아야 한다는 것은 알고 있는데, 왜 쓰지 말아야 하는지를 새롭게 알게 된 것들이 있었다. 그때는 알았겠지만, 시간이 지나 결론만 기억에 남았나 보다. 주기적으로 리마인드를 해야겠다.
- 개선율 구하는 공식을 미리 알았다면 유용하게 사용했을 텐데 아쉬웠다.
메모
Cpu 시간과 대기 시간
- 하나의 메소드, 한 라인을 수행하는데 소요되는 시간은 무조건 CPU 시간과 대기 시간으로 나뉜다.
- CPU 시간은 CPU를 점유한 시간이고, 대기 시간은 CPU를 점유하지 않고 대기하는 시간을 의미한다.
- CPU 시간과 대기 시간을 더하면 실제 소요 시간(Clock time)이 된다. CPU 시간은 툴에 따라서 스레드(thread)시간으로 표시되기도 한다.
nanoTime
- Jdk 5.0에 등장, 수행된 시간을 측정하기 위해 나옴
개선율이란
- 튜닝 전과 후의 차이를 수치로 나타낸 것이다.
- (튜닝 전 응답속도 - 튜닝 후 응답 속도) X 100 / 튜닝 후 응답 속도 = 개선율(%)
e.printStackTrace()
- 최대 100개 까지의 로그를 프린트하기 때문에 서버의 성능에도 많은 부하를 준다.
- 스택 정보를 가져오는 부분에서는 거의 90% 이상이 CPU를 사용하는 시간이고, 나머지 프린트하는 부분에서는 대기 시간이 소요된다.
XML
- XML 처리하는데 소요되는 시간 대부분은 parse() 메소드에서 처리하는 CPU 시간이다. 즉, 대기시간은 없지만, XML을 처리하는 과정에서 CPU에 순간적으로 많은 부하가 발생한다.
- SAX 파서는 XML 파일 크기의 거의 두 배의 메모리를, DOM 파서는 거의 열 배의 메모리를 사용한다.
KeepAlive On
- 웹 서버와 웹 브라우저가 연결이 되었을 때 keepAlive 기능이 켜져 있지 않으면, 매번 HTTP 연결을 맺었다 끊었다가 하는 작업을 반복한다. 즉 이미지와 같은 모든 개체들도 서버에 매번 접속을 해야 하는 상황이 발생한다.
- 하지만 이 기능이 켜져 있으면 두 개 정도의 연결을 열어서 끊지 않고, 연결을 계속 재사용한다. 이렇게 되면 연결을 하기 위한 대기 시간이 짧아지기 때문에 사용자가 느끼는 응답속도도 엄청나게 빨라진다.
서버 인스턴스
- 서버의 인스턴스를 늘리면 늘릴수록 CPU가 처리해야 하는 양은 많아진다.
- 보통은 1-2개의 CPU 당 하나의 인스턴스를 지정하는 것이 좋다고 이야기 한다.
- 경험상으로는 인스턴스 수를 증가시켜서 성능이 좋아진 경우도 있고 그렇지 않은 경우도 있었으나, 대부분 성능이 월등히 좋아지지는 않았다.
DB 병목
- DB가 병목인지 확인하기 가장 쉬운 방법은(모니터링 툴을 따로 사용하지 않고) DB Connection Pool 의 개수를 확인하는 것이다.
- 이 때 현재 처리되고 있는 스레드의 개수를 같이 확인해야 한다.
스레드
- 각 스레드에서는 스택 영역의 메모리를 점유한다.
- -Xmx나 -Xms 옵션을 지정해서 메모리를 증가시켜도 생성되는 스레드의 개수는 비슷할 것이다.
0 댓글