성능 18

NoSQL IO에 대한 메모

NoSQL 하드웨어 구성에 있어서, DISK IO에 대한 메모. RAID 구성은 5가 정답 NoSQL의 N-Value를 통한 장애 대처 능력은 노드간 장애를 대처하기 위함이지, 노드의 디스크 장애 극복은 불가능함. 아주 큰 클러스터가 아니면 RAID 5가 정답, 아니면 스트라이핑 기반의 RAID 0가 정답(대규모 클러스터의 경우, 단 이 경우, 디스크 장애는 해당 노드의 장애를 의미함, 검출도 어려울듯...) IO Scheduler가 성능 튜닝 포인트라고는 하는데... 오늘 구글링에서 본 자료로는 Scheduler 바꾼다고 IO 자체 성능이 큰 차이가 없는 듯.. 이건 한번 테스트 해봐야 할듯. 결국은 네트워크 분리,캐쉬 튜닝을 어떻게 하느냐가 가능 큰 팩터가 될듯.

MS SQL 를 가상화할시(클라우드 적용시)에 고려사항(성능자료 포함)

DB를 VM에 올릴 때 첫번째로 고려할 사항은 수직적 확장성이다. 수평적인 확장성은 DBMS 자체가 제공하는 클러스터 기능을 이용해야 한다. (MS SQL의 경우 수평 확장 불가, ORACLE의 경우 RAC를 이용하여 수평확장 가능). 만약에 DBMS 자체 클러스터링에 대한 확장이 불가능하다면 애플리케이션 단에서 Database Sharding등을 이용하여 확장을 하는 안을 고려할 수 있다. 수직적 확장의 경우 현재까지 Hyper-V가 최대 CPU 4 코어까지만 지원하기 때문에, 더 이상의 용량이 필요한 경우 분리된 Physical Machine을 사용하는 방법을 사용해야 한다. DBMS를 VM에 올릴 경우 가상화에 대한 Cost로 인하여 성능이 떨어지는데, 그 중에서 성능에 가장 큰 영향을 미치는 것이..

XML 변환 성능

SOA 프로젝트를 진행하면서 가장 골치거리 중의 하나가 XML 변환에 소요되는 CPU와 응답시간이다. 통상 SOA나 요즘의 많은 Remote call들이 XML을 기반으로 하다보니, 특히나 XML 메세지 변환에 대한 요건이 많다. 자료들을 찾아보니 몇가지 흥미로운 자료들이 있는데, XSLT가 전체적으로 변환에는 가장 많이 사용되는 듯 (OSB의 경우 XQuery가 편해서 XQuery를 많이 사용하긴 하지만.)한데 그중 흥미로운것인 XSLT를 compile time에 translet이라는 것으로 변환해서 사용할 수 있는 프레임웍 http://xml.apache.org/xalan-j/xsltc_usage.html 그리고 재미있는 것중의 하나가 Intel에서 만든 XML 변환 가속기인데, Native 코드로 ..

Java File Writing 성능 비교

JAPM을 업그레이드 할까 싶어서 Log Writing 부분을 개선하고자 해서 File Writing을 어떻게 하는 것이 제일 빠를까 테스트를 해봤다. 크게 아래 케이스인데. 1. FileWriter fw = new FileWriter(LOG_HOME+"writer.log"); 2. BufferedWriter bw = new BufferedWriter(new FileWriter(LOG_HOME+"writer.log")); 3. FileOutputStream fos = new FileOutputStream(LOG_HOME+"outputstream.log"); 4. BufferedOutputStream fos = new BufferedOutputStream(new FileOutputStream(LOG_HOM..

Aspect J를 이용한 초간단 APM 만들기 (2)

JMX를 이용하여 Thread 별 CPU 시간을 측정하는 방법 == ThreadMXBean mbThread = (ThreadMXBean) ManagementFactory.getThreadMXBean(); long[] ids = mbThread.getAllThreadIds(); for (long id: ids) { System.out.println(mbThread.getThreadInfo(id).getThreadName()); System.out.println(" CPU Time(" + id+ ")" + mbThread.getThreadCpuTime(id)); System.out.println(" User Time(" + id+ ")" + mbThread.getThreadCpuTime(id)); } == ..

포탈의 성능 향상을 위한 디자인 방법

이형봉과장 아저씨 아이디어인데. 메가사이즈급 포탈을 하더니 경험이 많이 늘어나신것 같다. 포탈에서 성능상 가장 문제가 되는 부분은, 로그인 과정에서 개인화시에 컨트롤 트리 빌딩하는 과정이 많은 시간을 잡아먹게 된다. 이부분이 주요 성능 FACTOR가 되는데. 결과적으로 컨트롤 트리에 바인딩되는 컨트롤의 수를 줄이는것이 가장 키 포인트다. 다른 방법으로 접근은 컨트롤 트리란 데스크탑 단위로 렌더링이 되기 때문에, 업무 별로 데스크탑을 나누는 것이다. 여기까지는 다 아는 사실이고 업무에서 개인화를 하는 사람이 있고 하지 않는 사람이 있다. 로그인했을때 무조건 개인화 페이지를 보여주는것이 아니라, 개인화 페이지를 따로 만들어서 개인화 탭을 눌렀을때만 개인화 페이지를 보여주는 방법이다. 개인화 페이지의 구조를 ..