고성능 웹 사이트 구축 (메모 1)

09 년 12 월 12 일 에 상경 하여 교 내 신 입 사원 간담 회 에 참석 했다.제 부 서 는 3G 기술 을 하고 있 습 니 다. 핸드폰 무선 wap (구체 적 으로 wap 가 무엇 인지 아직 모 르 겠 습 니 다) 를 하고 있 습 니 다. 지도 교수 옌 지 동 은 관련 서적 몇 권 을 추천 하여 저 를 입문 시 켰 습 니 다. 이것 은 그 중의 한 권 입 니 다.회 의 를 마치 고 돌아 와 눈 깜짝 할 사이 에 한 달 여 동안 눈 깜짝 할 사이 에 지나 갔다. 실험실 선생님 의 요구 가 엄격 하고 규칙 이 엄격 하기 때문에 실험실 에서 비 혼돈 관련 서적 을 읽 는 것 을 엄격 한 대상 으로 삼 았 다. 게다가 그 동안 혼돈 암호 화 소프트웨어 를 만 들 었 기 때문에 이 책 을 연구 하 는 데 많은 시간 을 들 이지 못 하고 중간 몇 장 만 훑 어보 고 내 려 놓 았 다.겨울방학 이 고 주말 이 되면 실험실 에서 상대 적 으로 긴장 을 풀 라 고 요구 해서 나 는 책 을 다시 주 워 서 자세히 음미 하기 로 결정 했다. 비록 수박 겉 핥 기 식 이지 만 입문 할 권리 가 있다.시작 하기 전에 예전 의 스타일 에 따라 전생 을 요리 하고 방문 한 3, 4, 5, 6, 7 장 을 정리 합 니 다.
 
제3 장 서버 병행 처리 능력     여기 서 말 하 는 서버 는 Http 서 비 스 를 제공 하 는 서버 1, 삼투 율: 웹 서버 단위 시간 내 처리 요청 의 개 수 를 말 합 니 다.삼투 율 은 압력 테스트 를 통 해 얻 을 수 있 는데 삼투 율 의 전 제 는 다음 과 같은 조건 을 포함한다. 동시 다발 사용자 수, 요청 총수, 요청 자원 설명 이다.     동시 다발 사용자 총수: 어느 순간 서버 에 요청 한 사용자 수 를 동시에 보 내 는 것 을 말 합 니 다.     비교적 많은 변 수 를 포함 한 데이터 모델 에서 최적화 결 과 를 구 하 는 것 은 매우 어렵다.     서버 와 사용자 쌍방의 모순: 서버 는 높 은 병발 율 과 삼투 율 을 지원 하 기 를 원 하지만 사용 자 는 비교적 적은 시간 만 기다 리 기 를 원 하기 때문에 쌍방 이 모두 만족 할 수 없다.     웹 서버         실제 동시 다발 사용자 수 는 웹 서버 가 현재 유지 하고 있 는 서로 다른 사용 자 를 대표 하 는 파일 설명 수, 즉 동시 다발 연결 수 로 이해 할 수 있 습 니 다. 물론 사용자 가 요청 한 만큼 연결 을 만 드 는 것 이 아 닙 니 다. 웹 서버 는 일반적으로 동시 서비스의 최대 사용자 수 를 제한 합 니 다. 예 를 들 어 Apache 의 MaxClient 파라미터 와 같 기 때문에..때때로 실제 동시 다발 사용자 수 는 서버 가 유지 하 는 나 는 간 설명자 의 총수 보다 클 수 있 습 니 다. 이때 더 많은 사용자 요청 은 서버 커 널 의 데이터 수신 버퍼 에서 처 리 를 기다 리 고 있 습 니 다.         웹 서버 가 하 는 작업 의 본질은 가장 빠 른 속도 로 커 널 버퍼 에 있 는 사용자 가 요청 한 데 이 터 를 하나 도 남지 않 은 것 으로 가 져 온 다음 에 이 요청 을 최대한 빨리 처리 하고 커 널 유지보수 에 응 하 는 다른 데 이 터 를 데 이 터 를 보 내 는 버퍼 에 넣 고 다음 요청 을 계속 처리 하 는 것 입 니 다.     사용자 평균 요청 대기 시간: 서버 가 일정한 동시 다발 사용자 수 를 평가 하 는 상황 에서 단일 사용자 에 대한 서비스 품질 을 평가 하 는 데 사 용 됩 니 다.     서버 평균 요청 처리 시간: 사용자 가 서버 의 전체 서비스 품질 을 평가 하 는 것 은 삼투 율 의 역수 입 니 다.
     Apache 의 ab 테스트: ab. exe 는 Apache 의 bin 디 렉 터 리 에 있 습 니 다.      명령 행 조작  C:\Program Files\Apache Software Foundation\Apache2.2\bin>ab –n 100 –c 10 http://zzqrj.iteye.com/blog/570951       -n 100 은 요청 총 수 를 나타 내 고 - c 100 은 동시 다발 사용자 수 를 나타 낸다.      결과:

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking zzqrj.iteye.com (be patient).....done

