'자바 성능을 결정짓는 코딩 습관과 튜닝 이야기'에 해당되는 글 53건

  1. 2012.01.16 [OO 자바] 나의 네번째 책 집필 진도율 90% (1)
  2. 2011.06.13 [JCO 2011] 제니퍼도 울고갈 BTrace 교육 준비
  3. 2011.06.03 [Blog2Book] Troubleshooting 트러블 슈팅 책 링크 (1)
  4. 2011.05.25 [Blog2Book 자바 트러블 슈팅] 조만간 자바 트러블 슈팅 책이 나옵니다. (1)
  5. 2011.04.04 [Blog2Book 자바 트러블 슈팅] 원고를 넘기다.
  6. 2011.04.01 [GC] CMS 사용시 verbosegc 분석하는데 도움이 되는 자료
  7. 2010.12.21 [자바 객체의 크기] Shallow size와 Retained size
  8. 2010.08.09 [Java GC Options] 버전별 GC 옵션이 잘 정리되어 있는 페이지
  9. 2010.06.30 [Java Concurrent] 일반적으로 모르는 자바에 대한 사실들
  10. 2010.06.30 [자바 무료 프로파일링 툴] Java Free profiling tools
  11. 2010.06.29 [Profiler] 자바 메모리 할당 측정기(java-allocation-instrumenter)
  12. 2010.03.20 [Blog2Book] 자바 성능을 결정짓는 코딩 습관과 튜닝 이야기- 3쇄를 찍다. (1)
  13. 2010.01.29 [Java Profiler] 오픈소스 자바 프로파일러들 (1)
  14. 2010.01.28 [Blog2Book Test] 자바 개발자도 쉽고 즐겁게 배우는 테스트 이야기(자바 테스트 책)와 자바 성능을 결정짓는 코딩 습관과 튜닝 이야기 비교
  15. 2009.12.23 [Blog2Book Test] 이번에 나온 테스트 책과 관련된 이벤트가 진행됩니다. (2)
  16. 2009.12.22 [자바 GC] 도대체 Permanent 영역에는 어떤 놈들이 있는 것일까?
  17. 2009.10.09 [IT 서적이나 책은 어떻게 만들어 지는가? -5] 마무리하기 (1)
  18. 2009.10.08 [Tomcat] Tomcat 성능 튜닝 가이드라인 (tomcat performance tuning)
  19. 2009.10.06 [IT 서적이나 책은 어떻게 만들어 지는가? -4] 집필하기
  20. 2009.10.01 [IT 서적이나 책은 어떻게 만들어 지는가? -3] 시작하기 (2)
  21. 2009.09.29 [IT 서적이나 책은 어떻게 만들어 지는가? -2] 자료 모으기
  22. 2009.09.26 [IT 서적이나 책은 어떻게 만들어 지는가? -1] 준비하기 (4)
  23. 2009.08.06 [성능 튜닝] 고급 성능 조정의 개념
  24. 2009.06.27 [jensor] 무료 자바 프로파일링 툴 젠서
  25. 2009.06.16 [JavaOne 2009] 자바원 2009 세미나 자료들
  26. 2009.06.05 [GC] 자바의 CMS(Concurrent Mark & Sweep)을 대체할 G1
  27. 2009.06.03 [Blog2Book] 이제는 태교서적으로 분류되는구나 (3)
  28. 2009.05.29 [자바 성능을 결정짓는 코딩 습관과 튜닝 이야기] Collection 에 관하여 (1)
  29. 2009.05.25 [GC] Java GC Tuning 방법 (자바 메모리 튜닝)
  30. 2009.05.22 [Heap Dump] 자바 힙 덤프(java heap dump) 분석기 - Eclipse Memory Analyzer
지금까지 알만한 분들에게만 이야기한 지금 집필중인 책의 진척사항을 정리해보고자 한다.

현재 열심히 집필중인 "OO 자바"의 집필 진도율을 오늘 확인해 봤더니 90%다.
1월 중순이니 2월말까지 본문에 대한 집필은 끝낼 수 있을 것 같다. ㅎㅎㅎ

3월부터 두달간은 베타 리더들을 선정하여 베타리뷰 진행하고,
그 사이에 부록을 정리할 예정이다. (부록을 열심히 보는 사람은 그리 많지 않으므로. ㅎㅎ)
4월말, 5월초에 출판사에 넘기면 7월초에 나올 듯 하다.

이 글을 읽는 여러분들이 지금까지 봐 왔던 자바책과는 완전히 다른,
현업에서 꼭 필요한 주옥같은(?) 내용들만 포함되어 있는 책이라 기대해도 좋을 것이다.

마음 같아서는 모두 대박나라는 뜻에서 "대박 자바"라고 하고 싶지만,
이 책의 이름은 벌써 정해 졌다.
(7월달이면 모두 알게 되겠지만... ) 

이 책 출간이 완전히 끝나면,
잠시 쉬었다(?)가
나의 첫 책 리뉴얼에 들어갈 것이다.  
("자바 성능을 결정짓는 코딩 습관과 튜닝 이야기"의 2nd edition ... ㅎㅎㅎㅎㅎ )  
신고
Posted by tuning-java Trackback 0 : Comment 1
2011년 6월 19일에 진행되는 JCO 교육에 참석하실 분들은 아래의 가이드대로 준비한 후 교육장에 참석하셔야만 합니다. (그렇지 않으신 경우 제대로 된 교육이 진행되지 않습니다.)

1. BTrace 다운로드
아래 URL에서 본인이 지참하시는 PC의 OS에 맞는 라이브러리를 다운로드 합니다.
http://kenai.com/projects/btrace/downloads/directory/releases/release-1.2 

2. JDK 설치
Mac 사용자는 상관 없지만,
윈도우 사용자분들은 JDK를 반드시 6.0 이상 설치하셔야 하며,
C:\jdk1.6 폴더에 설치해 주시길 권장합니다.
C:\Program files 아래에 JDK를 설치하시면 실습이 매우 어려우니,
귀찮으시더라도 해당 폴더에 설치해 주시길 권장합니다.

3. 샘플 소스 다운로드
아래의 샘플 소스를 참석하실 PC에 다운로드 하셔서 갖고 오셔야만 합니다.



이렇게 필요한 파일들만 받고 설치해 주시면 교육 준비는 끝납니다.
실제 필요한 설정은 교육 시간에 진행되오니 걱정 안하셔도 됩니다.

감사합니다. 
신고
Posted by tuning-java Trackback 0 : Comment 0
"자바 개발자와 시스템 운영자를 위한 트러블 슈팅 이야기"라는 깔끔한(?) 제목의 책이 조만간 나온다. (아마도 6월 중순에는 시중에 풀릴겁니다.)

2010년 1월 3일부터 집필을 시작하여 6개월간 딴 책(안드로이드)을 쓰다가 너무 광활한 범위에 포기하고, 올해 1월부터 다시 정리하기 시작하여 집필한 책이다. 

이번 주말에 마지막 원고 리뷰 후 정리하면 6월 중순쯤 될 예정이다.

이 책의 구성은 다음과 같다.
- 웹 기반의 시스템의 장애 유형
- 쓰레드 문제와 해결 방법
- 메모리 문제와 해결 방법
- 진단을 위한 무료 툴들
- 많은 자바 개발자들이 취약한 리눅스에서 리소스를 모니터링 하는 방법
- 장애 유형에 따른 진단 절차
뭐 울트라 킹왕짱 자바 개발자 및 자바 엔지니어는 다 알고 있는 내용이므로 보실 필요는 없겠지만, 장애에 허덕이고 있는 분들은 이 책을 보면 문제 해결의 답이 보일 수도 있다.

WebTune, Jennifer, Pharos등의 APM들을 사용하는 분들이라도 그 툴들에서 잡을 수 없는 문제들을 잡는 방법이 나와 있기 때문에 분명 도움이 될 것이다. (이 툴들이 나쁘다거나 부족하다는 것은 저~~~얼대 아님) 

