Marauder: Synergized Caching and Prefetching for Low-Risk Mobile App Acceleration

2021 / 10 / 1 iMES 세미나

Abstract

• 모바일 app -> user로의 experience : 적은 상호작용 반응시간이 중요
  • 그러나, network latency를 완화하기 위한 전략이 현재는 부족
    • caching : resource의 content가 변경될 때의 만료시간 등의 문제점
    • prefetching : user의 행동의 정확한 예측을 미리 하기 어려움
• Marauder 제안 : 위 2개의 기법을 시너지화 ( 장점 +, 한계 - ) -> 달성된 속도를 더욱 향상
  • interaction을 처리하는 기법임 ( app이 load할 resource set을 완전히 구조화된 text resource로 download / 파싱 ) -> app binary로 consult할 필요를 없앰
  • app의 cache에서 2가지의 low-lisk 최적화 소개
    • 캐시된 text file에 따라, 이미 트리거된 interaction 중에 참조된 resource를 prefetching
  • 하는 일
    • 만료 예정인 resource를 현명하게 prefetching
    • 변하지 않는 resource의 수명 연장
    • 가벼운 text file ( 가볍지만 중요함 ) 에 대한 업데이트 download
  • 효과
    • 데이터 사용량은 18% 정도 증가했음
    • 대신 interaction 응답 시간을 27% ~ 43% 정도 감소시킴

Introduction

• 스마트폰 사용자가 사용하는 시간의 80%를 app에 사용할 만큼 app은 지배적임
  • app의 성공 요인 : 낮은 반응시간 / user가 인식하는 latency
  • 100ms에도 부정적인 느낌 / 2~3초면 심지어 app을 삭제하기까지 시도
    • user 측면 / 개발자의 수입 등에서도 좋지 않은 영향을 미칠 수 있다
• 응답성 향상에 대한 연구는 많이 진행됨, 그러나 저조했던 성적 ( 2.9초 )
  • network 전송 delay가 주요 원인임은 파악
• network delay가 app 응답시간에 미치는 부정적인 영향을 완화하기 위한 2가지 방법
  • caching : server에서 streaming된 HTTP header를 기반으로 동작
    • app : 정적 resource의 local 복사본을 저장 / 이후 이것이 변경되기 전까지 fetching을 막을 수 있음
    • 기존의 기술들은 최적과는 거리가 있음
    • 원인 : content가 시간에 따라 달라지는 속도의 차이 때문에, 개발자들이 보수적인 TTL ( time-to-live ) 를 사용하기 때문 // content의 변경을 완전히 통제하고 오래된 content의 loading 방지
  • prefetching : 이후의 user interaction을 미리 예측하고 client cache에 저장하는 기법
    • 단점 : user가 어떤 interaction을 할지 정확한 예측이 불가능함 ( 한계 존재 )
    • 잘못된 예측 -> bandwidth와 energy 낭비
  • 위의 2가지 모두 효율적이지만 기본적으로 drawback이 존재 ( 한계 있음 )
• Marauder 제안 : caching + prefetching / 각 기술의 합으로 속도 향상 + 위험요소 회피할 수 있는 시스템
  • insight : mobile app이 client측 binary의 설치에도 불구하고 web page의 load와 유사한 모델로 user interaction에 respond한다는 것
  • 추가로, 이전에 가져온 text file로부터 분석을 통해 후속 request를 찾아냄
    • 본문 파일 : app binary 대신 text file을 분석 -> pure하게 참조 가능한 URL을 도출할 수 있도록 구조화되어있음
  • app cache에서 직접 app responce를 최적화함 ( 2가지 방법 존재 )

Caching for just-in-time prefetching

• marauder : text file의 구조 활용 ( 현재 interaction 중에 사전 fetching함 )
  • 잠재적으로 부정확한 ‘user의 미래 예측’ 방식을 사용하지 않음
  • 방법 : download된 text file을 정적 분석 -> 참조된 URL 목록 추출 -> factor 처리 ( 동적 쿼리 문자열 / 관련 URL )
  • 이후 interaction이 시작될 때 선택권이 있음
    • 캐시에서 text file 제공
    • network 상에서 text file 가져오기
    • marauder : 참조하는 resource에 대한 비동기 prefetch 요청 발행
      • 위험도가 낮은 방식 ( 명시적으로 요청되어 처리되어질 file들에 대한 resource만을 사전에 저장하기 때문 )
      • 유용함 ( 해당 text file이 download되고 구문 분석이 되기 전까지는 참조 resource를 가져올 수 없음 )

Prefetching to improve the efficacy of cached resources

