일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 리트코드
- fast api
- k8s
- vuejs
- Redis
- kubernetes
- 생성형
- 컨설턴트
- BFS
- 머신러닝
- LLaMa
- LeetCode
- SpringBoot
- 쿠버네티스
- Python
- Docker
- OpenShift
- 메세지큐
- 솔루션조사
- 오픈시프트
- jpa
- fastapi
- Machine Learning
- 로깅
- vue.js
- 생성형 AI
- 컨설팅
- GPT
- 도커
- POD
- Today
- Total
목록개발지식/Database(DB) (2)
수 많은 우문은 현답을 만든다
안녕하세요, 조영호입니다. 오늘은 Mybatis를 쓰면서 캐싱과 관련해서 고민했던 내용을 공유하고자 합니다. 백엔드 개발을 하시는 분들이라면 한 번 쯤은 아래와 같은 고민을 해보셨을 것 같습니다. "API들이 호출될때마다 특정 query를 매번 호출해야 하는 경우, 과연 이대로 성능은 괜찮을까?" 예를들어 제공하려는 조회 API가 100개인데, 각 API를 호출할때 마다 사용자의 상태가 바뀌었는지 DB에서 조회를 해야하는 상황이 있다고 가정해보자. 그러면 우리는 수 천명의 동시 접속자가 각각 API를 호출하게 되면 엄청난 성능 저하가 발생할 것으로 예상할 수 있다. 위와같은 경우 우리는 Redis 같은 메모리디비나, 자체적으로 Bean으로 등록한다거나 해서 비용을 줄일 수 있다. 하지만, JPA나 Myb..
안녕하세요 조영호입니다. 오늘은 성능테스트 당시 발견한 CPU 사용률이 100%까지 올라가는 현상을 해결한 경험을 공유하고자 합니다. 다른 웹 페이지들과는 다르게 빅데이터(약 80,000,000건)를 조회하는 페이지에서 TPS가 너무 낮게 나오는 현상이 있었습니다. 이슈 내용 Database 조회 Table에는 적절한 Index를 설정했다 조회 API에서 Index 검색을 탈 수 있도록 필요한 컬럼들을 파라미터로 보냈다 동시접속자 30명이 넘어가면 CPU가 100%를 치면서 서비스가 마비되는 현상이 발생했다. 테스트 내용 Jmeter로 동시 접속 사용자를 기준으로 웹 사이트의 부하테스트를 수행했습니다. 일반적으로 데이터가 많지 않은 Back-end API는 호출시 300 tps 이상의 빠른 응답을 보였지..