2009년 12월 25일 금요일

[JDBC]일반 JDBC와 Oracle JDBC 성능비교(Java 배치) #2



에서는 일반 JDBCOracle JDBC간의 "조회+등록"이 함께 있는 시나리오에 대해 성능비교를 해보았다.

번에는 "조회"만 있는 경우에 대해서 성능비교를 해보면 아래와 같다.


<시나리오>
□ 100건씩 조회(rownum <=100)
□ 위 작업을 1~100,000 반복

※ 타 조건은 "성능비교 1차"와 동일


<총 소요시간(총 응답시간) 비교>










※CASE1:일반JDBC, CASE2:Oracle JDBC

<결론>
1."조회"만 있은 경우 70% 이상의 성능개선효과 발생
   o 반복횟수가 증가할수록 개선율은 낮아지지만, 최소 70%이상의 개선효과 발생

2. "조회+등록"이 있는 경우가 성능개선 효과가 더 높은 것으로 판단
   o "조회+등록" 이 있는 경우, 90%이상 성능개선효과 발생


 ※ "조회+등록" 이 있는 경우, 등록에 대한 일괄처리로 인한 성능개선효과가 크게 나타나는 것으로
      조회 부분(Parse+Fetch)에 대한 성능개선은 상대적으로 미미해 짐.
      (조회부분은 약 5% 정도만 개선)






2009년 12월 23일 수요일

[사진] Apple Team

 (출처 : flickr.com)
From Left...
Tony Fadell(engineering vice president),
Jon Rubinstein(iPod head),
Jonathan Ive(industrial design chief),
Steve Jobs(CEO),
Philip Schiller(marketing director).

최고의 멤버! 최고의 팀!
(Force가 느껴진다...그들 뒤에 있는 사무실도 예사롭지 않아 보인다.)

2009년 12월 17일 목요일

[IBM dW] 자바 EE 6에서 의존성 주입

이창신씨가  IBM developerWorks에 연재한 글이다.


J2EE6 에서의 Dependency Injection의 Spec확정에 대한 내용이며,
이를 Servlet 예제와 함께 소개하고 있다.

IoC나 AOP의 개념이 이제 J2EE에서 표준 패러다임으로서 정착해가는 느낌이다.








[FW] Application Framework in J2EE

J2EE 환경에서
Open Source Frameworks를 이용한 아키텍처 구성도(예시)

  • Presentation Tier : Struts
  • Business Tier : Spring
  • Persistence Tier : iBatis

2009년 12월 16일 수요일

[dW]7 Roles of Architect

2003.11.2 IBM developerWorks에
"아키텍트가 갖출 일곱 가지 자질 "이라는 제목으로 실렸던 글이 새삼 와 닿는다.
("Applied Software Architecture" 책의 내용을 정리한 글이다.)

이 글에서 말하는 일곱가지 자질은 아래와 같다


1. 비전 제시자(creating vision)

2. 핵심 기술 조언자(the architect as a key technical consultant)

3. 의사 결정자(The architect makes decisions)

4. 코치(The architect coaches)

5. 조정자(The architect coordinates)

6. 구현 능력(The architect implements)

7. 대변자(The architect advocates)

2009년 12월 15일 화요일

[JDBC]일반 JDBC와 Oracle JDBC 성능비교(Java 배치) #1

만약, 한 아키텍트가 JAVA로 배치 아키텍처를 제안한다면,

그 아키텍트는 대용량처리 시 응답속도에 대한 것을 포기하는 것이냐는  핀잔을 들을지도 모른다.

(아마,  JAVA가 느린것도 모르냐며 무능한 아키텍트로 낙인찍힐 수도 있다.)


하지만,  Oracle JDBC 를 이용할 경우 이야기는 달라질수 있을 듯하다.


JAVA기반의 배치프레임워크를 지원하는 상용제품(CASE1)

동일한 로직을 Oracle JDBC(CASE2)로 구현하여 총 소요시간(응답시간)을 비교하여 보면 아래와 같다.

※ 상용제품은 표준(일반) JDBC로 구현



<시나리오>

100 건 select 후 insert

    ※ 모든 SQL(select, insert SQL)문은 동일

    ※ commit 단위 : 100건

□ 위 작업을 1/10/100/1,000회 반복 수행 후 총 소요시간(응답시간) 비교



<테스트 서버환경>

□ OS : IBM AIX 5.3(64 bit)

□ CPU / RAM : 12 / 3 GB

□ Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 – 64bit

□ JVM : build 1.4.2, J2RE 1.4.2 IBM AIX 5L for PowerPC (64 bit JVM)



<설정비교>









 JDBC 각 처리단계(Parse, Execute, Fetch)별 관련 클래스 및 메소드 비교표임

※ CASE2(Oracle JDBC)의 설정값은 테스트 및 관려자료를 참고하여 결정한 수치임.



<총 소요시간(응답시간)비교>













<결론>

위와 같이 일반 JDBC와  Oracle JDBC를 이용할 경우 98% 이상의 Dramatic한 성능개선을 보였다.

 

