책 이미지
책 정보
· 분류 : 국내도서 > 컴퓨터/모바일 > 컴퓨터 공학 > 소프트웨어 공학
· ISBN : 9788994506906
· 쪽수 : 308쪽
· 출판일 : 2014-05-21
책 소개
목차
제1장 크롬의 고성능 네트워킹
1.1 구글 크롬의 역사와 기본 지침 1
1.2 성능의 여러 측면 2
1.3 현대적인 웹 응용 프로그램의 특징 4
1.4 네트워크 자원 요청 하나의 일생 5
1.5 “충분히 빠르다”의 의미 8
1.6 3천 미터 상공에서 본 크롬의 네트워크 스택 10
1.7 브라우저 세션의 일생 19
1.8 크롬은 사용하면 할수록 빨라진다 33
제2장 SocialCalc에서 EtherCalc로
2.1 초기 원형 38
2.2 첫 번째 병목 39
2.3 Node.js로 이식 41
2.4 서버 쪽 SocialCalc 42
2.5 Node.js 프로파일링 43
2.6 다중 코어 규모 확장 46
2.7 교훈 48
제3장 Ninja
3.1 크롬의 간단한 역사 54
3.2 Ninja의 설계 56
3.3 Ninja가 하는 일 58
3.4 Ninja의 최적화 60
3.5 결론 및 설계 대안 67
3.6 감사의 글 68
제4장 빛의 속도로 XML 파싱하기
4.1 소개 69
4.2 XML 파싱 모형들 70
4.3 pugixml 설계상의 선택들 71
4.4 파싱 72
4.5 DOM 자료구조 85
4.6 스택 기반 메모리 할당 89
4.7 스택 기반 할당자의 메모리 해제 지원 93
4.8 결론 95
제5장 MemShrink
5.1 소개 97
5.2 기반구조의 개요 98
5.3 잰 만큼 얻는다 101
5.4 달성하기 쉬운 과제들 105
5.5 내 잘못은 아니지만 내 문제 108
5.6 영속성은 탁월함의 대가 110
5.7 공동체 112
5.8 결론 113
제6장 최적화 원리 패턴들을 구성요소 배치와 구성 도구들에 적용하기
6.1 소개 115
6.2 DAnCE의 개요 119
6.3 최적화 원리 패턴들을 DAnCE에 적용하기 123
6.4 결론 140
제7장 Infinispan
7.1 소개 145
7.2 개요 146
7.3 Infinispan의 벤치마킹 149
7.4 Radar Gun 150
7.5 성능 문제의 잠재적 근원 153
7.6 결론 159
제8장 Talos
8.1 개요 162
8.2 측정 대상의 이해 164
8.3 재작성 대 리팩터링 167
8.4 성능 문화 만들기 168
8.5 결론 171
제9장 Zotonic
9.1 Zotonic 소개 173
9.2 왜 Zotonic인가? 왜 Erlang인가? 174
9.3 Zotonic의 구조 177
9.4 문제 해결: 슬래시닷 효과에 맞서기 180
9.5 캐싱 계층들 183
9.6 Erlang의 가상 기계 190
9.7 Webmachine 라이브러리 변경 사항 194
9.8 자료 모형: SQL 기반 문서 데이터베이스 196
9.9 벤치마크, 통계치, 최적화 197
9.10 결론 199
9.11 감사의 글 200
제10장 이동통신망 성능의 비밀
10.1 소개 201
10.2 잠복지연의 근원들 202
10.3 셀 방식 이동통신망의 특성 203
10.4 네트워크 프로토콜 성능 208
10.5 TCP(전송 제어 프로토콜) 209
10.6 HTTP(하이퍼텍스트 전송 프로토콜) 213
10.7 TLS(전송층 보안) 216
10.8 DNS(도메인 이름 시스템) 219
10.9 결론 221
제11장 Warp
11.1 Haskell의 네트워크 프로그래밍 224
11.2 Warp의 구조 229
11.3 Warp의 성능 231
11.4 핵심 착안 233
11.5 HTTP 요청 파서 235
11.6 HTTP 응답 조합기 242
11.7 타이머를 이용한 정리 245
11.8 향후 작업 249
11.9 결론 251
제12장 생물정보학의 거대 자료 다루기
12.1 소개 253
12.2 khmer의 구조와 성능상의 고려사항 257
12.3 프로파일링과 측정 261
12.4 조율 265
12.5 전반적인 조율 266
12.6 병렬화 271
12.7 결론 275
12.8 향후 개선안 275
12.9 감사의 글 276
참고문헌 277
찾아보기 282
저자소개
책속에서
소프트웨어에서 단순함은 하나의 미덕이다. 항상 문제는 단순함을 얼마나 오래 유지할 수 있는가이다. Ninja는 특정한 값비싼 과제들을 다른 도구(GYP나 CMake)에 위임함으로써 빌드 시스템의 복잡성을 상당 부분 잘라 냈다. 그리고 그 덕분에 애초에 Ninja를 염두에 두고 만든 프로젝트가 아닌 다른 프로젝트들에서도 Ninja를 유용하게 사용할 수 있다. 나는 Ninja의 단순한 코드가 기여자들을 격려했으리라고 믿는다.
소프트웨어를 최적화하기란 어렵다. 성공적인 최적화를 위해서는 거의 항상 저수준 미시적 최적화와 고수준 성능 지향적 설계 결정, 세심한 알고리즘 선택과 조율, 메모리와 성능, 구현 복잡도 사이의 절충 등 다양한 노력이 필요하다. pugixml은 아주 빠른 현업 수준 XML 파서를 제공하기 위해(그러한 목표를 위해 몇 가지 희생한 것들도 있긴 하지만) 이 모든 접근방식이 필요한 라이브러리의 예이다. 구현 세부사항의 상당 부분은 다른 프로젝트나 과제에 맞게 개조가 가능하다. 다른 프로젝트는 또 다른 파싱 라이브러리일 수도 있고, 아예 다른 뭔가일 수도 있겠다. 이 글에서 제시한 요령들이 독자의 흥미를 끌어당겼다면, 그리고 다른 프로젝트들에 유용하게 쓰인다면 좋겠다.
파이어폭스 4는 웹 브라우저의 개방적 동영상 지원, JavaScript 성능, 그래픽 가속 같은 영역에서 커다란 진전을 이룩했지만, 안타깝게도 메모리 사용량 면에서는 크게 후퇴했다. (중략) 그로부터 약 1년 반이 지난 지금, 그들의 일치된 노력은 파이어폭스의 메모리 소비량과 평판을 급속도로 바꾸었다. 대부분의 사용자들의 머리에서 ‘메모리 누수(memory leak)’는 과거의 일이 되었으며, 이제는 파이어폭스가 다른 브라우저들과 비교할 때 가장 가벼운 브라우저들 중 하나로 간주되는 경우가 많다. 이번 장에서는 파이어폭스의 메모리 사용량을 개선하기 위한 노력들을 살펴보고 그 과정에서 배운 교훈들을 소개하고자 한다.
