기본 배경.

크롬의 목표

  • 속도 : 빠른 브라우저
  • 보안
  • 안정성 : 웹 앱 플랫폼
  • 단순함 : 복잡한 기술을 단순한 사용자 경험속에 녹이기.

크롬이 사용한 기술

  • 멀티 프로세스 모델 : 프로세스 및 메모리 격리. 각 탭당 보안 샌드박스 모델 제공.
  • 웹 프로그램 싱행의 주요 단계 : 리소스 가져오기, 페이지 레이아웃 및 렌더링, 자바스크립트 실행.
  • V8 : 오픈소스, 빠른 자바스크립트 엔진. node.js의 기본 엔진이기도 함.
  • Blink : 오픈소스, 빠른 표준 호환 레이아웃 엔진.
  • 학습 : 사용자 이용 패턴 수집, 분석을 통한 빠른 사용자 경험 제공.

모던 웹 앱

  • HTTP archive 프로젝트에 수집된 30만개의 문서를 분석
  • 한 페이지를 표시하는데 1280KB, 88개의 리소스, 15개 이상의 개별 호스트 연결이 필요.

사용자 입장에서 '충분히 빠름'이란?

  • 0 100ms : 바로 반응
  • 100 300 ms : 약간 인식되는 느림.
  • 300 1000ms : 기계가 동작하는 구나 인식.
  • 1s+ : 정신세계의 컨텍스트 전환
  • 10s+ : 나중에 해야지

네트워크 입장에서 리소스 요청의 수명

  1. Redirect, App Cache : 이미 가져온 리소스중에서 적절한 캐시관련 헤더(Expireds, Cache-Control 등)가 설정되어 있었다면 로컬 사본을 이용.
  2. DNS 질의
    • 크롬은 {스킴, 호스트, 포트}에 따라 재 사용되는 소켓 풀을 관리.
    • 프록시가 설정되어 있거나, 프록시 자동설정 스크립트(PAC)가 설정되어 있는지 확인. 설정되어 있다면 프록시에 대한 소켓 풀 관리. PAC는 URL에 따라 다른 프록시 설정이 가능.
    • DNS 질의는 인기있는 호스트거나 가까이있는 호스트 도메인일 경우 응답이 빠름.
  3. TCP 연결
    • 3-웨이 핸드쉐이킹 : 순차적으로 SYN/SYN_ACK/ACK가 이루어지다 보니 시간이 많이 소요.(full round-trip time).
    • HTTPS 요청일 경우 SSL핸드쉐이킹이 발생. 이는 추가로 2번의 라운드트립 지연이 발생할 수 있음. 다만 SSL세션이 캐시되어 있을 경우 한번의 라운드트립 시간에 연결 가능.
  4. HTTP 요청
    • HTTP 요청을 보내는데 필요한 시간 + 서버가 응답을 처리하는데 소요되는 시간 + 서버가 보낸 응답을 받는 시간.

미국 광대역통신망에서의 간 단계별 소요시간

  • DNS : 50 ms
  • TCP 핸드쉐이킹 : 80ms (1RTT)
  • SSL 핸드쉐이킹 : 160ms (2 RTT)
  • HTTP 요청 전송 : 40ms
  • 서버 처리 시간 : 100ms
  • 서버 응답 전송 : 40ms
  • 하나의 리소스 요청에 대해 470ms 소요. 그중 80%이상의 시간이 네트워크 연결에 소요된 시간.
  • 악조건 : 초기 TCP 윈도우 크기(4~15KB)가 서버 응답을 보내는데 적절치 않을 경우 한두번 더 RTT지연이 발생. SSL 연결의 경우 인증서를 못가져오거나 온라인 인증서 상태 확인(OCSP; Online Certificate Status Check)를 진행할 경우 수백에서 수천 밀리초의 지연이 추가 발생




원문 : http://aosabook.org/en/posa/high-performance-networking-in-chrome.html

Posted by NeoZest


NeoZest입니다.

오늘은 신입/초급 웹 개발자를 위해 포스트를 적어볼까 합니다.

대부분 프로젝트를 수행할 때 기본 원칙과 현실적인 트릭을 함께 사용해야 할 경우가 있습니다. 그중 대표적인 것이 콘텐츠 동적 생성과 정적 생성입니다.

최근 웹 페이지는 콘텐츠를 데이터베이스에 많이 넣어두고 생성을 하죠.
그러면서 요청이 있을 때마다 데이터베이스에 연결해서 내용을 가져와서, 템플릿 코드로 뿌리죠. 그런데 이렇게 작성하는 것은 개발환경에서는 문제가 없는데...다수의 사용자가 요청할 때는 서버에 부담을 주게 됩니다.

반면 정적인 파일을 그냥 클라이언트로 전달하는 것은 연산작업이 없기 때문에 상대적으로 훨씬 적은 부담을 주게됩니다.

따라서 서버에서 전달할 콘텐츠가 실시간성이냐 아니냐를 잘 고민해 보고, 실시간성이 아닐 경우에는 일정 주기별로 정적 파일을 생성하고, 이 파일을 이용하는 것이 좋습니다. 일종의 캐싱기법을 직접 적용하는 것이죠.(이 방법보다 정석은 캐싱서버를 두는 것이겠지요.)

예를 들어 인기검색어를 XML로 뿌려주는 웹페이지를 만든다고 했을 때, 인기검색어가 초단위로 팍팍~ 변하는 것은 아니겠지요. 예를 들어 10분정도마다 변화가 있고, 10분마다 데이터를 갱신하더라도 사용자의 불만이 없는 상황이라 생각되면, 10분마다 정적인 파일을 생성하는 것이 좋겠지요.

여기까지 이야기를 하면 다들 어떤 파일명으로 바로 쓰기 작업을 하는 경우가 있는데요. 한 쓰레드가 동일 파일명으로 쓰기 작업을 수행할 경우에는 Lock이 걸립니다. 이런 문제는 결국 임시파일로 생성한 다음, 정상적으로 생성된 경우에만 rename/move를 해주는 것이 편법의 정석이겠지요.

신입/초급 개발자들을 보면 너무 DB에 많은 부담을 지우는 것 같아서 이런 방법도 있다라는 것을 알려주고, 또한 시스템 전체적으로 성능을 향상시키는 방법을 고민해 보라는 차원에서 적었습니다. 그리고 데이터의 생명주기까지 한번 고민해 보는게 좋을 것 같아요.

이런 경우가 안생기도록 서비스 플랫폼 구조를 만들고, 미리미리 성능까지 테스트하는 것이 가장 최선이겠지요!
Posted by NeoZest