조대협의 블로그

항상 성능 테스트를 준비할때 마다, 어떤 부하 테스트툴을 쓰느냐가 고민이다.어느정도 틀이 갖춰진 조직이나, 예산이 충분한 경우에는 뒤도 안돌아보고 파트너 불러다가 Load Runner돌린다. 1. Load Runner국내 인력도 많고, 다양한 시나리오에 대한 부하 테스트를 안정적으로 할 수 있어서 언제나 #1 옵션이지만, 비용이 살인적이다. 2. 기타 오픈소스그래서 오픈소스를 검토해봤는데,Apache JMeter의 경우 예전에 하도 실패를 많이 했고, 테스트 중 GC 발생도 그렇고, 툴 자체가 매우 세밀하게 사용을 해야 한다. 부하 테스트 툴이라기 보다는 부하테스트 프레임웍 정도로 보는게 맞지 않을까?그 다음으로 예전에 Multimechnizer라는 툴을 고민했었는데, Erlang기반이고 Python으로..

Garbage First Collector 이하 G1 Collector는 예전에 잠깐 소개한적이 있는데, 오늘 지금 하는 프로젝트에서 메모리 관련 이슈가 있어서 잠깐 살펴보았는데, 대략 적인 원리는 다음과 같다. CMS (Concurrent Mark & Sweep)의 원리는 기존에, New 영역을 Old영역으로 보낸후에, Old 영역의 Object Tree를 Search해서 Dead Object를 Mark하고, Mark 된 Object들을 deallocate하는 방식이었다. 이 작업을 Concurrent Thread가 연속적으로 한다는 것인데, (Full GC 시간에 몰아서 하는 것이 아니라. ) G1 Collector는 메모리 구조 부터가 틀리다. New/Old 영역을 Physical하게 따로 나누지 ..

재미있는 소식이 있어서 포스팅합니다. JDK 1.6 update 14에 G1이라는 형식의 Garbage collector가 추가됩니다. 기존에 CMS (Concurrent mark and sweep)과 는 다르게, Compaction을 사용하며, 특히 주목할만한 것은 Large Memory에서 latency time을 극소화 했다는 것입니다. 쉽게 풀어서 설명하자면, 이제 GC 시간 때문에 대용량 Heap을 사용하지 못하는 일이 없어진다는 것입니다. 애플리케이션이 메모리에서 많이 자유로워 지는 것이지요... 물론 뚜껑을 열어봐야 알겠지만, CMS옵션도 1.4에 release되어 1.5에는 꽤나 쓸만한 모습을 갖춘만큼. G1 Collector도 앞으로 많은 기대가 됩니다. 참고 http://www.info..