SilkPerformer - Cache Hit
Updated:
안녕하세요!
이번 글은 SilkPerformer에서 Cache 및 세션을 유지하고 웹브라우저와 같이 Cache를 사용하는 벙법에 대해 알아봅니다.
SilkPerformer Cache control
1. 캐시를 이용한 네트워크 사용량 감소
인터넷 기술의 발전에 따라 조금 더 빠른 컨텐츠 표기를 위해 도입된 기술중 하나가 바로 Cache를 사용하는 것인데요, 한번 다운받은 컨텐츠를 다시 다운받지 않고 보관된 컨텐츠로 대체함으로 인해 다운로드 시간을 줄여 사용자 입장에서는 빠른 웹서핑이 가능하게 됩니다.
일반적으로 웹브라우저(IE기준)에서는 다음과 같은 캐시 옵션을 사용할 수 있습니다.
이 옵션들은 다음과 같은 의미를 가지고 있습니다.
1. 웹 페이지를 열 때 마다
캐싱을 사용하지 않는 옵션으로 웹브라이저를 새로 열거나 웹페이지 새로고침 시 새 버전을 확인해 보여줍니다.
2. Internet Explorer를 시작할 때 마다
인터넷 익스플로러를 새로 시작할 때만 새 버전을 확인하여 캐싱된 정보를 비교하여 새 버전이 없으면 캐싱된 페이지를 보여주고 새 버전이 있다면 사아트의 신규/변경된 웹페이지를 가져와 보여준다는 의미입니다.
3. 자동으로
새로운 버전에 대한 확인을 일정 시간이 지나면 확인하도록 합니다.
이에 대응하여 SilkPerformer에서는 다음과 같은 옵션의 사용이 가능합니다.
옵션 설정은 메뉴 상 ‘Settings > Active Profiles > Replay > Web(Protocol Level) > Emulation’에서 설정할 수 있습니다.
이와 더불어 시뮬레이션 시 주로 같이 사용하는 유저 패턴 옵션과 더불어 살펴보겠습니다.
유저 패턴 옵션은 메뉴 상 ‘Settings > Active Profiles > Replay > Web(Protocol Level) > Simulation’에서 설정할 수 있습니다.
이 옵션을 조합하여 다음과 같이 테스트를 수행할 수 있습니다.
| 유저 패턴/캐시 전략 | Never | One per session | Everytime |
|---|---|---|---|
| Disable | 세션은 Transaction 간 자동으로 유지되며(별도의 세션 처리 없이 특별한 경우가 아니라면 Jsession과 같은 세션은 유지됨) 모든 Transaction에서 캐싱 처리함(단, 첫번째 정적 컨텐츠는 다운로드 받음) 사용자는 문서 캐시를 지우지 않으며 모든 트랜잭션에서 쿠키 데이터베이스를 재설정하지 않습니다. 이미 캐시 된 문서에 대한 조건부 요청(서버 리소스의 변경과 상관없이 요청하지 않음)이 없습니다. |
Never와 동일하게 세션 유지, 캐싱 처리함. 사용자는 문서 캐시를 지우지 않으며 모든 트랜잭션에서 쿠키 데이터베이스를 재설정하지 않습니다. 트랜잭션 요청의 한 실행주기 동안 캐시에서 문서를 찾을 수있는 경우 하나의 조건부 요청 만 전송됩니다. |
단건의 요청 내에서만 캐싱 처리함(각각의 단건은 별개의 캐싱을 함) Never와 비슷하지만 캐시에서 문서를 찾을 수있는 경우 조건부 요청(서버의 리소스가 변경되었을 경우 전송을 요청)이 서버로 전송됩니다. |
| First time user | 정적 컨텐츠 매번 모두 다운로드 받으며, 새로운 Transaction이 시작될 때 마다 쿠키 및 문서캐시를 지움(세션이 끊어짐) 문서는 만료되지 않는 한 캐시에서 검색됩니다. 가상 사용자가 트랜잭션을 수행 할 때마다 Silk Performer 는 쿠키 데이터베이스와 문서 캐시를 지웁니다. 영구 쿠키는 트랜잭션 실행 동안 유지 될 수 없습니다. |
Never와 동일함 대규모 또는 증가하는 신규 고객을 처리해야하는 웹 애플리케이션의 경우이 조합을 선택하십시오. 예를 들어 검색 엔진 또는 대량 소매 시즌에 접근하는 온라인 쇼핑몰. |
Never와 동일함 |
| Revisiting user | 새로운 Transaction이 시작될 때 마다 쿠키 및 문서캐시를 지움(세션이 끊어짐) 트랜잭션이 완료되면 가상 사용자는 비 영구 쿠키를 지우고 모든 연결을 닫습니다. 재 방문 사용자를 트랜잭션이 완료되면 브라우저를 닫고 나중에 임의의 시간을 반환하는 사람과 비교할 수 있습니다. |
Never와 동일하나 조건부 요청 빈도수 차이가 있음 | Never와 동일하나 조건부 요청 빈도수 차이가 있음 |
스크립트 작성 시 전성룡 수석님께서 기존에 작성하신 포스트 중 ‘성능 테스트 도구 알아보기: Silk Performer (3) 스크립트 작성’를 참조하면 Demo 페이지를 통해 쉽게 스크립트 작성이 가능합니다. 아래의 유저패턴 및 캐시 전략은 해당 demo페이지를 통해 확인하였습니다.
2. 유저 패턴 및 캐시 전략
2-1. 유저패턴: Disable, 캐시전략: Never
Transaction 간 자동으로 세션이 유지됩니다. 사용자 정의 세션이 아닌 일반적인 Jsession과 같은 경우 스크립트에서 별도의 처리 없이 Transaction간 세션이 끊어지지 않습니다. 또한, 모든 Transaction에서 정적 컨텐츠를 자동으로 캐싱 하여 두 번째 컨텐츠 부터는 다운받지 않아 URL 맨 뒤에 (cache hit) 표시를 볼 수 있습니다.
2-2. 유저패턴: Disable, 캐시전략: One Per Session
Never와 동일하게 세션을 유지하며 정적 컨텐츠의 캐싱을 지원합니다. 캐시에서 문서를 찾을 수 있을 경우 한개의 조건부 요청만 전송됩니다.
2-3. 유저패턴: Disable, 캐시전략: Everytime
Never와 동일하게 세션을 유지하며 정적 컨텐츠의 캐싱을 지원합니다. 단, 캐싱은 단 건의 요청 내에서만 캐싱 처리하게 되므로 여러 건의 호출이 혼재한 스크립트에서는 각각의 호출 내에서만 캐싱됨을 주의해야 합니다.
2-4. 유저패턴: First Time User, 캐시전략: Never
정적 컨텐츠를 매번 모두 다운로드 받으며(캐시 미 사용), 새로운 Transaction이 시작될 때 마다 쿠키 및 문서캐시를 지웁니다.
이때, Transaction 반복 시 세션이 모두 종료되므로 별도로 세션 처리를 해야 합니다.
2-5. 유저패턴: First Time User, 캐시전략: One Per Session
Never와 동일합니다. 일반적으로 이 옵션은 대규모 혹은 증가하는 신규유저의 웹 애플리케이션에 사용합니다.(ex. 검색엔진, 온라인 쇼핑몰 등)
2-6. 유저패턴: First Time User, 캐시전략: Everytime
Never와 동일합니다.
2-7. 유저패턴: Revisiting User, 캐시전략: None
각 Transaction 실행 후 사용자는 Persistent connections을 닫고 Document history, Persistent cookie database 및 SSL Context cache를 지웁니다.
그리고 모든 Transaction에서 정적 컨텐츠를 자동으로 캐싱 하여 두 번째 컨텐츠 부터는 다운받지 않아 URL 맨 뒤에 (cache hit) 표시를 볼 수 있습니다.
2-8. 유저패턴: Revisiting User, 캐시전략: One Per Session
Never와 동일하나 조건부 요청 빈도수 차이가 있습니다(트랜잭션 요청의 한 실행주기 동안 캐시에서 문서를 찾을 수있는 경우 하나의 조건부 요청 만 전송)
2-9. 유저패턴: Revisiting User, 캐시전략: Everytime
Never와 동일하나 조건부 요청 빈도수 차이가 있습니다(캐시에서 문서를 찾을 수있는 경우 조건부 요청(서버의 리소스가 변경되었을 경우 전송을 요청)이 서버로 전송됩니다)
이상으로 SilkPerformer의 유저패턴 및 캐시전략에 대해서 살펴보았습니다.
성능테스트 시 이 옵션을 잘 조합하면 실 사용자 패턴과 유사한 형태로 테스트가 가능합니다.
단, 모든 옵션에서 반드시 한 번 이상의 정적 컨텐츠를 다운받아야 합니다. 테스트 스크립트 구조 상 Initialize, Action, End 구조에서 초기 사용자를 최대 유저까지 증가하는 Initialize 구간에 정적 컨텐츠의 최초 다운로드로 인한 Traffic이 몰릴 수 있습니다. 물론 테스트 대상 사이트 마다 다를 수 있겠지만 내부 사용자 전용 시스템의 경우 대부분 자주 접속하여 실제로도 브라우저 캐싱을 많이 사용하게 됩니다. 이때 스크립트를 Low-level로 Generate하게 되면 URL 단위로 스크립트가 생성되므로 여기서 정적 컨텐츠를 모두 주석 처리하면 전체 구간에서 정적 컨텐츠의 호출을 막을 수 있습니다.