https://team-edo.github.io/tags/%EC%84%B1%EB%8A%A5-%EC%B8%A1%EC%A0%95/Recent content in 성능 측정 on 얼쑤 · Team EdoHugoko-krThu, 29 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/budget-end-to-end-analysis-time/Thu, 29 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/budget-end-to-end-analysis-time/<p>얼쑤의 연주 분석에는 60초 제한이 있습니다. 이 시간은 세션이 <code>PENDING</code>이 된 시각부터 결과를 저장할 수 있는 마감까지 흐릅니다. 실행기에서 대기하는 시간, 녹음 다운로드와 디코딩, 음높이 추정과 채점, DB 쓰기가 모두 같은 예산을 사용합니다. 모델의 처리 시간만 재면 가장 먼저 늦어지는 단계가 어디인지 알 수 없습니다.</p> <h2 id="같은-요청에도-여러-시간-제한이-있다">한 요청에 걸린 여러 제한</h2> <table> <thead> <tr> <th>시간 제한</th> <th>언제부터 재나</th> <th>만료되면</th> </tr> </thead> <tbody> <tr> <td>백엔드의 결과 저장 마감 <strong>60초</strong></td> <td>DB에 기록한 분석 시도 시작 시각부터</td> <td>늦은 결과는 저장하지 않고, 마감이 지난 <code>PENDING</code>은 상태 조회에서 <code>TIMEOUT</code>으로 처리합니다.</td> </tr> <tr> <td>백엔드 HTTP 클라이언트의 읽기 제한 기본 <strong>65초</strong></td> <td>AI 응답을 읽으면서 다음 응답 데이터를 기다릴 때</td> <td>대기 시간을 넘기면 HTTP 읽기가 실패합니다.</td> </tr> <tr> <td>앱의 상태 무응답 제한 <strong>70초</strong></td> <td>상태 조회를 시작하거나 재개한 시점부터, 응답을 받으면 그 시점부터</td> <td>앱이 시간 초과 화면을 표시합니다.</td> </tr> </tbody> </table> <p>HTTP 연결을 맺는 제한은 별도로 <strong>5초</strong>였습니다. 읽기 제한을 저장 마감보다 길게 둬, 느린 응답을 클라이언트가 먼저 끊어 서버 오류로 분류하는 경우를 줄이려 했습니다. HTTP 연결이 끊겨도 이미 실행 중인 AI 연산이 취소되는지는 별도의 문제입니다. 앱의 조회 간격과 무응답 경계는 가상 시계로 확인했습니다. <a href="https://team-edo.github.io/posts/2026/10/recording-analysis-polling/">녹음 업로드 202 이후 앱이 기다리는 것</a></p>