Title: In-The-Field Monitoring of Functional Calls: Is It Feasible?
ArXiv ID: 2001.07283
발행일: 2020-01-22
저자: Oscar Cornejo, Daniela Briola, Daniela Micucci, Leonardo Mariani
📝 초록 (Abstract)
장치에서 실행 중인 애플리케이션이 호출하는 함수 시퀀스에 대한 데이터를 수집하면 실패 재현, 프로파일링 및 디버깅 등 여러 응용 분야에 유용할 수 있습니다. 그러나 장치에서의 데이터 수집은 사용자 경험을 저해하는 지연을 초래할 수 있습니다. 지금까지 모니터링이 애플리케이션에 미치는 영향은 주로 추가적인 부하를 통해 연구되었습니다. 본 논문에서는 사용자가 실제로 인식 가능한 효과가 있는지에 대해 새로운 관점으로 연구했습니다. 이 결과, 수행되는 작업의 성질과 실행 컨텍스트에 따라 사용자는 상당한 부하도 견딜 수 있음을 발견하였습니다. 이 정보는 사용자를 불편하게 하지 않고 유용한 양의 데이터를 수집하는 데 활용될 수 있습니다.
💡 논문 핵심 해설 (Deep Analysis)
This paper focuses on the impact of monitoring function calls in applications while they are running. Specifically, it examines whether users can recognize any delays caused by such monitoring and under what conditions these delays become significant. The research team analyzed various types of operations across different applications to understand how much overhead is introduced by monitoring. They categorized operations into Instantaneous, Immediate, Continuous Simple, Complex, and Captive types. The key finding was that the majority of the time, the overhead caused by monitoring function calls was less than 10%, making it nearly imperceptible to users. However, certain operations, particularly those in Paint.NET, showed higher sensitivity to this overhead. This study provides valuable insights for developing monitoring systems that can collect necessary data without significantly impacting user experience. It also offers guidance on how to optimize these systems when computational resources are limited.
📄 논문 본문 발췌 (Translation)
## RQ1a - 함수 호출 모니터링이 초래하는 부하는 무엇인가?
각 카테고리별 및 애플리케이션 별로 관찰된 부하.
그림 1은 각 카테고리의 작업과 각 주제 애플리케이션에서 관찰한 부하를 보여줍니다. 모든 유형의 작업이 모든 애플리케이션에서 발생하는 것은 아니라는 점을 기억해야 합니다. 예를 들어 Captive 작업은 Paint.NET에만 있습니다.
카테고리별 부하 프로파일은 상당히 일관적입니다. Instantaneous 작업의 경우 부하는 항상 0에 가깝습니다. 이는 단순한 작업을 수행하며 적은 양의 로직이 실행되어 함수 호출도 제한적이기 때문입니다. Immediate 작업에서도 비슷한 결과를 볼 수 있습니다. Adobe Reader DC와 Notepad++에서 부하가 작지만, Paint.NET은 예외로 더 높은 부하를 보여줍니다. Continuous Simple 및 Complex 카테고리의 작업들에서는 0%에서 200% 사이의 부하 범위를 볼 수 있습니다.
동일한 카테고리 내에서도 애플리케이션이 다르면 부하가 다를 수 있지만, 몇 가지 예외 사항을 제외하면 대체로 일관된 패턴을 보입니다. 예를 들어 Notepad++에서 Continuous Simple 작업 중 Java 하이라이팅 선택 및 저장 취소 작업 두 개는 다른 작업들에 비해 매우 높은 부하(100% 이상)를 보여주는 아웃라이어입니다.
특정 부하 구간을 경험하는 작업의 백분율.
함수 호출 수집은 대부분의 경우 (실행된 작업의 65%) 0-10% 범위의 부하를 초래합니다. 8%의 경우는 10-30% 사이의 부하가 발생하며, 12%의 경우는 30-80% 사이의 부하가 발생하고, 나머지 약 15%의 작업은 더 높은 부하를 경험합니다.
함수 호출 수집이 초래하는 부하는 대부분의 경우 10% 미만이며, 매우 드물게는 80% 이상을 초과할 수 있습니다 (그림 2). 사용자 활동에 대해 이러한 부하가 얼마나 침습적인지 여부는 다음 연구 질문에서 살펴봅니다.
RQ1b - 함수 호출 모니터링이 사용자 경험에 미치는 영향은 무엇인가?
표 [table:slow_operations]
는 4개의 주제 애플리케이션에서 느린 작업으로 기록된 분석 결과를 보고합니다. 각 애플리케이션에서는 실험에서 실행된 각 카테고리별 작업 수와 함수 호출 모니터링에 의해 발생한 부하로 인해 작업이 어떻게 분류되었는지 나타냅니다. 사용자가 부하를 인식하지 못하면 해당 카테고리가 변하지 않습니다. 완벽한 결과는 대각선 값(회색 배경) 이외의 모든 값을 0으로 가집니다. 작업의 카테고리가 변경되면 테이블에 새로운 카테고리를 표시합니다. ‘$`>`$ Captive’ 열은 작업 지속 시간이 Captive 작업에 대해 허용된 최대 시간을 초과하는 작업 수를 나타냅니다. 마지막 열, ‘느린 작업 $`[\%]`$’,는 모든 실행에서 느린 작업의 백분율을 표시합니다.
SRT 카테고리별 느린 작업의 백분율.
그림 3은 시각적으로 느린 작업이 각 작업 유형에 어떻게 분포하는지 보여줍니다. 각 카테고리의 마지막 열은 해당 카테고리에서 느린 작업의 백분율을 나타냅니다.
실제 데이터는 Instantaneous 작업들이 사용자 경험에 영향을 미치는 지연이 거의 없다는 것을 시사합니다: 실제로 6%만 인식 가능한 지연을 초래했습니다. Immediate 작업에서도 비슷한 결과를 얻었지만 Paint.NET은 모든 Immediate 작업에서 유의미한 지연을 보였습니다. 이는 RQ1a에서 Paint.NET에서 Immediate 작업에 대한 부하가 높았던 것과 일치합니다. 이것은 Paint.NET에서 실행되는 Immediate 작업이 복잡한 로직을 수행하기 때문이며, 모니터링하기에 더 비싸다는 것을 의미합니다.
실행되는 애플리케이션의 로직 부분이 증가할수록 느린 작업의 수가 늘어나며, Continuous 작업에서 특히 그렇습니다 (그림 3 참조). 예를 들어 Notepad++에서 5개의 Continuous Simple 작업이 Captive 작업에 기대되는 시간을 초과했습니다. Continuous 작업 모니터링의 높은 비용은 그림 3에서도 확인할 수 있습니다. 평균적으로 Continuous 작업(Simple 및 Complex) 중 20% 이상이 심각하게 느려졌습니다.
매우 긴 작업, 즉 Captive 작업은 함수 호출 모니터링에 의해 초래된 부하를 잘 견디는 것으로 보입니다. 그러나 이들은 한 애플리케이션에서만 존재하기 때문에 더 일반적인 교훈을 얻기 어렵습니다.
결론적으로, 느린 작업으로 인식될 가능성이 있는 작업의 수는 매우 제한적($`<`$20% 전체)이며 대부분 Continuous 작업에 집중되어 있습니다. 또한, Paint.NET처럼 빠르게 실행해야 하는 작은 로직 조각을 구현하는 애플리케이션은 특히 모니터링하기 어렵습니다.
RQ1c - 도입된 부하에 대한 작업의 견디는 정도는 무엇인가?
다른 부하 구간에서 느린 작업의 백분율.
이 연구 질문은 다양한 카테고리별 작업이 특정 부하로 인해 너무 느려진 경우가 얼마나 자주 발생하는지 분석합니다. 그림 4는 각 카테고리의 작업에서 주어진 부하 구간 내에서 느린 작업의 백분율을 보여줍니다.
우리의 이전 연구에서는 사용자가 다른 반응을 보일 수 있는 30%, 80%, 그리고 180%를 흥미로운 부하 값으로 식별했기 때문에, 이번 연구에서는 이러한 범위를 사용하여 수집된 데이터를 분석했습니다.
이 실험에서도 유사한 결과를 얻었습니다: 30-80%의 부하는 대부분의 작업 카테고리에서 견디는 것이 어렵지만, Instantaneous 작업은 그런 부하를 더 잘 견디는 것으로 보입니다. 부하가 80% 이상인 경우에는 거의 불가능할 수 있습니다.
결론적으로 부하 수준이 30%까지는 해롭지 않으나, 그 이상의 부하 수준은 매우 조심스럽게 도입해야 합니다. Instantaneous 작업만 제외하고 말입니다.
RQ2 - 함수 호출 모니터링에 대한 자원 제한이 미치는 영향은 무엇인가?
이 섹션에서는 모니터링 활동이 계산 자원을 완전히 할당할 수 없는 경우, 즉 다른 작업에도 할당될 때의 영향을 연구합니다. 먼저 CPU 사용량에 따른 영향을 논하고, 그 다음에는 메모리 사용량에 따른 영향을 논합니다.
RQ1과 마찬가지로 우리는 함수 호출 수집을 통해 부하를 분석하고, 모니터링이 있는 경우와 없는 경우의 작업 카테고리 변경 수를 연구합니다.
RQ2a - CPU 사용량은 모니터링의 침습성을 얼마나 크게 만들까요?
다른 CPU 부하 수준에 따른 작업 카테고리별 실행 시간.
그림 5는 다양한 CPU 사용량(0%, 60%, 75%, 및 90%)에서 관찰된 작업의 시스템 응답 시간을 보여줍니다.
이 그림에는 두 가지 유형의 상자그림이 포함되어 있습니다. 주황색 상자그림은 모니터링이 있는 경우의 실행 시간을 나타내고, 갈색 상자그림은 모니터링이 없는 경우의 실행 시간을 나타냅니다.
즉시 작업을 제외하고 모든 유형의 작업에 대한 경향성이 매우 비슷합니다. 즉시 작업은 더 높은 CPU 부하 값에서 오버헤드가 감소하는 것을 보여줍니다. 주어진 CPU 사용량과 작업 카테고리별로 도입된 오버헤드가 다른 CPU 사용량에 노출된 동일한 작업 카테고리의 오버헤드와 어떻게 다를지 확인하기 위해 크루스칼-월리스 검정을 수행했습니다. 통계적으로 유의미한 차이를 발견하지 못했습니다 (표 1 참조), 모니터링의 영향력은 CPU 사용량에 크게 의존하지 않음을 나타냅니다. 즉, 애플리케이션은 함수 호출 모니터링으로 인해 비슷한 정도로 느려집니다.
다른 CPU 부하 수준에 따른 애플리케이션별 느린 작업의 백분율.다른 CPU 부하 수준에 따른 작업 카테고리별 느린 작업의 백분율.
우리는 또한 모니터링이 애플리케이션별 (그림 6) 및 작업 카테고리별 느린 작업 수 (그림 7)에 어떤 영향을 미치는지 고려했습니다. 과부하된 CPU 사용량은 이미 각 애플리케이션에서 느린 작업의 수를 생성하고, 함수 호출 모니터링은 이러한 작업의 수를 더 증가시킵니다. 그러나 추가적인 모니터링만으로도 사용자 경험을 비슷한 정도로 저해함을 알 수 있습니다.
RQ2b - 메모리 사용량은 모니터링의 침습성을 얼마나 크게 만들까요?
표 3에 각 애플리케이션의 메모리 사용량을 요약합니다: 실험 중 Adobe Reader DC는 356 MB, Notepad++은 278 MB, Paint.NET은 520 MB, VLC Media Player은 303 MB의 RAM을 사용했습니다.
다른 메모리 사용량에 따른 작업 카테고리별 실행 시간.
그림 8은 메모리 사용량이 90%까지 증가할 때 시스템 응답 시간에 도입된 부하를 보여줍니다.
주황색 상자그림은 함수 호출 수집을 통해 관찰된 실행 시간을 나타내고, 갈색 상자그림은 모니터링이 없는 경우의 실행 시간을 나타냅니다.
동일한 방법으로 Kruskal-Wallis 검정을 수행하여 (표 4 참조) 다양한 메모리 사용량에 따른 통계적으로 유의미한 차이를 찾지 못했습니다. 특히 메모리 부하가 오버헤드에 미치는 효과는 거의 없다고 볼 수 있습니다.
또한 우리는 메모리 사용량이 증가할 때 느린 작업이 얼마나 많이 되는지를 조사했습니다 (그림 9 및 그림 10). 애플리케이션의 동작은 어떠한 경향성도 보여주지 않았습니다.
우리는 각 애플리케이션에 대한 느린 작업 수에 대한 선형 회귀 분석을 수행하고, 계수 간 차이를 고려했습니다. 또한 메모리가 100% 포화 상태일 때의 작업 분류 변화도 살펴보았습니다.
표 5에 결과를 보고합니다. 각 애플리케이션에 대해 계수 간 차이와 작업 분류 변화의 백분율을 나타냅니다.
계수 간 차이는 미미하며 느린 작업 수도 거의 변하지 않아, 두 경우 모두 유사한 경향성을 보여줍니다. 메모리 사용량은 작업 카테고리를 고려할 때 크게 영향을 미치지 않는 것으로 확인되었습니다.
결론적으로, 메모리 사용량은 함수 호출 모니터링의 침습성에 거의 영향을 주지 않습니다. 즉, 모니터링 오버헤드는 메모리 가용성이 어느 정도인지와 관계없이 비슷합니다.
토론
자원 제한이 있을 때 함수 호출 모니터링이 사용자 경험에 미치는 영향은 자원에 큰 영향을 받지 않습니다. 따라서 모니터링 로직의 활성화 및 비활성화는 자원 사용량에 거의 신경 쓰지 않고 이루어질 수 있습니다. 단, CPU 포화가 90%를 초과하는 경우 모니터링은 피해야 합니다.
마지막으로, 결과는 즉시 작업이 다른 유형의 작업보다 메모리 가용성에 덜 민감하다는 것을 나타냅니다.