• TTL ( time-to-live ) 의 설정이 어려움 // resource들이 content의 변화가 없더라도 캐시에서 만료되는 상황 발생
  • marauder : TTL 확장 ( about-to-expire ) -> 곧 만료될 resource를 사전에 prefetching ( 이미 캐시된 content의 효율 극대화 )
    • 그러나 미래에 어떤 resource가 요청될지 모르므로 bandwidth의 낭비 가능성이 여전히 있음
    • risk 해결을 위해 하이브리드 접근법 사용
      • HEAD 요청 ( payload 발생시키지 않음 ) : content가 변경되지 않은 non-text resource에 대해 TTL 확장
      • 조건부 GET 요청 : text resource에 대한 content update를 우선적으로 download
    • 위 전략 : text file의 중요성 활용
• 현재 즉시 배포 가능 ( Link )
  • end-to-end HTTPS 보안 보존
  • 개발자가 server / app binary / 휴대폰 OS 등을 수정할 필요는 없음
  • app의 caching library를 marauder만의 최적화 내장 버전으로 대체한 것일 뿐임
  • 최적화를 위해 app 기능을 깨거나 / user에게 표시되는 content의 변경 등은 없음
  • app이 최신 resource를 모두 load함
• 평가 preview
  • 환경 : 인기 app / 실제 휴대폰 / live network / server / 현실적인 user interaction 추적 등을 다르게 평가
  • 결과
    • responce 시간 27.4% ~ 43.5% 감소시킴
    • bandwidth overhead는 18% 정도 추가로 소모 ( 무시할 만한 overhead라고 표기 )
    • 최근의 prefetching보다 2.1x 더 많은 이점을 제공
    • 91% 더 낮은 data overhead 부과

Methodology

Apps used

• 구글 플레이스토어에서 여러 분야의 app을 크롤링
• Marauder를 적용하기 위해서 50개의 대중적인 OkHttp 캐싱 라이브러리의 모호하지 않은 버전을 사용하는 app에 중점

User interaction traces

• 유저 상호작용 패턴 : 앱 성능과 네트워크 가속 기술의 효능에 영향이 큼
• 현실적인 interaction 추적을 위해 휴머노이드 앱 테스트 프레임워크 사용
  • 휴머노이드 : deep neural network 사용 -> 실제 유저 추적에서 interaction 패턴 학습 -> 실제 사용자처럼 새로운 앱과 UI 탐구
• 휴머노이드 session의 output : 일련의 수행해야할 action과 action 사이의 delay를 지정하는 trace
• 각 app에 대해 20개의 trace 생성
  • 각 trace : 20 click의 중앙값 포함 / 유저 세션 시간의 이전 report와 일치하기 위해 2-3분 지속

Running experiments

• 각 app에 대해 기본 APK / Marauder를 내장한 변형을 고려
• 사용 기종
  • Google Pixel 4
  • Samsung Galaxy Note 9
  • 성능에는 큰 차이가 없을 정도 ( 경쟁가능 )
• 실험 방법
  • app마다 5개의 user interaction 무작위 선택 / δ분 간격으로 적용
  • δ : 10분 ~ 1일 사이의 간격 지정 ( 기본값 : 60분 )
• 실험 중
  • app : 신호 강도가 센 것 ( 홈 WiFi, Verizon LTE 등 ) 네트워크를 사용하여 live origin 서버에 접속
  • app content와 network server delay를 공정하게 비교하기 위해, 각 trace를 back-to-back으로 진행
  • 중점 : 후속 interaction을 가속화하는 것 -> 첫번째 trace는 무시 ( cache를 prime하는데 사용하기 때문 )
• 각 trace : distinct한 상호작용 session을 나타냄
  • 후속 trace의 상호작용의 하위 집합 cold cache를 경험할 것
    • cold cache : 비어있음 -> 어떠한 값도 없고 어떤 speedup도 줄 수 없음
    • warm cache : 어떤 값이 있고, 특정 speedup을 줄 수 있음

Performance metrics

• 성능 측정 기준
  • 상호작용 응답 시간 (IRT)
  • 사용자가 interaction을 trigger하기 위해 스크린 tab을 실행하는 시간
  • interaction이 최종 화면에 완전히 렌더링되는 시간 사이
• IRT 측정 방법 : 각 interaction에 대한 각 전화기 화면을 기록
  • screen-cut tool을 이용하여 화면 비디오를 처리 // 화면이 시각적으로 멈춘 것을 track하기 위함
  • Speed Index와 같은 웹 성능 metric에 사용되는 기술들로 dynamic pixel / 설계에 따라 지속적으로 변경되는 pixel 등을 식별 / 제외