지금까지의 내 책들과 다르게, 출판사에서 적극적으로 내가 쓴 모든 문장을 가독성이 좋도록 바꿨기 때문에 책에 대한 가독성은 크게 문제하지 않아도 된다.

최초에 보낸 원고의 페이지는 그리 많지 않았는데, 조판 작업 후 페이지가 많아져서 부득이하게 가격은 24,000 원으로 책정했다고 한다. T T;
내가 책정한 것은 아니니 저를 원망하지는 말아주시구요~~~

아무쪼록 이 책이 장애에 허덕이고 있는 많은 개발자와 시스템 운영자 분들에게 도움이 되길 바랍니다.
 
신고
Posted by tuning-java Trackback 0 : Comment 1
작년 1월 3일부터 집필한 자바 트러블 슈팅 책의 원고를
한개 장과 부록 한개장을 제외하고 이미지까지 출판사에 넘겼습니다.

혹시나 해서 말씀드리지만, 이 책을 제대로 보시려면
"자바 성능을 결정짓는 코딩 습관과 튜닝 이야기"와
"자바 개발자도 쉽고 즐겁게 배우는 테스팅 이야기"를 함께 보셔야 됩니다. ㅎㅎㅎ

지금 안본다고 버리지 마세요...

궁금해 하실만한 목차는 책 출간 2주정도 전에 오픈할예정입니다.
(궁금해도 참으3)

출판사에서 뚜다닥 해주시면 5월말 출간(?)
약간 느려져도 상반기내에는 나올겁니다.  ㅎㅎㅎ
 
신고
Posted by tuning-java Trackback 0 : Comment 0
원문 출처 : http://www.yourkit.com/docs/95/help/sizes.jsp

번역 : 내가 했음. ㅎㅎ

Shallow size of an object is the amount of memory allocated to store the object itself, not taking into account the referenced objects. Shallow size of a regular (non-array) object depends on the number and types of its fields. Shallow size of an array depends on the array length and the type of its elements (objects, primitive types). Shallow size of a set of objects represents the sum of shallow sizes of all objects in the set.

객체의 Shallow 크기라는 것은 객체 자체가 저장되는 메모리의 양을 말하며, 참조되는 객체가 포함되지 않은다. 배열이 아닌 Shallow 크기는 해당 객체가 갖고 있는 필드의 갯수와 타입에 따라 달라진다. 배열의 Shallow 크기는 배열의 길이와 요소(객체, 기본자료형)의 타입에 의존적이다. 객체의 집합(set)에 대한 Shallow 크기는 해당 집합(set)에 있는 모든 객체의 Shallow 크기의 합을 말한다. 

Retained size of an object is its shallow size plus the shallow sizes of the objects that are accessible, directly or indirectly, only from this object. In other words, the retained size represents the amount of memory that will be freed by the garbage collector when this object is collected.

Retained 크기는 Shallow 크기 + 해당 객체에서만 직/간접적으로 접근 가능한 객체들의 shallow 크기를 말한다. 다시 말해서, retained 크기는 가비지 컬렉터에 의해서 해당 객체가 제거될 때 사라지는 메모리의 크기를 나타낸다. 

To better understand the notion of the retained size, let us look at the following examples:

retained size에 대한 보다 더 자세한 이해를 위해서 다음의 예제를 살펴보자.

In order to measure the retained sizes, all objects in memory are treated as nodes of a graph where its edges represent references from objects to objects. There are also special nodes - GC root objects, which will not be collected by Garbage Collector at the time of measuring (read more about GC roots).

retained size를 측정하기 위해서는, 메모리에 있는 모든 객체들은 그래프의 노드로 간주되며, 그것들의 edge는 객체들에서 객체들로의 참조를 나타낸다. 여기에 특별한 노드가 있는데, 이는 GC root 객체이며 이것은 측정 당시에 가비지 컬렉터에 의해서 처리되지 않는다. 

The pictures below show the same set of objects, but with varying internal references.

아래 그림을 보면 돌일한 set을 가지는 객체들이며, 내부적인 참조는 다른 상황이다.

Figure 1:
Figure 2:

Let us consider obj1.
As you can see, in both pictures we have highlighted all of the objects that are directly or indirectly accessed only by obj1. If you look at Figure 1, you will see that obj3 is not highlighted, because it is also referenced by a GC root object. On Figure 2, however, it is already included into the retained set, unlike obj5, which is still referenced byGC root.

obj1을 생각해보자.
여러분들이 볼 수 있듯이, 두 그림에서 색칠되어 있는 객체들은 obj1에서만 직/간접적으로 접근가능하다. 그림 1에서는 obj3이 색칠되어 있지 않은 것을 볼수 있다. 왜냐하면 해당 객체는 GC root 객체에서 참조하고 있기 때문이다. 그림 2에서는 obj3이 retained set에 포함되어 있다. obj5는 아직도 GC Root에서 참조하고 있는 것을 볼 수 있다.

Thus, the retained size of obj1 will represent the following respective values:

  • For Figure 1: the sum of shallow sizes of obj1obj2 and obj4
  • For Figure 2: the sum of shallow sizes of obj1obj2obj3 and obj4

따라서  obj1의 retained size는 다음의 값들을 나타낸다.
  • 그림 1 : obj1,2,4의 shallow size의 합
  • 그림 2 : obj1,2,3,4의 shallow size의 합


Looking at obj2, however, we see that its retained size in the above cases will be:

  • For Figure 1: the sum of shallow sizes of obj2 and obj4
  • For Figure 2: the sum of shallow sizes of obj2obj3 and obj4

obj2를 보자. 이 객체의 retained 크기는 
  • 그림 1 : obj2, 4의 shallow size의 합
  • 그림 2 : obj2,3,4의 shallow size의 합

In general, retained size is an integral measure, which helps to understand the structure (clusterization) of memory and the dependences between object subgraphs, as well as find potential roots of those subgraphs.

일반적으로 retained size는 integral 한 측정이며, 메모리의 구조와 객체 하위 그래프의 의존관계를 이해하는데 도움이 된다. 그리고 이러한 하위 그래프의 잠재적인 root를 찾을 수 있다.  


신고
Posted by tuning-java Trackback 0 : Comment 0
IBM 디벨롭터 웍에 좋은 글이 있어서 링크를...
글이 두개인데, 파트1은 한글, 파트2는 영어다.
제목은 "java.util.concurrent에 대해 모르고 있던 5가지 사항"

링크를 보다보니 다른 글도 있을 것 같아서 뒤져보니 다음과 같은 글들이 있다. ^^;

Java Collections API에 대해 모르고 있던 5가지 사항, Part 1
Java Collections API에 대해 모르고 있던 5가지 사항, Part 2

그 밖에 아직 번역안된 영어글들
5 things you didn't know about ... JARs

