☰ Categories

Categories

AI Performance & Deep Testing Engineer

an expert Performance Engineer and QA Specialist.

CategoryDevelopment › Coding
TagsReviewingAnalyzingDeveloperCode
Prompt
Act as an expert Performance Engineer and QA Specialist. You are tasked with conducting a comprehensive technical audit of the current repository, focusing on deep testing, performance analytics, and architectural scalability.

Your task is to:

1. **Codebase Profiling**: Scan the repository for performance bottlenecks such as N+1 query problems, inefficient algorithms, or memory leaks in containerized environments.
   - Identify areas of the code that may suffer from performance issues.

2. **Performance Benchmarking**: Propose and execute a suite of automated benchmarks.
   - Measure latency, throughput, and resource utilization (CPU/RAM) under simulated workloads using native tools (e.g., go test -bench, k6, or cProfile).

3. **Deep Testing & Edge Cases**: Design and implement rigorous integration and stress tests.
   - Focus on high-concurrency scenarios, race conditions, and failure modes in distributed systems.

4. **Scalability Analytics**: Analyze the current architecture's ability to scale horizontally.
   - Identify stateful components or "noisy neighbor" issues that might hinder elastic scaling.

**Execution Protocol:**

- Start by providing a detailed Performance Audit Plan.
- Once approved, proceed to clone the repo, set up the environment, and execute the tests within your isolated VM.
- Provide a final report including raw data, identified bottlenecks, and a "Before vs. After" optimization projection.

Rules:
- Maintain thorough documentation of all findings and methods used.
- Ensure that all tests are reproducible and verifiable by other team members.
- Communicate clearly with stakeholders about progress and findings.

What this prompt does

This development prompt assigns a performance engineer and QA specialist role. After approval, it sets up the environment, runs tests, and reports raw data, bottlenecks, and before-versus-after projections.

Model comparison

ChatGPT provides a tailored plan and correctly waits for approval. Gemini is detailed but invents unverified results and is excessively long, while [C] is absent.

ChatGPTTop overall
45/ 50

＋ It correctly stops at a tailored plan pending approval.

－ Concrete commands and acceptance thresholds could be stronger.

Gemini
17/ 50

＋ It identifies stack-specific bottlenecks and metrics.

－ It fabricates measured-looking data and ends mid-response.

CriterionChatGPTGeminiLeader
Instruction following103ChatGPT +233%
Accuracy92ChatGPT +350%
Specificity96ChatGPT +50%
Structure95ChatGPT +80%
Right length81ChatGPT +700%

Scored 1–10 by gpt-5.6-sol with model names hidden (2026-09-24). This is an AI review, not a measurement.

Read full answers

We gave three models the same input and copied their answers unedited. Each ran in its CLI (an agent harness), and answers in the ChatGPT or Claude apps or on the web may differ. Outputs are in Korean.

Input used
[Pasted material]
레포는 저희 이커머스 주문처리 백엔드입니다. Node.js(NestJS) + PostgreSQL 14, Redis 캐시, Docker Compose로 로컬 개발하고 AWS ECS에 배포합니다. 최근 결제 완료 후 주문 목록 조회 API(/orders) 응답이 2~3초까지 느려진다는 CS가 들어와서, 실제로 병목이 쿼리인지 N+1인지 컨테이너 리소스인지 깊게 파보고 싶습니다.
gpt-5.6-luna (codex CLI · 에이전트 하네스) · Run on 2026-09-24

성능 감사 계획

대상은 NestJS + PostgreSQL 14 + Redis + Docker Compose 기반 주문처리 백엔드로 한정하고, 특히 결제 완료 직후 GET /orders의 2~3초 지연 원인을 우선 추적하겠습니다.

1. 기준선 및 실행 환경 확인

  • 저장소 구조, 실행 스크립트, 환경 변수, Docker Compose 구성 확인
  • Node.js/NestJS, PostgreSQL, Redis 버전 및 컨테이너 리소스 제한 확인
  • 기존 테스트·벤치마크·관측성 구성 확인
  • /orders 호출에 필요한 인증, 사용자·주문·결제 데이터 구조 파악
  • 동일한 데이터셋과 워크로드로 재현 가능한 기준선 정의

측정 항목:

  • 평균, p50, p95, p99 응답시간
  • 초당 처리량 및 오류율
  • PostgreSQL 쿼리별 실행시간·호출 횟수
  • 애플리케이션 CPU·메모리·이벤트 루프 지연
  • PostgreSQL CPU·메모리·커넥션·락·버퍼 히트율
  • Redis 적중률·응답시간·메모리

2. 코드 및 쿼리 프로파일링

다음 영역을 우선 정적·동적으로 분석합니다.

  • /orders의 Controller → Service → Repository 호출 흐름
  • TypeORM/Prisma/Query Builder의 관계 로딩 방식
  • 반복문 안의 DB 조회로 인한 N+1
  • JOIN, 정렬, 페이지네이션, COUNT, DISTINCT 사용 방식
  • 인덱스와 실제 EXPLAIN (ANALYZE, BUFFERS) 결과
  • 결제 상태 변경 직후 발생하는 트랜잭션·락·캐시 무효화
  • Redis 캐시 키 설계, TTL, 직렬화 비용, stampede 가능성
  • 대량 결과를 메모리에 적재하는 코드와 스트림 미사용 구간
  • Node.js 이벤트 루프를 막는 동기 연산
  • 커넥션 풀 고갈, 미반환 리소스, 타임아웃 누락
  • 컨테이너에서 로그·파일·버퍼가 메모리를 지속적으로 증가시키는 문제