The State of App Performance

• network delay가 app 반응성에 미치는 부정적 영향을 정리

1. Background on App Operation

• 각 interaction : 이벤트 handler / callback을 호출 ( app binary에 정의되어있음 )
  • 각 event handler : 특정 event에 대응 + 결과 화면을 띄움 ( 이미 download한 정보를 이용해서 )
• request : 대부분 HTTP 방식 사용
  • server로부터 정보를 받은 후, handler가 logic을 이용해 이것을 처리 ( download 파일에 있거나 app binary에 존재 )
• 위 프로세스는 최종 화면이 뜨기까지 재귀적으로 실행되어짐
• app : 종종 타사의 캐싱 라이브러리 사용 -> app과 server 간의 발행된 request를 download하거나 응답 중재
  • 이전에 download된 응답은 캐싱 가능성에 기준하여 동일한 resource에 대한 후속 request를 처리하는데 사용되어짐
    • 서버 : 해당 resource에 대한 TTL 설정하여 header로 전송 ( resource가 안전하게 재사용될 수 있는 시간 )
• 캐싱 라이브러리 : 표시된 resource와 TTL이 만료된 resource를 모두 저장 중
  • 변경된 경우에만 content를 다운받도록 GET 요청 발행
  • 중복 data 전송을 제거하였지만, fetch latency는 제거하지 못함

2. Motivation

Mobile app interactions are too slow

• 상호작용 반응시간 ( IRT ) 비교
  • WiFi : 1.6 ~ 3.7초
  • LTE : 2.9 ~ 6.7초
• 사용자가 참을 수 있는 2 ~ 3초를 훨씬 초과하는 수치임

Network delays are key contributors

• app 응답시간 : 2가지 이유에 의해 정해짐
  • content를 fetch할 때 발생하는 network delay
  • content를 파싱 / 렌더링하기 위한 client 측의 연산 delay
• 네트워크 delay가 0ms인 상태로 진행 ( interaction마다 2번 실행해서 상황을 강제시킴 )
  • 특정 app request에 고유한 비결정성에서 불구하고, 2차 실행에서 높은 cache hit rate를 보장하기 위해, URL이 불일치하더라도 캐시된 resource를 제공하기 위해 안전한 시나리오 식별
• 결과
  • 휴리스틱에도 불구하고 9%의 resource가 캐시에 들어가지 못함
  • resource에 대한 network delay를 제한하기 위해, low-latency 무선 네트워크를 이용하여 origin server를 relay
  • network delay가 전체 IRT의 38% ( WiFi ) / 64% ( LTE ) 차지

3. Limitations of Existing Optimizations

• app의 APK 또는 origin server가 지정한 캐싱 / 프리페칭이 사용됨
  • 응답시간이 너무 오래 걸림
• 최적화가 얼마나 잘 되었는가? 얼마나 효과적으로 적용되었는가?

1. Caching

Caching is widely used and helps

• 74% 정도의 resource가 서버에 의해 캐싱되어질 수 있음을 보임

• 실제 리소스 type마다 캐싱되어질 수 있는 여건이 달라짐

  Resource Type	% of resource cacheable	% of bytes cacheable
  Images	85.3%	99.9%
  HTML	44.7%	94.9%
  JSON	64.6%	42.5%
  CSS	100%	100%
  Javascript	67.6%	96.2%
  XML	90.2%	60.7%
  Binary	98.2%	93.0%

  • byte와 resource의 캐싱 가능성 불일치 이유 : single-pixel tracking image ( 캐시 불가능 )

• 성능 증가율

  • 28% 적중률 향상 / 44% 속도 향상

Current caching is suboptimal

• 기존 정책과 최적의 캐싱 전략과의 비교
• 리소스 내용이 변경될 때까지의 시간 = 이상적인 TTL 결정
  • 이상적인 TTL과의 상호작용을 재생하기 위해 network delay가 없는 환경에서 평가
• 결과
  • 최적의 캐싱 전략이 기존 캐싱 전략보다 적중률 2.1x 증가
  • 최적의 캐싱 전략이 기존 캐싱 전략보다 중앙값 IRT를 32% 감소시킴

The problem

• 기존 캐싱 관행 : 개발자가 각 리소스에 대해 TTL을 명시적으로 설정해야함
  • 각 리소스마다 이상적인 TTL이 변하므로, 설정하는 것이 어려움
  • 가장 이상적인 TTL 표준편차 : 2시간
