Nginx 캐시 사용량

웹 캐시는 클라이언트와 "원본 서버" 사이에 위치하여 표시되는 모든 콘텐츠의 복사본을 보관합니다. 클라이언트가 캐시에 저장된 콘텐츠를 요청하면 서버와 통신하지 않고 캐시에서 직접 콘텐츠를 가져올 수 있습니다. #推荐#(추천 학습:

nginx 사용)#🎜🎜 ## 🎜🎜#이렇게 하면 웹 캐시가 클라이언트와 "더 가까워"지기 때문에 응답 성능을 향상시킬 수 있으며, 점점 더 서버가 모든 요청에 ​​대해 페이지를 생성할 필요가 없기 때문에 애플리케이션 서버를 효율적으로 사용합니다.

브라우저와 애플리케이션 서버 사이에는 클라이언트 브라우저 캐시, 중간 캐시, 콘텐츠 전송 네트워크(CDN), 서버의 로드 밸런싱 및 반사와 같은 여러 "잠재적" 캐시가 있습니다. 대리인. 역방향 프록시 및 로드 밸런싱 수준의 캐싱은 성능 향상에 큰 도움이 될 수 있습니다. 예를 들어 작년에 저는 로딩이 느린 웹사이트의 성능을 최적화하는 작업을 맡았습니다. 첫 번째로 눈길을 끈 것은 이 웹사이트가 홈페이지를 생성하는 데 거의 1초 이상 걸렸다는 것입니다. 일련의 디버깅 후에 페이지가 캐시할 수 없는 것으로 표시되었기 때문에 로딩이 느린 이유를 발견했습니다. 즉, 페이지가 모든 요청에 ​​대한 응답으로 동적으로 생성되었기 때문입니다.

페이지 자체는 자주 변경할 필요도 없고 개인화도 필요하지 않기 때문에 실제로는 그럴 필요가 없습니다.

제 결론을 확인하기 위해 5초마다 캐시되도록 페이지를 표시해 두었습니다. 이것만 조정해도 확실히 성능이 향상되는 것을 느낄 수 있습니다. 첫 번째 바이트까지의 시간은 몇 밀리초로 줄어들고 페이지 로드 속도가 훨씬 빨라집니다.

캐싱을 사용하면 대규모 콘텐츠 전송 네트워크(CDN)뿐만 아니라 캐싱을 통해 로드 밸런서, 역방향 프록시 및 애플리케이션 서버 프런트엔드 웹 서비스의 성능도 향상시킬 수 있습니다.

위의 예를 통해, 콘텐츠 결과를 캐싱하면 매번 페이지 생성 작업을 반복할 필요가 없기 때문에 애플리케이션 서버를 보다 효율적으로 사용할 수 있음을 알 수 있습니다. 또한 웹 캐싱을 사용하여 웹사이트 안정성을 향상할 수도 있습니다.

서버가 다운되거나 바쁠 때 사용자에게 오류 메시지를 반환하는 대신 캐시된 콘텐츠를 사용자에게 보내도록 NGINX를 구성하는 것이 좋습니다. 이는 애플리케이션 서버 또는 데이터베이스 오류가 발생하는 경우 웹 사이트가 일부 또는 모든 기능을 유지할 수 있음을 의미합니다.

기본 캐시 설치 및 구성 방법

기본 캐시를 활성화하려면 Proxy_cache_path 및 Proxy_cache라는 두 가지 명령만 필요합니다. Proxy_cache_path는 캐시 경로 및 구성을 설정하는 데 사용되고, Proxy_cache는 캐싱을 활성화하는 데 사용됩니다.

proxy_cache_path/path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m

use_temp_path=off;

server {

...

location / {

proxy_cachemy_cache;

proxy_pass http://my_upstream;

}

}

1. 캐싱에 사용되는 로컬 디스크 디렉터리는 /path/to/cache/

2입니다.levels에는 /path/to/cache에 2단계 설정이 있습니다. / 계층적 디렉터리. 단일 디렉터리에 많은 수의 파일을 배치하면 파일 액세스 속도가 느려질 수 있으므로 대부분의 배포에서는 2단계 디렉터리 계층 구조를 권장합니다. level 매개변수가 구성되지 않은 경우 NGINX는 모든 파일을 동일한 디렉터리에 저장합니다.

3.keys_zone은 타이머 사용과 유사하게 캐시 키와 메타데이터를 저장하는 데 사용되는 공유 메모리 영역을 설정합니다.

키 복사본을 메모리에 저장하면 NGINX가 디스크를 검색하지 않고도 요청이 'HIT'인지 'MISS'인지 신속하게 결정할 수 있으므로 검색 속도가 크게 향상됩니다.

1MB 메모리 공간에는 약 8,000개의 키를 저장할 수 있으므로 위에서 구성한 10MB 메모리 공간에는 거의 80,000개의 키를 저장할 수 있습니다.

4.max_size는 캐시의 상한을 설정합니다(위 예에서는 10G). 이는 선택 사항입니다. 값을 지정하지 않으면 캐시가 증가하여 사용 가능한 모든 디스크 공간을 소비하게 됩니다.

캐시가 이 제한에 도달하면 프로세서는 캐시 관리자를 호출하여 최근에 가장 적게 사용된 파일을 제거함으로써 캐시 공간을 이 제한 이하로 줄입니다.

5.inactive는 항목에 액세스하지 않고 메모리에 보관할 수 있는 시간을 지정합니다. 위의 예에서 60분 이내에 파일이 요청되지 않으면 캐시 관리자는 파일 만료 여부에 관계없이 해당 파일을 메모리에서 자동으로 삭제합니다. 이 매개변수의 기본값은 10분(10m)입니다.

비활성 콘텐츠는 만료된 콘텐츠와 다릅니다. NGINX는 캐시 제어 헤더(이 예에서는 Cache-Control:max-age=120)에 지정된 만료된 콘텐츠를 자동으로 삭제하지 않습니다.

만료된 콘텐츠는 지정된 비활성 시간 내에 접속하지 않은 경우에만 삭제됩니다.

만료된 콘텐츠에 액세스하면 NGINX는 해당 콘텐츠를 원래 서버에서 새로 고치고 해당 비활성 타이머를 업데이트합니다.

6. NGINX는 처음에 캐시에 기록할 파일을 임시 저장 영역에 넣습니다. use_temp_path=off 명령은 NGINX에게 해당 파일을 캐시할 때 동일한 디렉터리에 기록하도록 지시합니다.

파일 시스템에서 불필요한 데이터 복사를 방지하려면 매개변수를 off로 설정하는 것이 좋습니다. use_temp_path는 NGINX 버전 1.7 및 NGINX Plus R6에서 도입되었습니다.

마지막으로, Proxy_cache 명령은 URL이 위치 부분(이 경우 `/`)과 일치하는 콘텐츠 캐싱을 시작합니다. 또한 서버 섹션에 Proxy_cache 명령을 추가할 수도 있습니다. 이렇게 하면 해당 위치에 자체 Proxy_cache 명령이 지정되지 않은 모든 서비스에 캐시가 적용됩니다.

위 내용은 Nginx 캐시 사용량의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!