Server Software:        lighttpd/1.4.20 /*    Web       */
Server Hostname:        zzqrj.iteye.com  /*   URL        */
Server Port:            80  /*             */

Document Path:          /blog/570951  /*  URL       */
Document Length:        2095 bytes  /*Http         */

Concurrency Level:      10    /*     */
Time taken for tests:   41.563 seconds  /*              */
Complete requests:      100   /*    */
Failed requests:        0   
Write errors:           0
Total transferred:      235300 bytes  /*        ，  Http      */
HTML transferred:       209500 bytes /*            ，   Http */
Requests per second:    2.41 [#/sec] (mean)
/*   ，     CPU       Complete requests/ Time taken for tests */
Time per request:       4156.250 [ms] (mean) 
/*           Time taken for tests /( Complete requests/ Concurrency Level)*/
Time per request:       415.625 [ms] (mean, across all concurrent requests)
/*           ，       Time taken for tests / Complete requests */
Transfer rate:          5.53 [Kbytes/sec] received /*                */

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      328  405 414.2    344    3344
Processing:   344 3500 1311.0   3125    6125
Waiting:      344 2161 1424.1   2016    6109
Total:        688 3905 1357.3   3469    6484

Percentage of the requests served within a certain time (ms)
  50%   3469
  66%   3516
  75%   3563
  80%   6297
  90%   6422
  95%   6453
  98%   6453
  99%   6484
 100%   6484 (longest request)

    동시 다발 사용자 가 일정 수량 으로 늘 어 날 때 서버 의 평균 처리 시간 이 대폭 증가 하고 사용자 의 평균 요청 대기 시간 도 대폭 증가한다.    병발 전략의 디자인 은 서버 가 비교적 많은 요 구 를 동시에 처리 할 때 어떻게 CPU 계산 과 IO 조작 을 합 리 적 으로 조율 하고 충분히 이용 하여 비교적 큰 병발 사용자 수 상황 에서 비교적 높 은 삼투 율 을 제공 하 는 지 하 는 것 이다.     아파 치 prefork 모드 와 worker 모드:        prefork 모드: 이러한 다 중 처리 모듈 (MPM) 은 비 스 레 드 형, 예비 파생 웹 서버 를 실현 합 니 다. 이 모드 는 요청 이 올 때 새로운 프로 세 스 를 만 들 지 않 아 도 시스템 비용 을 줄 여 성능 을 향상 시 킬 수 있 습 니 다.Prefork 는 여러 개의 키 프로 세 스 를 사용 합 니 다. 모든 프로 세 스 는 하나의 스 레 드 만 있 고 스 레 드 보안 라 이브 러 리 가 없 는 시스템 에 적합 합 니 다.        worker 모드: 이 다 중 처리 모듈 (MPM) 은 네트워크 서버 가 혼 합 된 다 중 스 레 드 다 중 프로 세 스 를 지원 합 니 다.여러 개의 하위 프로 세 스 를 사용 합 니 다. 모든 하위 프로 세 스 는 여러 개의 스 레 드 가 있 습 니 다.        아파 치 conf \ extra \ httpd - mpm. conf 에 설정 되 어 있 습 니 다.2. CPU 병렬 계산     IO 의 속 도 는 CPU 의 속도 에 비해 늙 은 소의 산책 과 초음속 비행기 처럼 멀리 떨어져 있다.     프로 세 스: 모든 프로 세 스 는 독립 된 메모리 주소 공간 과 수명 주 기 를 가지 고 있 으 며, 모든 프로 세 스 는 CPU 레지스터 만 공유 할 수 있 습 니 다.     스 레 드:    컨 텍스트 전환: 모든 프로 세 스 가 시스템 자원 을 돌아 가면 서 사용 할 수 있 도록 프로 세 스 스케줄 러 는 필요 할 때 실행 중인 프로 세 스 를 걸 고 이전에 걸 었 던 프로 세 스 를 복원 합 니 다. 이러한 행 위 는 프로 세 스 전환 이 됩 니 다.     프로 세 스 가 걸 려 있 는 본질은 CPU 레지스터 에 있 는 데 이 터 를 꺼 내 커 널 스 택 에 임시 저장 하 는 것 입 니 다.
     프로 세 스 복구 작업 의 본질은 CPU 레지스터 에 데 이 터 를 다시 불 러 오 는 것 이다.    CPU 전환 (좋 은 예): 한 손 으로 원 을 그리고 한 손 으로 사각형 을 그 리 는 것 은 힘 들 고 머리 가 돌아 가지 않 으 며 그림 을 유창 하 게 그리 지 못 하기 때 문 입 니 다. 그림 을 그 리 는 데 는 두뇌 계산 이 필요 하기 때 문 입 니 다. 두 손 이 동시에 그림 을 그 릴 때 양쪽 이 유창 하 게 진행 되도록 '상하 문 전환' 을 빠르게 진행 하고 원형 과 사각형 을 그 리 는 규칙 을 뇌 에 계속 넣 고 옮 겨 야 합 니 다.시간 이 필요 해.     자물쇠 경쟁: 자 물 쇠 는 자원 이다. 잘 팔 리 는 자원 과 관련 되면 반드시 경쟁 이 존재 한다.우 리 는 보통 '잠 금' 체 제 를 사용 하여 자원 의 점용 을 제어 합 니 다. 한 작업 이 자원 을 점용 할 때 자원 을 잠 그 고 이때 다른 작업 은 잠 금 의 방출 을 기다 리 고 있 습 니 다.
3. 시스템 호출     프로 세 스 의 사용자 상태 와 커 널 상태: 프로 세 스 는 보통 사용자 상태 에서 실 행 됩 니 다. 이 때 는 CPU 와 메모리 로 작업 을 수행 할 수 있 습 니 다. 프로 세 스 가 하드웨어 외부 설정 을 조작 해 야 할 때 커 널 상태 로 전환 해 야 합 니 다.커 널 은 일련의 시스템 호출 을 제공한다.     사용자 상태 와 커 널 상태의 분 리 는 시스템 의 바 텀 안전성 을 향상 시 키 고 개발 모델 을 간소화 할 수 있다.시스템 호출 은 프로 세 스 가 사용자 상태 에서 커 널 상태 로 전환 하 는 것 과 관련 되 는데 이것 은 일정한 메모리 공간 교환 이 필요 하고 비용 이 많이 든다.     불필요 한 시스템 호출 을 줄 이 는 것 은 웹 서버 의 성능 최적화 에 도움 이 된다 (예 를 들 어 times 와 gettimeofday 호출 을 닫 는 것).4. 메모리 할당     Apache 는 다 중 프로 세 스 모드 로 메모리 풀 정책 을 기반 으로 한 메모리 관리 방안 을 사용 합 니 다.     Lighttpd 는 단일 프로 세 스 모델 입 니 다.     Nginx (Engine X) 는 단일 프로 세 스 모델 로 메모리 사용량 이 적다.Nginx 는 다 중 스 레 드 를 사용 하여 요청 을 처리 할 수 있 습 니 다. 이 는 여러 스 레 드 간 에 메모리 자원 을 공유 하여 메모리 의 전체 사용량 을 크게 줄 일 수 있 습 니 다.이것 은 단계별 메모리 분배 정책 을 사용 하여 필요 에 따라 분배 하고 방출 하 더 라 도 메모리 사용량 을 아주 작은 수량 범위 로 유지 합 니 다.
     Lighttpd 와 Nginx 의 장점 은 주로 네트워크 IO 모델 에 나타난다.     메모리 할당 정책 의 디자인 은 웹 서버 의 병행 처리 능력 의 중요 한 보증 이다.5. 지속 접속 (Keep - Alive)     지속 적 인 연결: 긴 연결 은 TCP 통신 의 한 방식 으로 한 번 의 TCP 연결 에서 다 중 데 이 터 를 지속 적 으로 보 내 고 연결 을 계속 하 는 반면 짧 은 연결 입 니 다.     HTTP 는 무상 태 입 니 다. TCP 긴 연결 에 의존 하지 않 습 니 다. 보통 TCP 연결 로 HTTP 요청 을 처리 합 니 다.긴 연결 을 만 들 려 면 웹 브 라 우 저 와 웹 서버 의 공동 작업 이 필요 합 니 다.      브 라 우 저 는 긴 연결 을 지원 합 니 다: 보 낸 요청 헤더 에 긴 연결 성명 을 포함 합 니 다. Connection: Keep - Alive.      웹 서버 는 긴 연결 을 지원 합 니 다: 아파 치 에서 conf \ extra \ httpd - default. conf 에 KeepAlive On 을 설정 하면 됩 니 다.      긴 연결 의 효과 적 인 사용 에 있어 서 관건 은 긴 연결 시간 초과 설정 에 있 습 니 다. 이 는 브 라 우 저 와 서버 가 공동으로 설정 하고 최소 자 를 기준 으로 해 야 합 니 다.      지속 적 인 연결 동 기 는 연결 횟수 를 최대한 줄 이 고 연결 통 로 를 최대한 재 활용 하 는 것 이다.6. 차단 과 비 차단 은 프로 세 스 가 접근 하 는 데이터 가 필요 하지 않 으 면 프로 세 스 가 기 다 려 야 하 는 지 를 말 합 니 다.차단 이란 현재 IO 작업 을 시작 하 는 프로 세 스 가 차단 되 는 것 을 말 합 니 다. CPU 가 차단 되 는 것 이 아니 라 CPU 는 필사적으로 계산 할 뿐 영원히 차단 되 지 않 습 니 다.    동기 화 와 비동기 화 는 데이터 에 접근 하 는 메커니즘 을 말한다. 동기 화 는 일반적으로 주동 적 으로 요청 하고 IO 작업 이 끝 날 때 까지 기다 리 는 방식 을 말한다. 데이터 가 준 비 된 후에 읽 고 쓸 때 반드시 막 아야 하고 비동기 화 는 주동 적 으로 데 이 터 를 요청 한 후에 다른 임 무 를 계속 처리 할 수 있다 는 것 을 말한다.    동시 다발 정책 의 목적 은 IO 작업 과 CPU 계산 을 가능 한 한 중첩 하여 진행 하 는 것 이다.
 
    이 장 을 보고 저 에 게 보충 해 야 할 지식 을 불 러 일 으 켰 습 니 다. Http, TCP 프로 토 콜 은 깊이 이해 해 야 합 니 다.