• 개발자는 tradeoff에 직면하게 된다
  • 개발자가 보수적 -> 이상적 TTL를 낮게 설정 ( content에 대한 업데이트를 신속하게 전파하기 위함 )
    • 단점 : 최소 TTL보다 이상적인 TTL이 큰 기간동안 캐시 적중 횟수를 많이 포기함
  • 이상적 TTL 스펙트럼보다 더 높은 값을 설정 ( 캐시 적중률 개선 )
    • 단점 : 오래된 버전의 리소스를 사용할 수도 있는 risk
• 개발자들은 기본적으로 최신 content 활용을 보장하기 위해 보수적인 TTL을 선정함

2. Prefetching

Prefetching is less common

• 사용 앱의 6%가 WiFi 연결이 되있을 경우 prefetch가 가능 ( news 카테고리 앱이였음 )
  • 앱의 홈 화면에서 참조하는 text 기사를 정기적으로 다운로드
  • 사용자에게 prefetch 시간 간격 / 다운로드된 content / prefetching 실행 조건 설정 등 수동적으로 정책을 변경할 수 있도록 지원
  • 비활성화할 수 있도록 선택도 가능하게 둔 앱도 있음
• 지금까지는 각 앱에 대한 기본 prefetching 정책을 고려했음
  • prefetching에 대한 전체적인 관점을 개발하기 위해 각 앱이 지원하는 모든 prefetching 정책에 따라 실험 재설계

Prefetching can help

• prefetching을 쓰는 것이 완전한 비활성화보다 59.3 ~ 82.4%의 IRT 중앙값을 향상시켰다

The problem

• prefetching : 사용자가 미래에 어떤 요청을 할지 정확한 예측이 중요
  • 이전의 많은 연구가 이 부분이 어렵다는 것을 강조했음
  • prefetching을 지원하는 상당 앱 : 많은 양의 content를 가져옴 ( 상당부분 사용되지 않음 )
    • 속도 향상은 잠재적으로 되지만, 리소스 사용 측면에서는 매우 낭비
    • 위의 낭비는 높은 cellular data 계획 비용을 초래 + IRT 속도 향상을 없애버림
• 실험에서, 앱에 의해 지원되는 가장 보수적인 prefetching 정책 : 중간 bandwidth 낭비를 6.7%로 만듬 // 겨우 9 ~ 13%의 속도 향상

Design of Marauder

• Marauder : 모바일 앱 가속 프레임워크 - 2개의 기술의 위험과 한계를 회피하는 방식으로 caching과 prefetching의 힘을 집단적으로 활용
  • key idea : 이미 캐싱된 object에 대한 utility 극대화하기 위해 현명한 prefetching 사용 + 캐싱된 object를 이용하여 just-in-time prefetching을 가이드
  • 주요 원칙 : 기존의 앱 / 서버 및 OS와의 직접적인 배치 가능성을 보장하는 것

1. Guiding observations

Observation 1

• 오늘날 앱이 user interaction에 반응하는 방식 : text file이 상호작용에 필요한 non-text 리소스를 가져옴
  • non-text 리소스의 94%가 text file로부터 파싱되어질 수 있다
  • client측 binary를 설치했음에도 앱은 전에 가져온 text 리소스를 구문분석 / 후속요청 ( 웹페이지 load와 유사 )
  • text file : 참조된 리소스를 명확하게 설명하도록 구성되어있음
    • 임의 data blob : app binary만 해석 가능함
• text file이 app에 의해 구문분석되고 실행되고 있음 -> 앱의 캐시에서 직접 참조된 file에 대한 prefetch 요청을 할 수 있다
  • 이러면 text file의 초기단계 파싱 / 실행 delay가 non-text file들에 대한 network latency와 중첩될 것
  • JIT prefetching은 low-risk이다 : 명시적으로 요청되었고 / 구문분석이 임박한 file에 대한 직접 나열된 resource만을 고려함
  • 그래도 성과가 있을 것
    • 텍스트 파일이 앱에 제공되는 시간과 첫 레퍼런스된 파일이 요청되는 사이의 latency가 230ms ( 무시할 수 없는 수치 )
    • 위 공백동안 네트워크는 완벽히 유휴상태임 ( text file은 app이 가져와야하는 다른 file set를 지시하기 때문 )

Observation 2

• TTL이 보수적으로 설정되는 경우가 많음 ( 리소스의 TTL이 만료되었어도 변하지 않는 경우가 존재 47% )
  • TTL 중앙값이 최적 값보다 1.5시간 낮은 값으로 설정됨
