ATS가 캐싱 전략을 구현하여 동적 서비스 처리량을 늘리는 방법

먼저, 정책 조정 직후의 트래픽 그래프를 살펴보겠습니다.

사용자 경험을 향상시키기 위해 캐시 증폭 비율을 높이는 동시에 고객 신고를 피할 수 있습니다. 캐시를 할 때 엄청 고생한다고 하는데, 대용량 파일은 작은 파일로 분리되어 있고, 동적 컨텐츠와 정적 컨텐츠는 작은 파일로 분리되어 있어서 기본적으로는 동적 컨텐츠만 저장이 안된 상태입니다. 이전 전략에 따르면 동적 콘텐츠는 1:1 진입 및 종료로 직접 프록시되지만 일부 게임은 멈추지 않고 특정 배율에 도달해야 한다고 주장합니다. 문제 없습니다. 동적 콘텐츠에 칼을 사용하기만 하면 됩니다.

본론에 들어가기 전에 먼저 분석을 하고 저장할 수 있는 동적 콘텐츠와 ATS 캐싱 전략에 대해 많은 테스트를 했는데 많은 이점을 얻었습니다. ATS의 현재 캐싱 전략은 HTTP 프로토콜을 완전히 준수하며 가장 보수적인 캐싱 방법을 채택합니다. 즉, 동적, 쿠키, 인증 및 캐시 없음이 명확한 정보만 저장됩니다. ats의 해당 구성 매개변수는 기록되지 않습니다. 품질을 보장하기 위해 위험이 너무 높기 때문에 쿠키 및 승인이 포함된 동적 콘텐츠를 직접 건너뜁니다.

1. 명확한 수명 주기 헤더가 있는 동적 URL 이미지 및 기타 콘텐츠 웹사이트의 헤더 정보는 신뢰할 수 있습니다)

2. 정보가 없거나 마지막으로 수정된 헤더 및 기타 정보만 포함된 명확한 헤더 수명 주기 헤더가 없는 정적 URL 사진, 동적 URL 사진 등.

유형 1의 경우 처리하기 쉽습니다. ats에는 해당 매개변수가 있으므로 열기만 하면 됩니다.

proxy.config.http.cache.cache_urls_that_look_dynamic INT 1

유형 2의 경우 먼저 처리해야 할 기술 작업입니다. 모두 온라인 헤더 정보에 대한 필수 조건은 다음과 같습니다.

proxy.config.http.cache.required_headersINT 2

이에 대한 제한을 완화해야만 두 번째 범주가 포함될 수 있으므로 0으로 설정하는 것이 첫 번째 필수 조건입니다. 예를 들어 인증번호 설정 시 헤더 정보가 없기 때문에 보수적인 전략은 당연히 정상적인 서비스를 제공하지만, 방치하면 반드시 문제가 발생합니다. 분석 후 ats는 헤더 정보 없이 콘텐츠의 캐시 시간을 보장하기 위해 최대 및 최소 캐시 시간을 사용합니다. 두 가지 시간 매개변수는 다음과 같습니다.

proxy.config.http.cache.heuristic_min_lifetime INT 3600

proxy.config.http .cache.heuristic_max_lifetime INT 864000

마지막 수정된 헤더만 있는 정보의 경우 에이징 인자를 통해 계산됩니다.

proxy.config.http.cache.heuristic_lm_factor-v 0.1

그래서 도착 후 콘텐츠를 Pass-through하는 아이디어를 생각해 냈는데, 매번 침을 뱉기 전에 ATS에 IMS 헤더 정보를 원국으로 보내서 변경 사항이 있는지 물어 보도록 요청하세요. 트래픽을 많이 차지하지 않습니다. 변경 사항이 없으면 TCP_REFRESH_HIT가 원본으로 반환되지만 변경 사항이 있으면 TCP_REFRESH_MISS가 계속 출력됩니다. 사용자는 또한 최신 콘텐츠를 얻게 되며, 이는 눈에 띄지 않게 침의 흐름을 증가시킵니다.

매개변수를 어떻게 설정하나요? 위의 모든 매개변수를 0으로 설정하면 이론적으로 목표를 달성할 수 있다는 생각이 문득 떠올랐습니다. 처음 저장한 후 두 번째부터 IMS 헤더를 다시 소스에 요청하기 시작했고 즉시 테스트를 찾았습니다. 테스트 환경은 예상대로였습니다.. 마찬가지로 신나서 바로 온라인으로 전략을 업데이트하고 트래픽 그래프 툴을 통해 1시간 동안 모니터링을 해보았으나, 사용해보니 이상한 현상이 발생했습니다. tsar가 특정 순간에 원점 복귀가 여전히 동일하다는 것을 확인했는데, Traffic_logstats -s로 분석한 결과 ERR_CLIENT_ABORT가 많이 있다는 것을 발견했는데, 이 로그는 정말 끔찍합니다. 클라이언트가 연결 후 데이터 수신을 완료하기 전에 연결을 적극적으로 끊었습니다. 이보다 적으면 정상이고, 많으면 문제가 됩니다. 예, 테스트를 위해 max-age가 있는 1M 이미지를 찾았습니다. 먼저 연결을 컬링하고 바로 연결을 끊으니 이런 오류 로그가 생성되었습니다. 두 번째 방문했을 때 로컬 이미지를 다운로드하고 정상적으로 열었더니 ATS가 계속되는 것으로 나타났습니다. 이 문제를 처리할 때 캐시에 다운로드하려면 이러한 도메인 이름의 품질이 좋지 않기 때문에 반환 트래픽이 매우 높을 수 있습니다. Google에서 계속 정보를 찾아보니 이 항목이 있습니다.

proxy.config. http.ground_fill_completed_thresholdFLOAT 0.5

기본값은 0으로 설정되어 있습니다. 이 매개변수는 다운로드가 특정 비율에 도달하면 다운로드가 갑자기 중단된다는 의미입니다. 아니오 더 생각해 본 후 연결이 끊어집니다. 0.5로 테스트를 하고 바로 업데이트를 했더니 트래픽이 안정되고 처리량도 늘어났습니다.

마지막으로, 온라인 매개변수가 그다지 안정적이지는 않지만, 앞으로도 비즈니스 상황에 따라 테스트를 조정해야 하지만 이것도 재미있는 부분입니다.

모든 조정은 균형을 이루고 있습니다. 1. 디스크 읽기 및 쓰기 IO 증가. 2. CPU 부하 증가.

위 내용은 ATS가 캐싱 전략을 구현하여 동적 서비스 처리량을 늘리는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!