Skip to content

PERFORMANCE_DIAGNOSIS_PLAN.md

Latest commit

 

History

History
199 lines (129 loc) · 4.8 KB

PERFORMANCE_DIAGNOSIS_PLAN.md

File metadata and controls

199 lines (129 loc) · 4.8 KB

성능 점검 계획

결론

현재 체감되는 "전체적으로 조금 느림"은 CDN 하나로 해결될 가능성보다 API 호출 수, 불필요한 refetch, 이미지 로딩, Railway ↔ Supabase 응답 시간 문제일 가능성이 더 높다.

즉 우선순위는 다음과 같다.

  1. 어떤 화면에서 느린지 계측
  2. 어떤 API가 느린지 확인
  3. 프론트의 중복 refetch / invalidate 정리
  4. 이미지 최적화
  5. 마지막으로 CDN 검토

CDN이 직접 해결하는 영역

CDN이 효과적인 경우:

  • 큰 이미지
  • 썸네일
  • 배경 이미지
  • 정적 에셋

CDN만으로 잘 안 풀리는 경우:

  • 홈 진입 시 API 여러 개 동시 호출
  • Railway 서버 응답 지연
  • Supabase 쿼리 지연
  • 화면 전환 때 과한 refetch
  • 모달/상세 진입마다 같은 데이터를 다시 읽는 구조

현재 구조에서 우선 의심할 부분

1. 홈 화면

홈은 진입/복귀 시 여러 쿼리가 겹칠 가능성이 있다.

  • home-summary
  • home-panel
  • tracking-report-status
  • 알림/방명록 모달 진입 시 추가 조회

특히 invalidateQueries가 많은 구조라 작은 액션 뒤에도 홈 관련 API가 연쇄적으로 다시 호출될 수 있다.

2. 피드 상세 / 무한 스크롤

피드 상세는 선택 포스트 + 랜덤 세션 + 댓글/공감 갱신이 섞여 있어서 한 번의 진입에서 네트워크 왕복이 누적될 수 있다.

3. 타인 프로필

타인 프로필은 다음 요소가 겹친다.

  • 프로필 조회
  • 친구 물주기
  • 방명록 화면 진입
  • 방명록 작성 후 invalidate

즉 프로필 화면이 단순 조회처럼 보여도 실제론 상호작용 이후 재조회 비용이 있다.

4. 이미지 로딩

배경 / 식물 / 프로필 / 피드 이미지가 최적화되지 않은 원본이면 네트워크보다 렌더 체감이 더 느릴 수 있다.

특히 다음을 의심한다.

  • 원본 해상도 이미지 직접 사용
  • 썸네일 URL 부재
  • 캐시 정책 불명확

먼저 확인할 화면

다음 4개 화면을 우선 계측한다.

  1. 홈 첫 진입
  2. 피드 상세 진입
  3. 타인 프로필 진입
  4. 비둘기 모달 / 방명록 모달 열기

각 화면에서 확인할 값:

  • 첫 화면 표시까지 걸린 시간
  • API 응답 시간
  • 이미지가 다 보일 때까지 걸린 시간
  • 같은 API가 중복 호출되는지 여부

프론트 점검 항목

1. 중복 refetch

다음을 우선 확인한다.

  • useFocusEffect에서 매번 refetch하는 쿼리
  • 액션 성공 후 invalidateQueries를 여러 번 호출하는 구조
  • 이미 최신 캐시가 있는데도 상세 진입 시 다시 읽는 구조

2. 낙관적 업데이트 가능한 부분

다음은 서버 재조회 대신 로컬 반영이 가능한 후보다.

  • 알림 읽음 처리
  • 좋아요 토글
  • 댓글 수 증가
  • 친구 물주기 후 버튼 상태

3. 이미지 표시 최적화

확인 포인트:

  • 큰 원본 이미지를 그대로 쓰는지
  • 썸네일과 상세 이미지를 분리할 수 있는지
  • 리스트에서는 작은 이미지, 상세에서 큰 이미지를 쓰는지

백엔드 점검 항목

1. 느린 API 찾기

우선 로그로 응답 시간이 느린 API를 찾는다.

  • /api/v1/home
  • /api/v1/home/panel
  • /api/v1/notifications
  • /api/v1/users/{id}
  • 피드 상세 관련 API

2. Supabase 쿼리 비용

확인 포인트:

  • N+1 조회
  • 정렬 + 조인 + 카운트가 한 번에 많은 API
  • 인덱스 없는 조건 검색

3. Railway 환경

확인 포인트:

  • cold start 체감 여부
  • 연결 풀 초기화 시간
  • 외부 스토리지/DB 왕복 시간

추천 계측 방법

프론트

  • 화면 진입 시점 로그
  • API 요청 시작/종료 시간 로그
  • 이미지 onLoad 완료 시간 로그

백엔드

  • 주요 API의 시작/종료 시간 로그
  • 느린 쿼리 로그
  • 필요한 경우 endpoint 별 응답 시간 측정

개선 우선순위

1차

  • 과한 refetch / invalidate 줄이기
  • 알림/좋아요/물주기 같은 짧은 액션은 로컬 상태 우선 반영
  • 홈/피드/프로필 진입 시 중복 호출 제거

2차

  • 이미지 최적화
  • 썸네일 도입
  • 캐시 전략 정리

3차

  • 백엔드 느린 쿼리 최적화
  • 인덱스 / fetch 전략 조정

4차

  • CDN 적용
  • 이미지/정적 에셋 위주로 우선 적용

실무 판단

현재는 CDN부터 붙이는 단계가 아니라 어디가 느린지 계측해서 병목을 찾는 단계다.

가장 먼저 할 일은 다음 둘이다.

  1. 홈 / 피드 / 프로필 / 알림 모달의 실제 체감 지연 구간을 로그로 잡기
  2. 각 구간에서 API와 이미지 중 무엇이 병목인지 분리하기

이후 결과에 따라

  • API 병목이면 쿼리/호출 수 최적화
  • 이미지 병목이면 CDN + 썸네일

순서로 들어가는 것이 맞다.