• 추가 목표 : TTL이 변경되지 않았을 때 TTL 확장을 희망하며 곧 만료될 리소스를 prefetch하는 것
  • 위험도가 있음 : 리소스가 미래에 요청이 될 것인지 / 지출된 bandwidth가 정당화될 것인지 알수 없음
• risk 완화를 위해, root resource인 text file이 높은 우선순위 / 경량이라는 사실에 주목
  • Marauder : TTL를 확장하려고 시도하는 동안 변경된 text file에 대해서만 업데이트 우선 다운로드 / byte 소모가 크고 interaction 처리 과정에서 차단하지 않는 다른 리소스의 업데이트는 다운받지 않음
• text file이 아닐 경우, content가 바뀌었는지만 확인 ( 서버와 payload를 교환하지 않음 )

Observation 3

• text 파일에 의해 참조된 파일 set : text file의 변화가 생기더라도 오랜 기간 안정된 상태 유지
  • 앱 캐시에 있는 최신 text file과는 관련이 없음
  • interaction에서 content dynamism의 미세한 유연성을 유지하기 위해, HTTP 헤더에서 캐싱 불가능 지정하여 text file을 항상 새로 유치시킴
    • text file은 앱의 캐시에 유지되지만 앱에 제공되지 않음 ( origin server와의 조건부 검사 의무화 )
    • 후속 요청 : text file의 구문분석에 의해 + 해당 파일의 유효성 검사를 위해 network로부터 fetch하는 것에 의해 차단되어짐
  • delay 완화 : text file이 검증 / 업데이트되고 파싱되는 동안, 캐싱할 수 없는 text file에 의해 참조된 파일에 대한 prefetch 요청을 발행

Summary

• 낮은 risk로 캐싱 + prefetching 속도를 강화할 수 있는 기회 제공

2. Background Operation

• 첫 배경작업 : 캐시된 리소스 refresh -> 전반적인 캐시 적중률 향상
  • 0이 아닌 TTL를 가진 캐시의 리소스마다 Timer event 추가 ( 만료시 리소스의 content의 변화가 없는지 / TTL이 확장될 수 있는지 )
  • text file과 non-text file은 다른 방식으로 TTL 확장 프로세스 수행
  • Marauder : 수정되지 않은 서버에서도 사용하고 있는, HTTP 요청 형식 + 캐시 업데이트 방법을 사용
  • text file의 경우
    • 서버에게 이전에 사용한 HTTP 헤더를 사용하여 조건부 GET HTTP 요청 발행
    • HTTP 캐시 유효성 헤더 중계 -> 캐시된 리소스의 버전 식별
    • 응답을 받은 경우, Marauder는 2가지 선택이 가능함
      • 리소스가 변경되지 않았다는 알림을 받은 경우 : 캐시된 리소스의 TTL을 수정 ( 응답 헤더에서 지정된 기간만큼 )
      • 리소스가 변경되었다는 알림을 받은 경우 : 캐시된 리소스를 새 버전과 HTTP 헤더의 TTL로 교체
  • non-text file의 경우에도 위와 같은 방식으로 적용
    • Marauder : 미래에 요청되지 않을 수 있는 리소스의 업데이트에 사용되는 bandwidth 낭비를 최소화하기 위해, 조건부 GET 회피 ( HTTP HEAD 요청 사용 )
      • 원본 서버가 리소스의 현재 버전에 대한 정보를 공유할 수는 있지만, content가 변경되었을 때 캐시된 리소스를 업데이트하지는 못함
      • HEAD 요청 : GET 요청과 달리 캐시 유효성 검사 헤더를 포함하지 않음 ( 대신 클라이언트가 캐시된 리소스의 유효성을 결정할 수 있도록 response에 내장시킴 )
      • HEAD 요청에 대한 응답을 수신하면, 캐시 검증 헤더값을 캐시된 리소스 버전에 대한 값과 비교
        • 변경되지 않았다면 TTL 확장
        • 변경되었다면, 캐시된 리소스를 업데이트하지 않음 ( 캐시에서 제거하지 않고 캐싱 라이브러리의 기본 제거 정책에 따름 )
• 또 다른 배경작업 : 텍스트 파일에 의해 참조된 리소스의 online prefetching을 용이하게 하는 것
  • 앱 캐시에 텍스트 파일이 추가될 때마다 worker thread를 생성 ( 참조된 URL 검색 / 텍스트 파일의 본문 파싱 )
    • text file 정적분석 -> URL과 유사한 모든 문자열 검색
  • 각 entry는 절대경로 / 상대경로 로 URL이 나타남 ( 상대경로의 경우 root는 text file의 hostname / protocol을 채택하는 경우가 대부분 )
    • Marauder : 상대경로를 절대경로로 변환하려고 함