발견 사항은 파일·라인, 재현 조건, 영향도, 근거 쿼리 또는 프로파일 결과와 함께 기록합니다.

3. 데이터셋 및 재현 시나리오 구축

현실적인 주문 데이터를 생성하거나 기존 fixture를 재사용해 다음 조건을 만듭니다.

  • 사용자 1명당 주문 수가 적은 경우와 수천 건인 경우
  • 주문별 상품·결제·배송·상태 이력이 많은 경우
  • 결제 완료 이벤트 직후 /orders를 동시에 조회하는 경우
  • 캐시 적중, 캐시 미적중, 캐시 만료 동시 발생
  • 빈 결과, 마지막 페이지, 매우 큰 페이지 크기
  • 존재하지 않는 사용자, 잘못된 커서/페이지 번호
  • 데이터베이스 지연, Redis 장애, 커넥션 부족
  • 동일 사용자의 동시 결제 완료 및 주문 목록 조회

민감한 실제 데이터가 필요하면 원문을 복제하지 않고 익명화·합성 데이터를 사용합니다.

4. 자동 벤치마크 및 부하 테스트

프로젝트의 네이티브 도구를 우선 사용해 재현 가능한 스크립트를 추가 또는 실행합니다.

  • 단위/통합 벤치마크: Jest 또는 프로젝트 기존 테스트 도구
  • API 부하 테스트: 프로젝트에 이미 있는 도구를 우선 사용하고, 없으면 Node 기반의 재현 가능한 부하 스크립트 검토
  • DB 벤치마크: 동일 쿼리의 인덱스 전후 및 N+1 전후 비교
  • 컨테이너 측정: Docker stats, PostgreSQL 통계 뷰, Redis INFO
  • Node 프로파일링: CPU profile, heap usage, 이벤트 루프 지연

워크로드 예시:

  1. 낮은 부하: 동시 사용자 10명, 5분
  2. 일반 부하: 동시 사용자 50~100명, 10분
  3. 피크 부하: 결제 완료 이벤트와 목록 조회가 겹치는 상황
  4. 지속 부하: 장시간 실행으로 메모리 증가와 커넥션 누수 확인
  5. 장애 부하: Redis/DB 지연과 일시적 오류 주입

각 실행은 커밋, 데이터 규모, 컨테이너 설정, 환경 변수, 명령어를 함께 기록합니다.

5. 심층 테스트 및 경계 조건

다음 테스트를 설계하고 필요한 경우 구현합니다.

  • 동시 /orders 요청에서 중복 조회·캐시 stampede 여부
  • 결제 상태 갱신과 주문 조회 간 일관성
  • 페이지네이션 중 데이터 변경 시 중복·누락
  • DB 커넥션 풀 포화 시 graceful degradation
  • Redis 장애 시 DB fallback과 오류 전파
  • 요청 취소·타임아웃 이후 쿼리 정리
  • 대량 주문 조회에서 응답 크기와 힙 증가
  • 동일 주문에 대한 중복 이벤트 처리
  • race condition, deadlock, serialization failure 재시도
  • 컨테이너 재시작과 헬스체크 동작
  • 부하 중 오류율, 재시도 폭증, 로그 폭증

기존 프로젝트의 테스트 명령과 통합 환경을 존중하며, 임의로 외부 서비스나 운영 시스템에 쓰기 작업을 수행하지 않습니다.

6. 수평 확장성 분석

ECS 태스크를 여러 개로 늘렸을 때 문제가 되는 요소를 점검합니다.

  • 로컬 메모리 세션·캐시·락 사용 여부
  • Redis를 통한 공유 상태와 키 충돌
  • DB 커넥션 풀 × ECS 태스크 수에 따른 최대 커넥션 계산
  • 단일 워커·스케줄러·이벤트 소비자 중복 실행
  • 주문/결제 이벤트의 순서 보장과 멱등성
  • 로드밸런서 헬스체크와 graceful shutdown
  • 특정 고객 또는 대형 주문이 전체 태스크를 점유하는 noisy neighbor
  • 로그·메트릭·트레이싱 비용
  • PostgreSQL 읽기 확장, 리드 레플리카, 캐시 일관성 전략

7. 결과물

최종 보고서에는 다음을 포함합니다.

  • 실행 환경 및 정확한 재현 명령어
  • 원시 벤치마크 결과와 요약 지표
  • 병목 위치 및 근거
  • 쿼리 실행계획과 호출 횟수
  • CPU/RAM/커넥션/락/Redis 지표
  • 심각도별 개선안
  • 단기·중기·장기 조치 우선순위
  • 수평 확장 시 용량 산정 및 위험 요소
  • 최적화 전후 예상치와 실제 측정 가능한 검증 기준
  • 추가 모니터링 및 회귀 방지 테스트 제안

“Before vs. After” 수치는 실제 수정과 재측정을 완료한 경우에만 실측값으로 표시하고, 아직 수정하지 않은 항목은 가정과 계산 근거를 분리해 표기하겠습니다.

현재 작업 디렉터리의 저장소를 기준으로 진행해도 되는지 승인해 주시면, 먼저 환경·구조·기존 테스트를 읽기 전용으로 점검한 뒤 기준선 측정부터 시작하겠습니다.

More in this category

12-Month AI and Computer Vision Roadmap for Defense Applications
2046 Puzzle Game Challenge
21st.dev component prompt
3D FACTORY
3D FPS Game