2.7 KiB
내부 브라우저 CPU 비교
장비의 동일한 matrix-browser 옵션(-no-sandbox --disable-gpu), 동일한 백엔드/CR 설정을 유지하고 표시 콘텐츠만 바꿨다. 아래 수치는 vmstat 1의 첫 누적 행을 제외한 구간별 user+system이다. 짧은 비교 실험이며 장기 평균은 아니다.
| 표시 콘텐츠 | 전체 CPU 사용 |
|---|---|
| 기존 장비 UI | 41~42% |
| about:blank | 4~5% (반올림된 idle 기준 약 4~6%) |
| 원래 URL로 재실행 | 41~44% |
| 현재 로그인 HTML/CSS 복사본, JavaScript 제외, 애니메이션 유지 | 43~47% |
| 같은 복사본, CSS animation/transition만 비활성화 | 4~9% |
로그인 CSS의 login-progress-slide는 무한 반복 애니메이션이다. JS를 제거한 비교 화면에서 이 애니메이션을 포함한 CSS 동작만으로 높은 부하가 재현됐다. 원래 실행 페이지의 JS 상태나 실제 DOM을 직접 확인한 것은 아니므로 원래 페이지가 왜 계속 애니메이션 중인지까지 확정하지 않는다.
웹에서 가능한 개선은 로그인 준비 막대의 무한 이동 효과를 제거하고 실제 진행률 변경만 표시하는 것이다. 상태 조회/인증/CAPTCHA/CR 검사를 끄는 변경은 필요하지 않다. login.js가 AbortSignal.timeout을 직접 사용하므로 장비 Qt 브라우저의 지원 여부 확인과 구형 브라우저용 타임아웃 대체 구현도 검토해야 한다. 이 API의 미지원은 아직 런타임에서 확인하지 않았다.
실험 후 /etc/init.d/S99matrix-browser start로 원래 URL을 복구했다. 영구 설정과 배포 파일은 바꾸지 않았다. 이 결과는 별도로 확인된 RCU stall/IRQ95 차단의 해결을 의미하지 않는다.
원시 기록: ../runtime/browser-blank-comparison.log 및 ../runtime/browser-animation-comparison.log.
수정 및 장비 배포 확인
로그인 준비 막대의 무한 애니메이션과 관련 keyframes를 제거하고 CSS 캐시 버전을 갱신했다. 준비 상태에 따른 막대 폭 및 메시지 갱신 코드는 유지했다. 프런트엔드 핸들러 테스트 및 ARM64 빌드가 통과했다.
웹만 배포했고 해시 1d6b8ba457e702a70fab9b03156d80a012ead37440fc8d93e5914ddd9c70c3f6, HTTP80, 준비 상태12/12, CAPTCHA true를 확인했다. 내부 브라우저를 원래 URL로 재실행한 후 실측 CPU는 첫 누적 행 제외 11~14% 구간이었다. 수정 전 동일 URL의 41~44%보다 낮다. CR 서비스는 변경하지 않았다. 커널 IRQ 장애 해결이나 장시간/재부팅 후 성능 보장을 의미하지 않는다.
배포 기록: ../runtime/static-progress-transfer.log. CPU 측정: ../runtime/static-progress-cpu.log.