• 최종 목표 : URL이 클라이언트 상호작용 중에 app이 요청하는 방식으로 정확하게 나열될 수 있는가?
  • app이 시간 / 날짜 / 위도 / 경도 / 화면크기 / 리소스 품질 / 크기 등의 속성을 나열한 쿼리 매개변수로 절대경로 URL을 augment할 수 있음
  • 대신 위의 파라미터가 누락 또는 잘못되면 cache miss 발생 -> prefetching 중에 bandwidth 낭비
• 특정 쿼리 문자열 ( 리소스 크기와 관련된 것 ) : URL과 함께 정적으로 나열되는 경우가 많음 -> 앞의 단계에서 capture됨
  • 다른 쿼리 파라미터 : 본질적으로 동적 -> client interaction 중에 채워짐
  • 위 경우를 처리하기 위해, 주어진 원본에 대한 동적 쿼리 파라미터 유형 set이 주어진 리소스 type에 대한 모든 request에서 전적으로 공유되고 있음을 확인
    • 12%만이 다른 동적 쿼리 파라미터를 사용하는 것으로 확인됨
  • Marauder : 동일한 content 유형 및 origin을 가진 캐시된 리소스를 식별 / 대응하는 동적 쿼리 파라미터를 URL에 추가 ( prefetching 시간에 채워짐 )
• 특정 text file : 후속 interaction 이후에만 가져와야 하는 리소스 set을 설명
  • 이런 경우, 후속 interaction은 자신의 handler 설명을 mark함
  • Marauder : 미래 interaction을 예측하지 않고 이미 trigger된 interaction에 대해 JIT prfetching 수행 -> 미래 interaction과 관련된 URL을 prefetch할 참조 리소스 목록에 포함하지 않음

3. Handling Client Requests

• 인터렉션 중에는, 앱의 request가 캐시를 평소처럼 hit함
• 3가지 잠재적 시나리오 ( Marauder와 다른 workflow )
  • 첫 text file 요청 or non-text file 요청인 경우, Marauder는 즉시 network를 통해 요청 발송
    • 응답 수신한 경우 content를 app으로 보내고 / 캐시에 추가 / text file인 경우 참조 URL을 확인하기 위해 background 작업 시작
  • 앱 캐시에 입력된 text file 요청의 경우, Marauder는 해당 content로 앱에 응답 / 해당 text file로부터 참조되는 모든 file에 대해 즉시 비동기 prefetching 요청 발행
    • prefetching : 앱 캐시를 먼저 통과 -> 이미 캐시된 리소스가 다시 다운로드되지 않도록 보장
    • prefetch 요청을 하기 위해, 먼저 동적 쿼리 파라미터 값을 채움 -> 이후 2가지 예외를 제외하고는 text resource 요청에 사용된 동일한 request header set을 적용
      • text와 참조 file의 내용 유형이 다를 수 있으므로, “Accept-Encoding” 등과 같은 협상 헤더는 사용하지 않음
        • 위 값은 기본 캐싱 라이브러리에서 설정될 수 있도록 연기함
      • “Referer” 헤더 추가 ( 텍스트 리소스 나열 )
        • client가 수행하는 특정 interaction과 관련하여 server에 대한 context 제공
    • 특정 동적쿼리 파라미터 값의 불일치를 허용 ( 동일한 interaction 중에 prefetch된 버전에 대한 리소스 앱의 명시적 요청을 보장하기 위함 )
  • 앱 캐시에서 누락되었지만 캐시 없음으로 표시된 항목과 관련된 text file 요청의 경우, text file에 대한 요청과 참조된 모든 하위 항목에 대한 prefetching 요청을 차례로 실행
    • text file이 특정 prefetch된 리소스보다 먼저 도착하는 경우, app이 이미 뛰어난 prefetching request가 있다는 것을 명시적으로 만드는 후속 request 대기
    • 이 방법으로 중복 요청과 bandwidth 낭비를 피함
    • 대기 요청 : 해단 prefetch된 response가 도착하자마자 service

4. Discussion

Preventing storage overheads