5 things you didn't know about ... Java performance monitoring, Part 1
(요 내용은 didn't know는 아닌듯 ㅋㅋ. 특히나 내책을 본 사람들에게는 ㅎㅎㅎ)
아직 8번째 글은 안썼나부다.
신고
Posted by tuning-java Trackback 0 : Comment 0
아시겠지만, 책의 쇄가 올라간다는 것은 그만큼 많이 팔려서 더 찍어 낸다는 것이다.
판이 올라가는 것은 많은 수정이 가해져서 많은 변화가 이루어 졌을 때 판 수가 증가하는 것이다.

어찌 되었든, 내 생애의 첫 출판 서적이 3쇄를 찍었다. 그것도 IT책이 ^^;
계산해 보니 6개월 만에 2쇄 찍고,
1년 6개월 만에 3쇄 찍었다.

많은 분들께 도움이 되기를...


신고
Posted by tuning-java Trackback 0 : Comment 1
블로그에 이렇게 길게 제목을 지어도 되는구나...

아는 분들은 아시겠지만, 내가 좀 집요(?)한 편이다.

다른 분들은 책을 낸 다음에 어떻게 하는지 모르겠지만,
나는 모든 포인트를 관리하는 인터넷 서점의 포인트를 정리한다.
(책이 나온지 한달, 혹은 두달 정도의 기간동안...)

출판사에 요청하면 일별 판매량 추이를 볼 수 있고,
출판사 담당자에게 물어보면, 누적 판매치를 알 수도 있지만,
내가 직접 관리하는 재미가 있다. ^^;

아래 그래프는 Yes24의 포인트 추이다.

이벤트를 걸어서 이러한 그래프가 겨우 그려진 것으로 생각하고 있다.

그래도, 튜닝책이 한달에 팔린 양보다 70%에 달하는 양이 팔렸으면 어느 정도 선방한거 아닌가? 라는 개인적인 생각이다.

왜냐면 아무도 안팔릴 거라고한 테스트 책이기 때문에.
튜닝책도 마찬가지로 몇명빼고는 안살꺼라고 했지만...




신고
Posted by tuning-java Trackback 0 : Comment 0
이번에 나온 테스트 책과 관련된 이벤트가 진행됩니다.

아이팟 타치는 제 사비를 털어서 제공해 드리는 것이고,
제가 직접 주문하여 보내드릴 예정입니다.

보통 이런 이벤트하면 약간 내부의 조작이 있다고 생각할 수도 있지만,
그러한 문제를 없애기 위해서 만약 제가 잘 아는 분이 당첨되면,
그 다음 대상분에게 드릴겁니다. ㅎㅎㅎ

단 Yes24 로 구매하실 경우에 한해서입니다.
(왜냐면 제가 다니는 회사에서 매달 Yes24 상품권을 제공해 주기 때~문에~~)

실제 링크도 이제 걸렸네요.




신고
Posted by tuning-java Trackback 0 : Comment 2
지난주에 회사에서 "GC 튜닝의 이해"라는 과정을 개설해서,
강의를 했다. 

강의 자료를 만들고 있는데,
도대체 자바의 Permanent 영역에는 정확히 어떤 놈들이 있는 것일까?
라는 의문이 생겨서 여기저기 찾아 보다가, 가장 정리가 잘 되어 있는 놈을 발견했다.

궁금하신 분들은 아래 글을 읽어보기 바란다.
http://blogs.sun.com/jonthecollector/entry/presenting_the_permanent_generation

신고
Posted by tuning-java Trackback 0 : Comment 0

이제 집필 작업의 마지막에 대해서 이야기 하겠다.


마지막 이야기를 하기 전에, 
한가지 퀴즈…

“책 한권이 나오기 전에 필자(저자)는 책을 몇 번이나 읽어볼까?”

그 답은 아래 내용에...

- 출판사로 글을 넘겨서 출판될 때까지

출판사로 글을 넘겼다고, 집필 작업이 끝나는 건 아니다.

물론 필자의 경우 출판사로 넘기기 전에 적어도 3번 이상 전체를 읽어 보면서,
문맥이 이상하거나, 오타를 수정하는 작업을 수행한다.

그리고,

아무리 여러분들이 워드에 이쁘게 작업해서 넘겼다고 하더라도,
모두 text로 변환해서 글들을 교정한 다음에 이미지와 여러 틀에 맞추어 편집작업을 한다.

교정하는 과정에서 오타나 소스를 이상하게 나열할 수도 있기 때문에,
두 세번 정도 필자가 확인작업을 수행한다.

그 다음엔 index에 넣어야 할 단어들을 표시하기 위해서 한번 더 읽는다.

그리고, 조판 들어가기 전에 마지막으로 또 한번 읽는다.

그러니까 3+3+1+1 = 8 번.. 적어도 8번 읽고, 출판사 담당자 및 교정 담당자도 몇 번씩 읽어보기 때문에, 10번 이상 읽혀진 후 출간된다고 생각하면 된다.

그렇게 보는데도, 오타가 없을 수는 없다.
(그리고, 몇번씩 읽어 본다고 하더라고, 저자에게 리뷰하라고 주는 시간이 많지는 않다.
보통 금요일 저녁에 받아서 일요일 저녁에 주고… 저녁에 받아서 다음날 아침에 주고… 뭐 그런 식이다.)

그리고, 책 중간 중간에 들어가는 삽화는 필자가 그려달라고 원고 중간중간에 표시할 수도 있고, 기획자가 알아서 그림을 추가할 수도 있다.

모든 작업이 끝나면 인쇄에 들어가는데, 인쇄 들어가면 더 이상 수정은 못한다고 한다. (2쇄 나올 때까지 오타 찍힌 책들을 팔 수밖에 없다.)

더 자세한 내용들은 출판사 업무이기 때문에, 내가 그리 잘 알지는 못한다. 더 궁금하신 분들은 출판사 직원들에게 물어보시길…


- 판과 쇄에 대하여

나도 책을 쓰기 전까지는 정확하게 잘 몰랐지만, 책이 나올때 판과 쇄라는게 있다.

보통 2nd edition, 2판으로 제목에 붙어서 책이 나오는 경우가 있다. 이렇게 제목과 내용이 많이 보완 및 upgrade되어 나오는 경우가 “판”이다.

이와는 다르게, 처음에 보통 1,000~3,000부 정도의 IT책을 찍는데, 그 찍는 단위가 쇄이다. 만약 1,000부 정도씩 찍어서 11쇄로 찍혀 있는 책을 샀다면, 그 책은 10,000 부 이상 팔린 책이라는 의미가 된다. (만약 저자의 인세가 몇 %인지 안다면, 저자가 얼마나 벌었는 지도 알 수 있다.)

그리고, 보통 쇄를 추가하는 경우는 200부 정도 남았을 때 추가한단다.(최초 부수에 따라 다르겠지만…)

참고로 내 Blog2Book 자바 튜닝 책은 출간된지 1년 반정도 된 지금 아직 2쇄라는 …
(그래도 약 7개월만에 1쇄가 다 나갔다는…)


- 증정 준비

상황에 따라, 출판사에 따라, 번역을 하거나 집필을 하면 저자에게 본인이 작업한 책을 몇권 무료로 준다.

그 내용은 계약서에도 써 있다.

번역을 하거나 감수를 할때에는 몇권 안준다. 5~10권…

집필의 경우는 약 20권정도…

그래서, 필자의 경우는 Google Docs excel에 증정 대상자 목록을 집필 시작하면서 부터 관리한다.

특히 책을 쓰는데 도움이 되었거나, 업무에 도움을 많이 주신 분들에게는 보지는 않더라도, 한권 드리면 다들 좋아 하신다. ㅋㅋ

그런데, 갑자기 책을 드려야 하는 경우가 있을 수 있다. 예를 들어 대표이사 라던지, 높은 분들에게…

그렇기 때문에 증정리스트는 3~5권정도 여유분을 가져야만 한다.


- 홍보 하기

기본적으로 홍보는 출판사에서 알아서 한다.

좋은 기획자를 만나면, 홍보도 알아서 잘 해준다. 그래서 필자의 Blog2Book 자바 튜닝 책도, 기획자가 많이 도와 줘서 마소에 인터뷰도 올려주고, 이벤트도 기획해 주었다.

저자도 그냥 있기 보다는 본인 블로그나 기타 매체에 홍보하는 것도 좋다.

필자의 경우는 (지금 회사도 작진 않지만) 전에 큰 회사에 있어서, 사내 홍보팀에 홍보를 부탁하니 회사에서 한달에 한번씩 발간하는 사보 한페이지의 1/8도 되지 않는 부분에 할애를 해 주었다.그 쪽에 잘아는 사람이 있긴 했지만, 별로 마음에 안들어서 그냥 넘어갔다.(- -) 조금만 힘좀 쓰면, 매일 아침에 하는 사내 방송에 내 보내는 것도 많은 홍보가 될 것이다.

그리고, 팀이나, 커뮤니티에서 발간하는 뉴스레터가 있다면, 그 뉴스레터에 책에 대한 소개를 올리는 것도 많은 도움이 된다.

참고로 올해 11월에 출간될 예정인 Blog2Book Test 책은 내가 받을 집필료를 할애하여 구매하신 몇 몇 분들에게 좋은 선물을 제공하는 이벤트를 진행할 예정이오니 기대하기 바란다.
그리 큰 선물은 아니지만, 그리 작은 선물도 아니다. ㅋㅋ
(상황이 어떻게 바뀔지 몰라 그 선물은 뭔지 지금 공개하진 않겠다.)


- 마음의 준비

이 연재의 마지막으로 마음의 준비에 대해서 당부 드리고 싶다.

물론 여러분들이 책을 쓴다면, 그 부수에 따라 달라지지만, 책에 대한 리뷰가 여러 곳에 등록된다. 그 중 인터넷 서점에 올라오는 글들은 유심히 보게 된다.  나도 그 리뷰 보고 책을 사기 때문에…
그리고, 그 글들은 올라가면 끝이다. 저자가 지울 수도 없다. - -;

그냥 내 책에 대해서 사람들이 어떻게 생각하는지 알고 있어야 한다는 이야기다.

추가로, 책이 나온 후부터 Google, Naver, Yahoo 등에서 책 제목으로 자주 검색해 보면 많은 리뷰를 볼 수 있다. 별별 다양한 의견들을 볼 수 있다.

그러한 의견들을 보면, 나의 책에 대해서 안티한 사람들이 적지 않다는 것을 알 수 있다.

내가 뭐 탁월한 천재도 아니고, 완벽한 사람도 아니기 때문에 실수를 할 수도 있지만, 우리나라 사람들(특히 IT하는 분들)은 똑똑한 분들이 굉장히 많기 때문에 많은 오류들을 찾아 내고, 부족한 부분들에 대한 글들을 블로그에 올린다.

그분들이 알지 모르겠지만, 나는 구글, 네이버, 야후에서 검색된 내 책에 대한 모든 리뷰를 거의 다 읽었다. (아마도…)

하지만, 나는 일일이 대꾸를 하지는 않는다. 사람마다 생각은 다르기 때문에...

안티한 사람들이 많더라도, 책이 많이 팔렸으니, 안티한 분들의 수도 그에 비례한다고 생각한다.
(아닌가? )

그런데, 몇몇 오류를 갖고 그 책의 모든 내용이 신뢰할 수 없다고 매도하는 사람들이 있다.
그런 글들이나 말을 들으면 며칠간 기분이 안 좋은데, 어쩔 수 없다. 그냥 그러려니 하는 수 밖에…

그래서 필자가 이 절에서 하고자 하는 이야기는

“책이 나오기 전에 사람들의 다양성에 대한 마음의 준비를 해야 한다.”

는 것이다. 책에 대한 안티한 글들에 일일이 답할 필요도 없고, 열받아 할 필요는 없다. 여러분만 손해다.
(그래서 이번 책에는 누가 이 책을 읽어야 하는지에 대한 설명도 포함하였다. 제발 좀 누가 읽어야 하는 책인지 확인해 보고 사서 보시면 고맙겠다.)




지금까지 짧으면 짧고, 길다고 하면 긴 "How to write a book" 연재를 마치고자 한다.
분명 도움이 되실 분이 있을꺼라 생각하고, 집과 출근버스에서 정리한 내용들이다.
마지막으로 이 글을 읽어주신 여러분께 한가지 당부를 드리고 싶다.

책의 내용이 저자의 의도와 100% 맞는 독자도 있고,
1%도 맞지 않는 독자도 있을 것이다.
바이블을 원하는 독자가 입문자를 위한 책을 읽을 경우 그러한 만족도는 많이 떨어질 것이다.
그렇다고, 그 책을 "쓰레기"나 "수박 겉핥기"로 매도하지는 말아 주기 바란다.

책을 쓰는 것은 저자의 이름을 걸고 하는 작업이다.

여러분들이 아무생각 없이 읽을 수도 있는 책의 한 챕터(장)를 쓰기 위해서는 적어도 2주, 많으면 한달이라는 시간이 소요된다.

그 책을 읽고 나서 리뷰를 쓸 때에는 한시간도 걸리지 않을 것이다. 따라서, 블로그나 인터넷 서점에 책 리뷰를 올릴 때에는 저자의 노력을 조금이라고 생각해 주고 써 주었으면 한다.

그래야, 그 저자의 다음 책들을 기다리는 독자를 위해서 여기 저기서 열심히 책을 쓰고 있는 저자, 번역자,그리고 출판사 담당자들에게 힘이 된다.

신고
Posted by tuning-java Trackback 0 : Comment 1
내가 한, 두번 Tomcat 5.5와 6성능 비교를 해 본 결과
동일한 Application을 수행할 때 Tomcat 6에는 성능 문제가 존재한다.
아직 정확한 성능 저하의 원인을 밝히진 못했지만,
TPS 상으로 적어도 10~20% 정도 저하된다.

어느정도 Tomcat 6의 성능이 안정화 될 때까지는 쓰지 않는 것을 권장한다.

참고로 아래 링크를 활용하면, 어떻게 Tomcat의 성능을 최적화 할 수 있는지 알 수 있다.

http://www.solutionhacker.com/?p=147




신고
Posted by tuning-java Trackback 0 : Comment 0

누차 이야기 하지만, 이 이야기는 지극히 개인적인 의견을 정리한 것이다.



출판사마다 작업의 방식이 다를 수 있고,
집필자마다 순서가 다를 수 있다.
절대적인 방법이 아니라는 것을 알아두기 바란다.
그리고, 순서대로 읽어주기 바란다.

 

번역이든, 집필이든,교육 교재든 출판사나 해당 회사와 계약이 되었다면
본격적으로 집필을 시작하자.

1. 집필의 순서

필자의 경우는 목차에서 자신 있는 부분을 먼저 작성한다.
(그래야 진도가 팍팍 나가는 느낌이 난다. )

그 다음엔, 좀 자신 없고, 매우 자신 없는 부분 순으로 작성한다.

만약 매우 자신 없는 부분부터 작성하면, 처음부터 질려서 포기하게 될 수도 있다.

그리고, 책을 쓰면서, 이렇게 쓰면 되나? 하고 본인에 대한 걱정이 생기면,
출판사 담당자에게 그때까지 쓴 부분을 보내주면서 괜찮은지 물어보는 것도 좋은 방법이다.

 

2. 집필 환경

번역할 때와 집필할 때의 환경은 틀리다.
번역은 PC가 있을때, 5분이나 10분만 있어도, 한줄 한줄 번역하면 되기 때문이다.

물론 그렇게 하면 앞뒤가 안 맞을 수도 있는데, 그건 나중에 해도 된다. ㅋㅋ

필자가 추천하는 환경은 적어도 30분 정도의 시간이 있을때 집필하는 것이 좋으며,
집필하기 위한 환경을 구축해 놓은 PC를 따로 준비하는 것이 좋다.
(그래서 필자는 넷북과 Mac을 준비했다. 어떻게 보면 책 쓴다는 핑계로 산 걸 수도 있다. ㅎㅎ)

필자가 보유하고 있는 PC만 해도,
- 회사 PC
- 집에 있는 와이프 인터넷 서핑용
- Mac
- Net Book

이렇게 4대다. 그래서, 이 PC 저 PC에 자료들이 혼재되어 있으면,
썼던 글을 덮어 쓸 수도 있고,
지울 수도 있고,
여러 안습 상황이 발생할 수 있다.

그래서, 회사 PC 및 인터넷 서핑용에서는 절대 집필 작업을 안하고,
Mac과 Net Book은 잠자기와 최대 절전모드를
최대한 활용하여, PC를 딱 열면 앞서한 작업을 연속해서 할 수가 있다.

만약 그렇게 하지 않으면, 집필 준비 작업만 적어도 5분 걸린다.

워드 띄우고, 이클립스 띄우고, 참고했던 문서나, 자료들 띄우고, …

되도록이면, 다른 사람의 간섭이 없는 그런 곳에서 작업하기를 권장한다.

글 쓰다가, 누가 말 시키거나 커피 먹자고 해서 집필이 끊기면, 나중에 다시 이어서 집필하기 어려울 수도 있다.
(이게 도대체 뭔 말이지? 하면서…)

 

3. 출처 밝히기

저작권에 걸리지 않기 위해서는, 출처를 꼭 명시해야만 한다.

때에 따라서는 저자의 동의를 얻어야 할 수도 있다.

필자가 Blog2Book 자바 튜닝 책을 집필한 당시에,
참조한 이미지에 대해서 Sun 에 괜찮은지 문의를 했다.

그때 Sun의 답은 황당했다.

“지금까지 이런 문의는 처음이라서…본사에 문의하겠습니다.”

한 3주 기다리다가 안와서 다시 문의하고, 출판사의 의견을 들어보니,
이미지는 다시 그리면 저작권에 위배가 안 된단다. (지금 저작권은 어떤지 모르겠지만..)

여하튼, 출처 밝히는 습관을 들여야 한다.

나중에 넣으려고 하면, 절대 못 넣는다.

 

4. 가끔은 쉬기

집필하는 작업은 개학이 1주일 정도 남아있는 초등학생의 기분과 비슷하다.
(물론 초등학교때 방학을 어떻게 보냈는지에 따라서 달라지겠지만, 필자의 경우…)

뭔가 하긴 해야 하는데,
책 쓰는 것 보다 이것을 더 하고 싶은데,
주말에도 책을 쓰긴 써야 하는데, PC 앞에만 앉으면 뭔가 딴짓만 하게 되고,

등등 스트레스가 적지는 않다.

프라모델을 만들거나, RC등을 조립하거나, 사진 찍으러 다니는 그런 일과
집필은 정 반대의 기쁨이기 때문이다.

그래서 가끔씩 쉬어 주어야 한다. 한달에 주말 내내 PC앞에 앉지 않고, 여행을 간다거나,
친구들을 만나서 술을 마시거나 하는 것이 정신 건강상 좋다.

그렇다고 집필하는 작업이 스트레스만 있는 것은 아니다.

책이 완성되어 나왔을 때, 저자에 내 이름이 박혀 있을 때의 기쁨은 다른 것과 비교할 수 없다.
(물론 와이프가 임신했다는 사실을 알았을 때가 더 기뻤다. ㅋㅋ)

 

5. 이미지는 BMP로 저장하기

왜 그런지 모르것지만, 모든 출판사가 이미지를 BMP를 달라고 한다.

되도록이면 이미지는 BMP로 저장해 놓기를 권장한다. (나중에 일괄로 변환해도 되긴 하지만, 만약 화면을 캡쳐하여 저장할 일이 있을때에는 BMP로 저장하는게 좋다.)

그리고, 순서를 맞추어서 01.aa.bmp와 같은 형식으로 숫자를 넣어 놓는 것이 좋다.

 

6. 목차 Update 하기

분명 최초 계획했던 목차에서 실제 목차는 바뀌게 되어 있다.

그래서 반드시, 목차가 추가되거나 삭제되었을 경우에는 반드시 update해야만 한다.

필자의 경우는 여러대의 PC에서 작업을 했기 때문에, Google Docs의 Word와 엑셀을 이용해서 목차를 관리했다.

그리고, 집필한 문서들이나 소스, 이미지들은 Google sites를 이용하여 저장했다. (반드시 비공개 사이트로 만들어야 한다. ㅋㅋ)

 

여하튼 계약 했으면, 열심히 쓰자~~~

신고
Posted by tuning-java Trackback 0 : Comment 0

다시 또 한번 이야기 하지만, 이 이야기는 지극히 개인적인 의견을 정리한 것이다.



출판사마다 작업의 방식이 다를 수 있고,
집필자마다 순서가 다를 수 있다.
절대적인 방법이 아니라는 것을 알아두기 바란다.
그리고, 순서대로 읽어주기 바란다.

 


그럼 세번째... 어떻게 시작해야 할 지에 대해서 알아보자.
집필을 하기 위해서 먼저 해야 하는 것은 "목차"를 만드는 것이다.
다른 것이 우선 아니냐고?

아니다.

먼저 목차를 만들어야 한다.
물론 목차를 만들기 전에는 앞에서도 이야기 했지만, 무엇에 대해서 책을 쓸 지에 "주제"를 선정하고, 자료를 모으는 작업은 선행되어야 한다.
하지만, 이 작업은 책을 쓰지 않는다고 하더라도 누구나 본인이 하는 작업을 정리 할 때 필요한 작업이다.

그래서, 본격적인 집필 시작은 목차를 만드는 작업이라는 것이다.

목차는 뭐 상세 목차까지 적어주면 되겠지만, 그럴 필요는 없이 그냥
대분류 목차로 적어도 15~20개 정도 적어 두면 된다.
(되도록이면 엑셀로)
만약 처음 집필하는 분이시라면, 상세 목차도 적어두면 좋을 것이다.

목차가 이쁘게 잘 선정 되었다면, 그 다음에는 출판사에 Contact 하는 것이다.
-주변에 아는 사람이나 친구, 친구의 친구가 출판사와 아는 사람이거나,
-친구중 저자가 있을 경우에는
그 아는 사람 통해서 Contact하는게 좋다.

만약 지인이 없어도 그냥 출판사에 Contact 해도 뭐라고 할 사람 아무도 없다.

메일로 연락해도 되고, 전화로 해도 되고, 만나도 된다.
아마도 여러분이 제시한 주제, 목차, 구성이 마음에 든다면 직접 만나서 이야기 하자고 할 것이다.

참고로 Blog2Book 자바 성능을 결정짓는... 책의 경우에는
A모 출판사에서 두명의 리뷰어에게 목차 리뷰를 받은 후 빠꾸를 먹었다.
(이런책은 아무도 필요 없다는 어떤 리뷰어의 리뷰와 함께...
논란의 여지가 있을 수 있어 말씀드리지만, 다른 한분은 목차가 괜찮다고 하셨지만,
책의 주제를 다른방향(Advanced Java ? 뭐 그런 방향...)으로 바꾸어 보라는 의견을 주셨다.)

하지만 운 좋게도, 그 빠꾸를 먹은날 한빛미디어에 책을 서너권 집필한 저자와 만났는데,
그분이 직접 출판사와 연결 시켜 주셨다.
그때 그 지인이 이야기한 중요한 이야기는
"책을 쓰려고 할때, 자신이 원하는 방향의 책이 아니면 쓰지 않는 것이 나아요.
이책임(그땐 직급이 책임(과장)이었다.)님은 튜닝 책을 쓰려고 한거지 다른 책을 쓰려고 한게 아니잖아요..."
라는 말이다. 그 말에 용기를 얻고 한빛 담당자분과 만나서, 목차를 약간 수정하고 집필하기로 했다.
안 그랬으면, 아마도 그 책은 세상에 나오지도 못했을 것이다.


이 이야기를 왜 하냐면,
여러분들이 직접 쓰고 싶은 책이 있다면, 출판사 하나에서 빠꾸 먹었다고 포기하지 말라는 것이다.

그런데, 어느 출판사나 이익을 내야하기 때문에, 1000부도 팔릴 것 같지 않은
그런 책을 내지는 않는다.
다시 말하면, 여러분들도 사지 않을 그런 책은, 다른 사람도 안산다는 것이다.

필자는 이번에 테스트 책을 썼지만, 원래는 테스트 책을 쓸 생각도 없었다.
그냥 Rex Black 아저씨 책 중 기본이 되는 몇권중 한권을 번역하려고 했었다.
하지만, 그 결과는 4개 출판사에서 그러한 번역서는 시장성이 없다는 이유로 빠꾸 먹었다. - -;
그 4개 출판사와 Contact하는 중에 심심해서 적어 놓은 것이 이번에 나올 Blog2Book Test책의 목차다.

그것도 그냥 책 쓸려고 한 것도 아니고, 그냥 목차만 만들어 놓고 한번 정리해 보면 좋겠다고 생각하고,
출판사 담당자에게 그냥 함 보라고 보여 줬던 것이 화근(?)이 되었다.
(그 담당자가 윗분에게 보여드리고, 그분이 한번 진행해 보라는 지시가 떨어져서리...)

여하튼,
출판사에서 OK하면,
책을 누가 보고, 누가 사고, 어떤 내용인지에 대한 소개서를 쓰고,
샘플챕터 하나 써서 내라고 한다.(아무리 목차가 좋아도 글이 맘에 안들면 안되니까...)
그리고 나서 마음에 들 경우,
계약금 받고 (보통 신사임당 10장에서 세금 좀 띄고) 계약서를 쓴다.

그런데, 여기서 한가지 유의할 점은,
"뭐 그럴 필요 있나? 다 쓰고 나서 가져가지"
라는 생각을 할 수도 있을 것이다.
그런데, 샘플 챕터를 제출하는 이유는 필자의 어떤 점들을 고쳐야 할지를 확인하는 데에도 의의가 있다.


그렇게 다듬고, 나머지 부분을 작성하는 것과
모두 작성해 놓고 문체나 책의 방식을 수정하는 것은
엄청난 차이가 있을 것이다.
(뭐 "난 상관 없어~~" 라는 분들은 그냥 다 써놓고 출판사를 만나도 된다.)

다음에는 본격적인 집필을 하기 위한 또 다른 준비작업에 대해서 알아보자.

신고
Posted by tuning-java Trackback 0 : Comment 2


다시 한번 이야기 하지만, 이 이야기는 지극히 개인적인 의견을 정리한 것이다.



출판사마다 작업의 방식이 다를 수 있고,
집필자마다 순서가 다를 수 있다.
절대적인 방법이 아니라는 것을 알아두기 바란다.
그리고, 순서대로 읽어주기 바란다.

 

두번째 이야기로, 제목에 있는 자료 모으기에 대해서 알아보자.

제목대로 자료만 잘 모으면 두번째 이야기에서 필자가 말하고자 하는 것은 끝난다.
(본인이 자료를 잘 모은다고 생각하면 이 글은 안 읽어도 된다.)

그렇다면, 어떻게 하면 자료를 잘 모으는 것일까?

구글링만 잘하면 자료를 잘 모은다고 할 수 있을까?

꼭 그런것 만은 아니다.

필자가  Blog2Book 자바 튜닝 책을 쓰려고 마음 먹은 것은 출판되기 3년전 이었다.
그냥 말 그대로, 마음만 먹고, 자료를 모으기 시작했다.
Sun, IBM, HP등 IT 관련 회사의 뉴스레터를 구독하고, 만약에 튜닝과 관련 있는 내용이라면,
그리고, 내가 경험한 내용도 체계적으로 정리해 놓으려고 노력했다.

그런데, 여기서 중요한 것은 자료를 모으는 것도 중요하지만,
정리하고, 분류하는 것도 중요하다는 것이다.

만약 집에 양말을 보관하는 곳이 두군데 이상이라면, 한곳의 양말이 떨어지면, 두번째 장소를 확인하고,
거기에도 없으면 세번째 장소를 찾아보게 될 것이다. 그 때 발생하는 시간 낭비는 급한 출근 및 등교시간에 적지 않은 시간이다.

여러분들이 모으는 자료도 마찬가지다.

뭐 ~~~ 메일 오면 바탕화면에 대충 저장하고, 
나중에 잘 찾으면 되겠지…
라는 생각을 가진 분도 있을 것이고,

뭐 ~~~ 자바라는 글자만 들어가 있으면,
한 폴더에 다 모아서 저장해 놓는 분도 있을 것이다.
(여러분들이 Mac을 쓴다면, 검색기능이 워낙 좋아서 신경 쓰지 않아도 되긴 하지만…)

그런데, 그렇게 하면 안 된다는 것이다.

꼭 책을 쓰기 위해서만이 아니라, 여러분이 프로젝트를 하거나, 무슨 일을 하더라도,
자료를 정리하고, 세부적으로 분류하는 습관을 가지면,
나중에 문서를 찾고, 참조할 때 매우 편리할 것이다.

예를 들어 자바도 각각의 패키지로 분류할 수 있고,
신기술도 여러 가지로 분류할 수 있다.

지금과 같은 정보의 홍수 속에, 이렇게 분류하는 것도 여러분들의 능력이다.

다음 글에서 설명하겠지만,
나중에는 이렇게 분류해 놓은 것에 순서만 붙이면,
그게 바로 목차가 된다.

 

그리고, 여러분들이 모아놓은 자료는 신뢰성이 있어야 한다.
필자가 쓴 책에 있는 내용에 딴지 거시는 분들도 많지만,(뭐 그 말들이 틀렸다는 건 아니고…)
여러분들이 모아 놓은 자료를 100% 신뢰해서는 안된다.
직접 눈으로 확인한 이후에 책에 넣어야만 한다.

 

보통 책을 집필할 당시에는 하루에 많으면 A4기준 5~10페이지를 쓰는 날도 있지만(그림 및 이미지가 많을 때에는 ㅋㅋ)
하루에 3장 정도 쓰는게 일반적인 속도다.(하루에 책쓰는데 아침과 저녁에 각 한시간씩 두시간 투자할 경우…)

그런데, 한 부분에서 필자도 잘 모르고, 막히는 경우에는 해당 부분의 글을 쓰기 위해서 3주가 소요될 수도 있다.
(더 자세한 이야기는 네번째 이야기인 집필하기에서…)

 

여러분들이 아무리 많은 자료를 모았다고 생각되더라도,  
책을 집필할 때에는 많이 부족하다는 것을 느낄 것이다.
그래도 일단 모아라…

 

여러분들이 글을 모으고, 정리해 놓기 시작했다면 다음 글을 읽어보기 바란다.

신고
Posted by tuning-java Trackback 0 : Comment 0
아시는 분들은 아시겠지만,
얼마전 나의 두번째 책을 탈고 했다.

앞으로 남은 일들도 있지만, 약간의 여유가 있어
내 경험을 기준으로 책은 어떻게 쓰는지, 어떻게 쓰면 되는지, 어떻게 시작하면 되는지 간단히 정리해 보고자 한다.

참고로 이 글은 지극히 개인적인 의견 및 경험이다.

이렇게 정리하고자 하는 이유는,
"내가 가진 지식을 누군가에게 알려주고 싶은데..."
"이거는 정리 잘 해 놓으면 도움 되는 사람들이 많을 꺼야..."
"내가 한 이런 고생은 다른 사람이 안했으면 좋겠다..."
"나도 책이란거 한번 써서 돈좀 벌어볼까?"
라는 분들을 위해서 정리하는 것이다.
(그런데 위의 4가지 사항중 마지막 사항에 관심있는 분들은 더 이상 읽지 말기바란다.
생각보다 IT책은 그리 돈은 안된다. - -;)

그러면 어떻게 준비해야 할까?
책이란 것을 쓰려고 준비하기 위해서는 먼저 경험이 필요하다.
프로젝트 경험이나, 개발 경험을 말하는 것이 아니다.
집필의 경험을 말하는 것이다.

아무도 아무것도 안하고 집필의 경험을 쌓을 수는 없다.
가장 집필 연습을 하기 좋은 것은
- 교육 기관의 교재 (즉 교육 교재를 말한다.)
- 번역서
다.
"난 블로그에 글 많이 썼고, 보고서도 많이 썼는데"라고 하는 분들도 있겠지만,
누군가의 통제하에 출판사가 만족할 수 있는 글을 쓰는 것은 쉽지 않다.(물론 내가 글을 잘쓴다는 것은 아니다. ㅎㅎ)
즉 출판사나 교재를 만드는 곳이 어떻게 돌아가는지를 교재나 번역서를 쓰면서 배우는 것이 좋으며,
기회가 되면 반드시 한번 도전하기 바란다.
(출판사에는 항상 저자나 역자를 향한 문이 열려있다. 출판사 홈페이지를 한번 뒤져보면 내 말이 거짓이 아니라는 것을 알 수 있다.)

그런데, 무엇보다도 이러한 경험을 쌓을 때 중요한 것은 약속을 지켜야 한다는 것이다.
누구와의 약속이냐면,
- 출판사와의 약속
- 자기 자신과의 약속
- 독자와의 약속
을 말하는 것이다.

출판사와는 기본적으로 납기를 기켜야 하며,
독자의 문의가 있거나 요청이 있을 때 그에 대한 답을 해 주어야 하며,
자신과의 약속은 하루의 일정시간, 일주일의 일정시간은 위의 모든 약속을
지키기 위해서 시간을 할애하겠다는 약속을 지켜야 한다는 것이다.

그렇지 않다면 아무것도 할 수 없다.


첫번째 집필한 Blog2Book 자바 성능 튜닝 책은 집필만 3개월, 직접 리뷰 1개월후 출판사로 넘겨서 납기에 문제가 없었다.
하지만, 이번에 집필 완료한 두번째 책(Blog2Book Test)은 납기를 무려 7개월이나 delay 했다.
이렇게 delay된 가장 큰 핑계는 회사를 옮기면서 정신적 여유가 없었다는 것이지만,
가장 큰 이유는 내가 게을렀기 때문이다.
회사를 옮긴 이후에 절대 이렇게 해서는 책을 쓸수 있는 시간이 없다는 판단을 했고, 어떻게 해서든 시간을 만들기로 했다.
그 시간을 만들기 위해서 넷북을 샀고, 출근 버스에서 집필했다.
(도저히 퇴근버스에선 멀미나서 쓸 수가 없다.)
아마도 이 책의 1/2 이상은 출근 버스에서 집필했을 것이다.
(그런데 출근 버스에서 책을 쓰면 인터넷이 안되어서 업무 가속도가 장난이 아니다.)

다음에는 그럼, 어떻게 시작하는지 알아보자.
신고
Posted by tuning-java Trackback 0 : Comment 4
http://www.ibm.com/developerworks/kr/library/au-aixperformancetuning/index.html

아침에 메일온걸 확인하다가, 고급 성능 조정의 개념이라는 글이 있어 이렇게 링크를 건다.

그런데, 상세한 가이드라기 보다는 개략적인 가이드라서
어느 정도 경험이 있는 분들이 봐야하는 그런 문서인듯...

추가로 메일을 보니, 에릭 감마 아저씨가 한국에 오는듯... 근데 무슨 QnA가 한시간이여???
안구라 선배가 가면 많은걸 물어볼텐데... ㅋㅋ

Jazz라는 제품 설명하러 오는거 같다.
신고
Posted by tuning-java Trackback 0 : Comment 0
http://jensor.sourceforge.net/

형이 어떻게 알고 알려준건지는 모르겠지만,
알려준 프로파일링 툴인 젠서(이렇게 읽으면 되나?)

관련 문서들을 대충 읽어 봤는데,
하나의 메소드당 30 마이크로 초 정도 잡아먹는단다.
그럼 그게 30번 불리면 1ms 정도 잡아 먹는다는 이야기가 되는데...
30000 번 정도의 메소드 호출이 있으면,
1초의 시간을 잡아 먹을듯...

근데 원격 기능이 없는듯 해서 약간 아쉽다.
신고
Posted by tuning-java Trackback 0 : Comment 0
http://developers.sun.com/learning/javaoneonline/j1online.jsp?track=javase&yr=2009

Java One 2009 자료들이 떴다.
이 자료들을 보려면 SDN 계정이 있어야만 한다.
(대부분 아시겠지만, 이 계정은 무료다. ^^)

지난 몇년간 성능테스트만 하고,
튜닝 업무는 주가 아닌 부 작업이 되었을 때 자료들을 보는 것과
지금 튜닝 업무가 주요 작업인 지금 자료들을 보는 것은 천지차이다.

역시 어떤 자료던지,
자기한테 필요가 있어야만 처다보게 되고,
머리에 쏙쏙 들어온다는 거~~~.

그나 저나 팀장님이 도움이 될꺼 같냐고 물어봤을때,
강력하게 이야기할 걸 그랬다.

내년엔 경기도 좋아지고,
팀도 계속 남아있고,
Java One 2010도 꼭 해서,
한번 참석해보고 싶당...
(회삿돈으로... ㅋㅋㅋ)
신고
Posted by tuning-java Trackback 0 : Comment 0
자바의 GC 방식에는 여러가지가 있지만,
최근에 나온 기술에는 G1이라는 것이 있다.
최근에 나온 JDK 6.0 update 14에는 early access 로 G1을 사용할 수 있도록 했다.
G1을 적용하기 위해서는 java start option에
-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC
라고 명시해 주면 된다.

추가로 G1을 사용할 때 GC로 인한 최대 대기시간을 지정하기 위한
-XX:MaxGCPauseMillis=<X>
옵션을 추가할 수 있으며,
-XX:GCPauseIntervalMillis=<X>
옵션을 통해서 GC 대기 사이의 간격을 지정할 수 있다.
그런데 여기서 중요한 것은
이 옵션은 Goal 이다. Promise나 guarantee 가 아니라는 것이다.
(목표일 뿐이고, 이건 약속이나 보장한다는 것이 아닐 뿐이고~~)

G1이 다른 GC와 다른 것은 GC를 담당하는 New와 Old의 장벽이 사라졌다는 것~~~
자세한건 아래 링크의 비됴나 문서를 함 보시길~~~

Sun Tech Days 2008-2009 자료 보기
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5419&yr=2008&track=javase


신고
Posted by tuning-java Trackback 0 : Comment 0
먼저 자바 성능을 결정짓는 코딩 습관과 튜닝 이야기를 구매하고, 읽어주신, 그리고, 읽고 계신 독자 여러분께 감사하다는 말씀을 드립니다.

이렇게 글을 올리는 이유는 책을 쓴 저자가 책을 읽는 여러분이 정확한 지식을 습득해야 한다고 생각하기에 책이 나온지 1년 3개월이 지난 지금 이렇게 글을 씁니다.(이렇게 갑자기 책에 대해서 이야기하는 것은 가장 아래에 적어 놓았습니다.)

먼저 제 책에 있는 몇몇 오류에 대해서는 손권남씨께서 자신의 블로그 http://kwon37xi.egloos.com/3733755 에서 잘 설명해 두었습니다. 여기서 제가 보기에도 완전한 문제라고 생각된 부분에 대해서는 2쇄 발행시 많이 수정하였습니다.

그런데, 가장 논란이 많은 부분은 역시 Collection관련 부분입니다.
물론 테스트를 제대로 하지 않았다는 점에 대해선 100% 인정합니다.
(http://agbird.egloos.com/4800620 에 있는 내용을 잘 읽어 보시면 도움이 되실겁니다.)

각각의  Map, Set, List, Queue 등은 자신의 용도에 맞게 사용해야만 합니다. 

그렇다면, 제가 책에 왜 Collection에 대해서 썼을까요?
잘못된 지식을 주기 위해서?
제 책에 안티하신 분들이 말씀하시는 잘못된 테스트 방법을 알리기 위해서 ?
모두 아닙니다.

사실 Collection은 일반 웹 프로그래밍을 할 때 성능의 관점으로 보았을 때 중요하지 않습니다.
하지만 만약 여러분들이 Batch 프로그램이나, WAS 등을 개발한다면 이야기는 완전히 달라집니다. 굉장히 중요합니다.
책을 보신분은 아시겠지만, 테스트 케이스는 적어도 만번 이상 반복 수행을 한 내용입니다.
일반 웹에서는 그렇게 많은 회수의 데이터 검색 및 처리를 해서는 안됩니다.
그렇게 몇만건의 데이터 처리를 하게 된다면 고객을 반드시 설득시키시기 바랍니다. 그건 Web이 아니라, Web의 껍데기를 하고 있는 C/S프로그램입니다.

책을 쓰면서 여러 자료를 수집하면서, 웹 상에서 어떤 Collection이 가장 빠르냐에 대한 논쟁이 일어난 부분을 많이 보았습니다.
그러한 논쟁은 웹 개발시에는 그리 큰 의미가 없다는 것을 알리기 위해서 쓴 부분 입니다.
그렇게 Collection의 성능이 걱정되신다면 구글 Collection을 쓰세요. 

다시 한번 책에 잘못된 지식을 전달한 점에 대해서 죄송하다는 말씀을 드립니다.

그런데, 지금까지 가만히 있다가 왜 갑자기 이런글을 썼을까요?
이번주 화요일에 사내에서 컨퍼런스가 있었습니다.
자바 성능과 관련된 부분이 있어 관심있게 듣게 되었습니다.
그런데, 사전에 컨퍼런스 자료를 검토하던중, 제 책이 잘못되어 있다고 되어 있는 부분을 발견하여
발표자에게 컨퍼런스 전에 메일을 드렸지만, 
메일을 보지 못하고 컨퍼런스를 진행하시더군요. - -;

그 발표자 분과는 컨퍼런스 후에 메일을 통해서 이야기를 하게 되었는데,
예전에 발표자와 다른 어떤 분이 Collection 부분 때문에 엄청 심하게 싸웠고,
그러한 문제 때문에 책에 대한 문제점을 세미나에서 다루었다고 말씀하시더군요.

제가 쓴 책 때문에 다툼까지 발생하리라고는 생각지도 못했습니다.
추후에라도 제가 잘못 쓴 부분 때문에 많은 분들이 다투지 않았으면 하는 생각에 글을 쓰게 되었습니다.

제가 완벽하지도, 똑똑하지도 않은 사람이지만,
성능에 때문에 고생하는 많은 분들을 위해서 쓰게된 책입니다. 조금더 성능에 대한 정확하고 심오한 정보를 얻고 싶으시다면, Effective Java를 반드시 읽어 보세요. 

그래도, 저도 사람인지라 깊이가 낮다. 일부분의 오류 때문에 잘못된 책, 믿지 못할 책이라는 평가를 보면 하루 종일 기분이 좋지 않더군요. 그래서 최근에는 검색을 잘 안해보고 있습니다. ^^:

지금은 "개발자도 쉽게 배우는 테스트와 테스트 툴 이야기(가제)"라는 책을 쓰고 있습니다.
이 책도 저번 책과 마찬가지로, 테스트에 대해서 잘 모르는 초급 개발자와 간단히 참조하기를 위한 중급 개발자분들을 위한 책입니다. TDD에 대한 심오한 이야기나 CI에 대한 깊은 이야기를 다루지는 않았습니다. 
단지, 그러한 단어가 무엇을 뜻하는지, 왜 해야하는지, 테스트라는 말만 들으면 스트레스를 받는 분들을 위해서 최대한 쉽게 쓰려고 노력하고 있습니다.
지금 쓰고 있는 책의 서문에도 써 놓았지만(나중에 출판사에서 그 내용을 뺄 수도 있습니다.), 
자신이 고급 개발자라고 생각하시는 그런 분들은 절대 제가 쓰고 있는 책을 사지 마세요.
그런 분들은 안읽으셔도 됩니다. (보시면 도움이 될만한 부분이 적어도 하나는 있겠지만...)

지금 쓰고 있는 책을 탈고하고, 출판을 한 이후에는
"자바 성능을 결정짓는 튜닝, 그 두번째 이야기"를 쓸 예정입니다.(목차는 거의 완성되었습니다.)
그 책은 성능에 대해서 깊게 쓸 예정이므로, 첫번째 이야기에 실망하신 분들은 기대하셔도 좋습니다.
두번째 책도 실망하시는 분들은 제가 어쩔 수 없죠. - -; 
단, 출판사와 계약 안하고 90% 완료한 상태에서 계약할 예정입니다. ^^;
(빠르면 내년 10월쯤 나올 것 같습니다. )

넋두리가 심했네요.

긴글 읽어 주셔서 감사합니다. 
신고
Posted by tuning-java Trackback 0 : Comment 1
GC가 뭔지 잘 모르시는 분들은 제 블로그의 다른 글을 찾아보시거나,
"자바 성능을 결정 짓는 코딩 습관과 튜닝 이야기"를 참조하시길...

자바의 메모리 구조는 다음과 같이 되어 있다.
  • Code Cache: contains memory used for compilation and storage of native code
  • Eden Space: pool from which memory is initially allocated for most objects
  • Survivor Space: pool containing objects that have survived Eden space garbage collection
  • Tenured Gen: pool containing long-lived objects
  • Perm Gen: contains reflective data of the JVM itself, including class and memory objects
  • Perm Gen [shared-ro]: read-only reflective data
  • Perm Gen [shared-rw]: read-write reflective data

    아래는 GC를 어떻게 튜닝하는지에 대한 자세한 설명이 있는 사이트 링크다.
    http://java-monitor.com/forum/showthread.php?t=30

    이것도 귀찮은 분을 위해서 더 간단한 튜닝 정보
    http://developer.amd.com/documentation/articles/pages/4EasyWaystodoJavaGarbageCollectionTuning.aspx

    완벽한 GC의 방식과 처리에 대한 자세한 정보를 보려면 아래 링크에 있는 PDF 파일을 참조하는 것도 좋다.
    http://www.cecmg.de/doc/tagung_2007/agenda07/24-mai/2b3-peter-johnson/index.html


    한글로 된 설명을 보고자 하신다면
    다시한번 말씀드리지만,
    "자바 성능을 결정 짓는 코딩 습관과 튜닝 이야기"를 참조하시길...
    지금 생각해보면 이 책에 이 부분에 대한 설명을 좀 약하게 적었다는 생각이 많이 들긴 한다.
    다음책에선 자세히 적어놔야지...

    추가로 Java 6 GC 튜닝 방법에 대한 Sun의 자료는 아래와 같다.
    http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html

  • 신고
    Posted by tuning-java Trackback 0 : Comment 0
    자바 힙 덤프 분석기는 jhat등 여러가지 툴이 있지만,
    최근에 발견한 Eclipse Memory Analyzer 라는 프로그램이 있다.

    http://www.eclipse.org/mat/

    다운로드하여 압축을 해제하고, 이클립스만 수행하면 된다.
    단, 기본 자바 VM을 사용할 때 발생한 HPROF 덤프 파일의 확장자는 반드시 hprof 여야만 읽을 수 있다.

    작성된 힙 덤프 파일을 이 프로그램에서 읽으면 다음과 같은 화면을 제공한다.
    사용자 삽입 이미지

    신고
    Posted by tuning-java Trackback 0 : Comment 0