일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 쿠버네티스
- Machine Learning
- vuejs
- Python
- 도커
- Docker
- BFS
- 리트코드
- kubernetes
- LLaMa
- GPT
- POD
- 머신러닝
- 생성형
- 메세지큐
- jpa
- 생성형 AI
- OpenShift
- Redis
- 솔루션조사
- 컨설팅
- fastapi
- 로깅
- 컨설턴트
- vue.js
- fast api
- SpringBoot
- k8s
- 오픈시프트
- LeetCode
- Today
- Total
목록성능 (2)
수 많은 우문은 현답을 만든다
오늘은 성능 향상에 대해서 이야기를 해보자. 서론한달만에 Big-data를 다루는 API 중계 솔루션을 개발했다.데이터를 수집하는 멀티쓰레딩 배치가 10개정도 동시에 돌아가고, 수집된 데이터를 API로 제공하는 서비스이다.문제는 API 응답 데이터가 가장 큰 녀석은 한번에 250MB를 보내고 있어서 성능 테스트에 어려움을 겪었다.처음부터 큰 데이터를 다루기 위한 설계를 잘 했어야 하는데, 분산시스템 개발 경험은 있으나 이런 큰 단건 데이터 처리는 경험이 없어서 고생을 했다. 솔루션 기술 스택 :- Fast API, Redis, Mongo DB 성능 요구 사항 :- 400 TPS, 동시접속자 150,000명, 속도 건당 1초 이내 본론우선 단건 데이터가 적은 API들은 성능 요구 사항을 만족했다. 그러나..
안녕하세요 조영호입니다. 오늘은 성능테스트 당시 발견한 CPU 사용률이 100%까지 올라가는 현상을 해결한 경험을 공유하고자 합니다. 다른 웹 페이지들과는 다르게 빅데이터(약 80,000,000건)를 조회하는 페이지에서 TPS가 너무 낮게 나오는 현상이 있었습니다. 이슈 내용 Database 조회 Table에는 적절한 Index를 설정했다 조회 API에서 Index 검색을 탈 수 있도록 필요한 컬럼들을 파라미터로 보냈다 동시접속자 30명이 넘어가면 CPU가 100%를 치면서 서비스가 마비되는 현상이 발생했다. 테스트 내용 Jmeter로 동시 접속 사용자를 기준으로 웹 사이트의 부하테스트를 수행했습니다. 일반적으로 데이터가 많지 않은 Back-end API는 호출시 300 tps 이상의 빠른 응답을 보였지..