• 캐싱 라이브러리 : 자체 제거 정책을 사용 ( LRU 방식 사용중 )
  • 캐시 공간이 필요할 때, 가장 먼 과거에 사용되었던 리소스를 삭제하는 방식
  • Marauder : 리소스 요청을 통해 캐시 항목을 새로 고치거나 / client가 요청하기 직전에 미리 가져옴
    • 마라우더의 요청은 캐싱 라이브러리의 리소스 access 빈도 부기를 무시 ( 리소스 access 패턴을 왜곡하지 않고 덜 중요한 리소스도 보존되도록 app 제거 방식을 변경하지 않도록 하기 위함 )
    • 이 방법을 쓰면 marauder는 앱이나 캐싱 라이브러리의 storage overhead를 추가하지 않음 ( 이전에 그들이 하던대로 제거 진행 ) / 리소스가 제거되지 않도록 지속적으로 재설정하지 않도록 보장

Preserving application behavior

• Marauder : HTTP GET / HEAD 요청 유형을 사용 -> 안전한 방법으로 정의되어있음 ( 서버의 상태를 바꾸지 않음 )
  • 의도된 app 행동에 해를 끼칠 위험이 없음 + 웹크롤링 / 캐시 최적화 / prefetch 등을 가능하게 함
  • Marauder의 최적화는 app의 기능에 영향을 미치지 않아야한다
• HTTP 캐싱 헤더를 통해 개발자가 선정한 TTL을 존중 ( 수정할 이유는 없음 )
  • 캐시에서 prefetch되거나 업데이트되는 각 리소스에 대한 캐시 관리는 리소스에 대한 최선 요청 동안 캐시 만료 헤더를 반영 ( 리소스는 TTL이 만료될 때까지만 client에게 제공 가능 )
  • 항상 최신 버전의 리소스를 제공할 수는 없지만, 모든 리소스는 앱 개발자가 사용할 수 있는 것으로 표시됨

Generalizability and future outlook for Marauder

• 최적화 : client측 app <-> server 간의 text 기반 통신 ( 캐시에서 만료되는 text resource ) 를 우선적으로 업데이트
  • 이 리소스를 사용하여 지속적인 interaction을 위해 사전에 필요한 다른 resource를 결정
• 이 방식을 app들이 계속 사용할 것임을 기대함
  • 많은 app들이 시작 이후 10년동안 ecosystem을 최적화 / 변경 / 수렴
  • text 기반 통신은 text 파일을 해석하여 웹 브라우저에서 가져올 리소스를 결정할 수 있음
• 그러나 이후에 text를 사용하지 않거나 app들의 관행이 종료될 경우, 위대로 사용하는 것은 힘들 것
  • HTTP 헤더에 참조된 URL를 명시적으로 지정하도록 하여 JIT prefetching을 덜 사용하는 방법으로 사용할 수 있음을 주목할 것

Implementation

• OKHttp 캐싱 라이브러리 V 3.12.0 사용
• 2500줄의 코드 ( low-risk 캐싱 / prefetching 최적화 지원 목적 )
• 일정한 access 시간으로 우선순위 큐에서 새로고침이 필요한 캐시된 리소스에 대한 참조 저장
  • Java Executor Service를 이용하여 새로고침 시행 ( TTL 확장 / 텍스트파일 업데이트 )
• JIT prefetching : LinkedIn URL 검출 라이브러리의 도움으로 참조된 리소스 발견
  • 명시적 user request 처리를 차단하지 않기 위해, 캐싱과 prefetching 작업이 별도 worker thread로 작동함
    • 캐시 refresh : 백그라운드에서 작동
    • JIT prefetching : 비동기적 수행
  • 네트워크 및 CPU 리소스가 interaction당 수백개의 리소스를 사용할 수도 있음
    • 복잡한 app에 대해 요청을 과도화하지 않도록 요청 수를 32개로 제한
• 앱을 수정할 때에는 apktool을 사용함
  • 파일을 분해 후 OkHttp의 라이브러리를 Marauder로 교체한 후 실험 진행

Evaluation

• 다양한 앱 / 모바일 네트워크 상황 / 핸드폰 기종 / 실제 사용자 상호작용 trace 등을 다르게 하며 평가
• 결과
  • 각 app마다 상호작용 반응시간을 27.4 ~ 43.5% 감소시킴
  • 데이터를 18% 더 사용함
    • 데이터 사용량을 3%까지 최소화시키는 캐시 새로고침 최적화만 사용하면 59%의 이익 달성 가능
  • 다른 prefetching 시스템보다 2.1x 더 빠른 속도 향상 / 91% 낮은 data overhead 부여
    • 데이터 overhead가 비슷한 기술과의 속도차이는 3.3x배

1. App speedups

• 기본 캐싱 / prefetching 정책에 비해 IRT를 낮출 수 있다
  • LTE에서는 19.8 ~ 27.4% ( 0.58 ~ 0.81초 ) 감소시킴
  • WiFi에서는 퍼센트에이지가 약간 감소하지만, 결과는 향상이 맞음 ( 네트워크 delay가 낮아지기 때문 )
