Windows 자격 증명효율적인 캐시 사용 비결

Raymond Chen

캐시는 성능을 향상시킬 수 있지만, 올바르게 사용해야 합니다. 대부분의 경우 많은 매개 변수를 사용하여 설정이 가능하지만, 캐시 정책을 아무리 올바르게 설정하더라도 캐시를 올바르게 사용하는 것이 제이 중요합니다.

다음은 실제 이벤트를 기반으로 하는 예입니다. 기본 문제와 관련 없는 기술에 대해서는 자세히 설명할 필요가 없도록 시나리오를 독자가 읽기 쉽게 일부 수정했습니다.

뉴욕에 위치한 회사에 문서 보관소 역할을 하는 중앙 웹 서버가 있습니다. 회사에서는 "2005년 6월 23일에 보관된 Johnson 사건의 기각 청원서 열람 바람" 등과 같이 요청을 보낼 수 있습니다. 문서는 변경되지 않기 때문에 이는 유효한 정적 웹 페이지입니다. 청원서를 업데이트해야 할 경우 원본 문서는 이미 파일로 보관되어 있기 때문에 변경되지 않은 상태로 유지되고 수정본이 파일로 보관됩니다. 원본 청원서를 변경하려면 시계 시스템을 해당 시점으로 되돌려야 합니다. (처리하는 중에 사소한 실수로 기록이 변경되는 경우도 있습니다.)

이 사용 패턴은 캐싱 웹 프록시 서버에 잘 매핑됩니다. 한 사용자가 6월 23일 청원서를 요청한 다음 잠시 후 다른 사용자가 동일한 문서를 요청할 경우 프록시 서버는 두 번째 쿼리에 응답하고 첫 번째 쿼리와 동일한 결과를 제공하여 중앙 서버를 왕복하는 시간을 절약할 수 있습니다.

이 조직에는 캐싱 웹 프록시 서버가 이미 보유하고 있으며 마이애미 사무실에서 해당 서버를 사용하도록 구성했습니다. 하지만 성능 향상이 이루어지지 않았습니다. 프록시로부터 동일한 문서를 여러 번 계속해서 요청하더라도 중앙 서버에서 직접 문서를 요청할 때와 마찬가지로 여전히 느리게 응답합니다. 무엇이 잘못된 것일까요? 프록시 서버가 차단된 것일까요?

실제로 프록시 서버는 정상적으로 작동하고 있습니다. 문제는 프록시 서버가 있는 위치에 있습니다. 마이애미 사무소에서는 뉴욕에 느린 속도로 연결하여 뉴욕 사무소에 설치된 캐싱 웹 프록시를 사용합니다.

그림 1의 다이어그램을 참조하면 프록시의 속도가 향상되지 않는 이유를 쉽게 파악할 수 있습니다. 프록시가 완벽하게 작동하고 중앙 서버에 연결하지 않고 모든 요청을 입력할 수 있더라도 마이애미와 뉴욕 간에 여전히 느린 연결을 통해 문서를 전송해야 합니다.

그림 1 잘못된 위치에서 느린 연결로 접속되는 프록시 서버(더 크게 보려면 이미지를 클릭하십시오.)

캐시를 사용하려면 캐시가 캐싱할 항목보다 더 빨라야 합니다. 이 예에서 마이애미 사무실과 프록시 서버 간의 연결이 마이애미 사무실과 중앙 서버 간의 연결보다 더 빨라야 합니다. 따라서 프록시 서버를 마이애미 사무소에 가깝게 설치해야 합니다. 최상의 결과를 얻으려면 그림 2와 같이 프록시 서버를 마이애미에 설치해야 합니다.

그림 2 마이애미 사무소에 유용한 프록시 설정(더 크게 보려면 이미지를 클릭하십시오.)

프록시 서버가 마이애미에 있을 때 마이애미의 변호사가 6월 23일 청원서를 호출하면 요청이 로컬 프록시로 전달되므로 캐시에서 문서를 빠르게 받을 수 있습니다. 문서가 캐시에 없는 경우 서버에서 문서를 검색한 다음 마이애미 사무실의 다른 사용자가 다음에 요청할 때에 대비하여 캐시합니다.

캐시는 임시 위치를 활용하지만, 프록시를 마이애미 사무소로 이동하면 지역 위치도 사용됩니다. 마이애미 사무소의 변호사는 뉴욕 사무소의 변호사와 다른 문서를 요청하는 경향이 있으므로(서로 다른 사건을 처리하기 때문) 원격 사무실별로 다른 캐시를 유지하면 할당된 사무실에 보다 유용하게 사용될 수 있습니다.

이 조직에서는 마이애미 사무실에 프록시 서버를 설치하고 해당 사무실의 컴퓨터에서 로컬 프록시를 사용하도록 구성했습니다. 이제 만족할 만한 성능을 얻을 수 있습니다.

Raymond Chen은 The Old New Thing 웹 사이트와 동명의 저서(Addison-Wesley, 2007)에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있습니다. 여기서 실용적이고도 유용한 팁을 얻을 수 있습니다.