PAC의 응답을 바꾸지 않고 더 빠르게 만들기

겹치는 예외와 대체 경로 순서를 유지하면서 불필요한 PAC 평가 작업을 줄입니다.

“일반적인 경우를 먼저 두라”는 PAC 파일에는 불완전한 조언입니다. 첫 return이 결정을 끝냅니다. 규칙이 겹치면 그 순서가 라우팅 정책의 일부입니다.

한 서비스에는 사설 프록시를, 그 도메인의 나머지에는 직접 경로를 쓰는 경우를 생각해 봅시다:

function FindProxyForURL(url, host) {
    host = host.toLowerCase();
    if (host === 'restricted.example.net') {
        return 'PROXY proxy.example.net:8080';
    }
    if (dnsDomainIs(host, '.example.net')) {
        return 'DIRECT';
    }
    return 'PROXY proxy.example.net:8080';
}

이름은 예시입니다. 넓은 접미사 검사를 정확한 호스트 예외 위로 옮기면 제한된 서비스가 직접 나갑니다. 스크립트는 더 짧거나 빨라질 수 있지만 잘못된 일을 합니다.

우선순위를 잃지 않고 조건 묶기

큰 목록이 정말 같은 등급의 정확한 호스트 이름 집합이고 결과가 하나라면, 적절한 조회 구조가 반복 패턴 검사보다 명확할 수 있습니다. 그 동등성은 먼저 입증해야 합니다. 정확한 이름, wildcard, 주소 범위 규칙은 자동으로 하나의 교환 가능한 집합에 속하지 않습니다.

마찬가지로 두 이름이 의도적으로 다른 경로를 쓴다면 www. 를 제거하는 것은 정책 변경입니다. 문자열 비교 최적화가 목적지를 조용히 재정의해서는 안 됩니다.

결정에 필요 없는 비싼 작업 제거하기

호스트 이름 동등성 검사에는 DNS가 필요하지 않습니다. 나머지 정책이 주소를 필요로 할 때만 확인하고, 지원되는 PAC 환경이 재사용을 허용하는 곳에서는 한 번의 평가 안에서 같은 조회를 반복하지 마십시오.

파일 옆에 예상 결정을 몇 가지 두십시오. 특정 예외, 넓은 접미사 아래의 형제, 무관한 호스트 이름, 관련 주소 리터럴입니다. JavaScript가 파싱되는지만이 아니라 반환된 경로와 모든 대체 항목의 순서를 비교하십시오. 그 결과가 일치하면 브라우저가 수정된 PAC를 로드했는지 확인하십시오.

같은 사례가 의도한 경로를 유지하고 불필요한 평가 작업이 사라질 때 성능 개선은 설득력이 있습니다. 넓은 DIRECT 지름길은 출구 IP를 바꾸면서 지연을 없앨 수 있습니다.

관련 글