• 사용자 세션 사이의 시간이 증가할때 개선사항이 더 잘 보임
  • δ가 커질수록 Marauder가 필요한 리소스의 회수를 가속화할 수 있는 기회가 더 많아짐
  • 반대로 기존 정책들은 client의 캐시에 있는 리소스가 줄어들 것이라는 것을 의미
• 캐시 miss : 캐시된 entry를 새고 고치거나 non-text 내용이 변경된 후에 후속 interaction 중에 미리 prefetch하는 marauder에게 가속기회를 더 제공하는 것

2. Analyzing Marauder

Ablation study

• 백그라운드 캐시 새로고침 : marauder 이익에 가장 큰 기여자
  • 이미 캐싱된 리소스의 적중률 향상 목적
  • 13.3 ~ 16.1%의 속도 향상을 보여줌
    • 반대로 JIT prefetching하는 것은 3.4 ~ 8.6%의 속도향상만을 초래
  • δ가 커질수록 2개의 기술 격차는 줄어듬 ( dynamic content가 상당량 있는 app의 경우 더 많은 resource content가 변경되고, TTL을 확장할 수 있는 캐시 새로고침 기술의 능력이 제한되기 때문 )
• 이것의 결과가 Marauder의 최적화 기술 사이의 시너지를 강조
  • 2개의 최적화에서 얻은 결론을 초과하는 이점을 제공하는 것이 목적
  • 캐시 새로고침 기술이 text 내용을 최신상태로 계속 유지 -> JIT가 상호작용에 필요한 적절한 resource를 미리 확보할 수 있음 -> 시너지 효과 발생하여 단순합보다 더 좋은 성능 야기

Case study of interactions

• 최적화 효과 : 표적이 되는 특정 상호작용의 적재 패턴에 영향을 받음

  App	Cache Refreshing	JIT Prefetching	Both	Neither
  Fox News	59.6%	12.8%	19.1%	8.5%
  Uniqlo	25.9%	11.1%	44.4%	18.5%
  Guardian	26%	13%	52.1%	8.7%
  UEFA	18.2%	7%	11%	63.7%
  Weather	22.6%	0%	0%	77.4%

  • 상호작용은 both와 같이 패턴의 여러개가 동시에 나타날 수 있음
  • 3가지 패턴 존재
    • 캐시 새로고침 최적화 : instance화에 걸쳐 리소스가 크게 변경되지 않은 interaction에 크게 도움이 됨 ( 보수적인 TTL 사용 )
  • 이 부분은 이후에 추가할 것

The importance of text files

• 최적화 핵심 : text file이 2가지 이유로 interaction에서 load할 수 있는 가장 높은 우선순위 리소스임
  • 상호작용이 시작될 때 blocking manner로 fetch되고, 상호작용을 처리하는데 필요한 리소스를 나열 ( JIT prefetching 안내 )
• text file을 loading하는 것을 가속화하는 것이 전체 성능에 좋은 속도 향상을 보임

Bandwidth overheads

• median app에 대해 1.18x 더 많은 데이터 소비
  • 앱에 사용되는 모든 interaction trace에 걸쳐 data를 요약
  • 기존 방법들보다 훨씬 낮은 수치

• bandwidth 사용을 즐가시킬 수 있는 2가지 방법 존재

• 이 부분도 이후에 추가할 것

3. Comparison with State-of-the-art

• 이 부분도 이후에 추가할 것

Related Work

Conclusion

• Marauder 제안 : 캐싱과 prefetching 기술의 관련 risk를 회피하는 혼합체
  • TTL 또는 캐싱 등의 낡아빠진 content를 잘못 설정하지 않고, bandwidth 낭비도 최소화
• 주요 관찰 : 웹과 비슷한 상호작용 처리
  • 다운로드된 text file가 가져올 나머지 URL set을 완전히 나열함
• 앱의 캐시에서 2가지 low-risk 최적화 도입
  • 캐시된 text file에 의해, 이미 트리거돤 상호작용 중에 참조된 리소스를 미리 설정
  • 캐시된 content의 효율성을 높이기 위해 about-to-expire 리소스를 사전에 구하고 캐시 수명을 연장 / 추가로 text file은 업데이트 진행
• 결과
  • 상호작용 응답시간 27.4 ~ 43.5% 감소시킴
  • 데이터 사용량은 18% 증가했음 ( 시간대비 적절히 사용한 것으로 생각 )