물론, 이는 지극히 단순화된 조건하의 극단적인 비교치일 수 있다.

즉, 일반 JDBC를 이용하더라도 addBatch등을 통해 Execute 등의 속도를 높일 수는 있으니 말이다.

 

하지만 확실한 것은,

Parse, Execute, Fetch 작업이 반복될수록 Oracle JDBC의 성능개선 효과가 더 커진다는 것이다.

 

JAVA 기반에 Oracle Database만 사용하는 환경에서 대용량 배치프로그램의 속도가 고민이라면,

Oracle JDBC를 이용한 속도향상에 대해 심각히 고려해 볼 필요가 있어 보인다.


 

<추신>

1) 테스트 소스나 DB 스크립트를 개시하지 못하는점 양해바람.

  -  소스는 상용프레임워크 소스가 그대로 보이고,

  -  DB스크립트는 실제 사용테이블 명이 나타나 보안상 문제가 될수 있어 생략함.

2) 위의 비교는 상용프레임워크의 문제점에 대한 논의가 아니라

    일반 JDBC와 Oracle JDBC 비교를 위해 편의상 현재 사용중인 상용프레임워크를 사용하였을 뿐임.

3)  각자 개발이나 운영중인 환경이 있다면 

     현재 사용하고 있는 JDBC방식을 Oracle JDBC 방식으로 변경하여 비교해 볼 것을 강력히 권장함

 

※ “Pro*C와 Java와의 Batch BMT(성능비교)라는 흥미로운 글이 있어 소개한다. 

    JDBC의 addBatch를 이용해도 Pro*C보다도 빠를 수 있다는 내용이다.

    (아마 Oracle JDBC의 setExecuteBatch를 이용하였다면 더욱 높은 속도개선이  가능했을 듯 하다.)

2009년 12월 10일 목요일

[기사] 아이폰 구입하면 '매국노', 국산폰 사면 '애국자'?

오마이뉴스 김인성 기자(09.12.10 10:46)



말이 필요없다. 읽어보면 다들 공감할듯.
완전공감, 개념기사다.
김인성 기자님께 감사드린다.

아이폰으로 인해 쓰레기 같은 Active-X좀 안쓰고,
웹환경도 표준좀 지키고 다양한 browser좀 쓸 수 있기를 간절히 바랄뿐이다.
(특히, 금융권들 제발....)





2009년 12월 7일 월요일

[Java] Effective Java - Still Effective After All These Years

 

Effective Java를 쓰신 Joshua Bloch(Chief Java Architect at Google)의 강의모습이다.

Java의 기본개념에 대한 내용들을 Quiz 형식을 통해 수강자들과 소통하며 즐겁게 진행하는 모습이 인상적이다.


<추신>

그의 모습에 열정과 즐거움이 묻어나온다... Google에 다녀서 그런가? ㅋ

(이런 Guru는 어디에서 일할까 궁금했는데, 역시.....Google에 있었다! ^^)


그리고 그가 공저한 "Java Puzzlers"라는 책도 한번 읽어봐야 겠다.

 

2009년 12월 6일 일요일

[Tx.]Connection Sharing 기능

[JEUS 5.0 #23 이상 버전 patch 기능 중 Connection Sharing 기능에 대한 설명]

UserTransaction tx = new UserTransaction();
tx.begin();
Connection con1 = ds.getConnection(); //ds : DataSource
Connection con2 = ds.getConnection();
Connection con3 = ds.getConnection();
...
tx.commit();

위와 같은 Global Transaction 로직에서,
일반적인 경우, con1, con2, con3은 3개의 다른 connection 객체이다.

connection sharing이란,
동일 Global Transaction에서는 여러번 connection객체를 요청하더라도
WAS단에서 동일한 connection 객체를 리턴시켜 주는 기능이다.
즉, con1, con2, con3은 모두 1개(con1)의 동일한 connection 객체이다.

즉, 위의 Connection Sharing 기능을 어플리케이션 측면에서는
tx.begin();
Connection con1 = ds.sgetConnection();
con2=con1;
con3=con1;
tx.commit();
와 같이 Connection을 재사용하도록 코딩한 것과 같은 의미가 된다.

정리하면, Connection Sharing 기능이란,
하나의 Global Transaction에서
어플리케이션에서 명시적으로 connection 객체를 재사용하지 않더라도
WAS단에서 동일한 connection 객체를 리턴하여 공유(재사용)하도록 하는 기능이다.

[장점]
이와 같은 기능은 하나의 Global Transaction에서 빈번히 getConnection을 수행하는 어플리케이션에서는
connection open 시간이 줄어들어 전체 response time 감소한다.
(즉, XA DataSource를 이용한 다수건 connection 사용환경에서 개선효과 발생)

[단점]
하지만, 단일 connection만 이용하는 어플리케이션에서는 connection 관리기능 추가로 인한 overhead로
connection open 시간이 더 늘어나서 전체 response time 증가한다.
(즉, Non XA DataSource를 이용한 connection 사용환경에서는 역효과 발생)








2009년 12월 5일 토요일

[Books]컨설팅의 비밀



누구에게 컨설팅이라는 행위를 하기 전에 컨설턴트로서 주의해야 할 사항들에 대한 정리!
특히, 돈이라는것을 받고 누구에게 충고(?) 할때에 고려해야할 사항들!

(※ 번역문맥이 다소 읽기에 어려웠음)

[기사] 아이폰의 성공 비밀

오마이뉴스 2009.12.05 김인성 기자

휴대폰 업체 구세주', 아이폰 성공 비밀
소비자 열광시킨 '편의성'...아이디어 중심으로 '선택과 집중'




애플의성공 비결을 논리적인 어조로 잘 써내려간 기사

결국 애플의 성공비결은 창의성!

과연 우리나라에 애플이 있었으면 성공할 수 있었을까?
아마 잡스형님도 꽉꽉막힌 군대식 문화와 어설픈 권위주위때문에 결코 쉽지 않았을 것이다.

이나라 대한민국에서도 애플과 같은 회사가 없는데
아이폰과 같은 제품이 나오기를 바라는건
닭이 없는데 달걀을 기대하는 것만큼이나 어리석은 일일지도 모른다.

이이폰의 놀라운 기능들을 눈으로 직접보면서
말로만 IT선진국이라고 떠들어 대며 IT에 아무런 비전이 없는 위정자들과
강이며 땅이며 삽질할 생각에만 가득한 현정부를 보면

대한민국의 IT는 밝지만은 않아 보인다.






[Books]Effective Java(Second Edition)


Java의 기본에 대한 생각을 하게 하는 책
Java Program Performance Tuning 관련 작업 전에 한번은 읽어봐야할 내용들





[JDBC] Oracle JDBC를 이용한 성능향상 방법

1. Statement Caching

① Implicit Statement Caching

// Statement cache 사이즈를 5로 설정
((OracleConnection) conn).setStatementCacheSize(5);
// Enable Implicit caching
((OracleConnection) conn).setImplicitCachingEnabled(true);

② Explicit Statement Caching

// Statement Cache 사이즈를 5로 설정
((OracleConnection) conn).setStatementCacheSize(5);
// Enable Explicit caching
((OracleConnection) conn).setExplicitCachingEnabled(true);

 

2. Implicit Connection Caching

private static final String CACHE_NAME =“ CacheSample”;
// Datasource 초기화
OracleDataSource ods = new OracleDataSource();

// Enable caching
ods.setConnectionCachingEnabled(true);
// Set the cache name
ods.setConnectionCacheName(CACHE_NAME);

// cache, datasource, cache properties를 지정하여 새로운 cache생성
connMgr.createCache(CACHE_NAME, ods, properties);
Connection conn = ods.getConnection();

 

3. Update Batching

① Standard Update Batching

Connection conn = ds.getConnection();
conn.setAutoCommit(false);

Statement s = conn.createStatement();

s.addBatch( “insert into dept values‘ ( 26’,‘HR’,‘Mongolia’)”);
s.executeBatch();

conn.commit();
s.close();

② Oracle Update Batching

Connection conn = ds.getConnection();
conn.setAutoCommit(false);

PreparedStatement ps =
conn.prepareStatement(“ insert into dept values (?, ?, ?)”);

((OraclePreparedStatement)ps).setExecuteBatch (3);

ps.executeUpdate();
((OraclePreparedStatement)ps).sendBatch();

conn.commit();
ps.close();

 

4. Standard Fetch Size and Oracle Row Prefetching

① Standard Fetch Size

Statement stmt = conn.createStatement();
stmt.setFetchSize(100);

② Oracle Row Prefetching

((OracleConnection)conn).setDefaultRowPrefetch(7);
((OracleStatement)stmt).setRowPrefetch (2);

 

 

<출처>
2007 Spring Oracle Korea Magazine

Oracle JDBC를 이용한 성능향상 방법
저자_김정식 Oracle ACE(oramaster@empal.com)

2009년 12월 2일 수요일

[FW] 전자정부 표준Framework

행정안전부에서 2009년 6월 24일(수)에

전자정부 표준프레임워크 공개 및 활성화 계획 발표” 를 했다.

오픈소스에 기반한 표준프레임워크 발표는 긍정적인 부분이다.

 

전자정부 표준프레임워크 사이트는 http://www.egovframe.go.kr 이며,

전자정부 표준프레임워크에 포함된 오픈소스 리스트는 아래에서 확인할 수있다.

http://www.egovframe.go.kr/EgovEnvRun.jsp

 

아키텍처 구성에 대한 내용은 꼭 한번 읽어볼 필요가 있어보인다.

앞으로도 지속적으로 유지보수되고 더욱더 개선되어지길 기대한다.

 

무료교육을 통한 전파도 시도되고 있다. 기회가되면 참여하고 싶다.

 

<추신>

공공기관에 있어 표준프레임워크에 대한 시도는 분명 좋은시도이며 많은 잇점이 있을것으로 보인다.

하지만 표준이라는 이름으로 다양성이 무시되고 쏠림현항이 심화되는 부작용은 없었으면 한다.