일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- pub.dev
- 코딩테스트
- c
- kakao
- thread
- Kotlin
- Redis
- AOP
- Spring
- Oidc
- 코드 트리
- java
- Scaffold
- OAuth
- 연습문제
- flutter
- dip
- C언어
- 부하 테스트
- 코딩 테스트
- hashmap
- 코드트리
- Kafka
- exception
- Sharding
- login
- 운영체제
- nGrinder
- 코딩
- 자료구조
- Today
- Total
목록nGrinder (3)
Nick Dev
5줄 요약nGrinder & pinpoint로 DB에서 getConnection()이 오래 걸린다는걸 파악함커넥션 풀 개수 조절해봄(10, 15, 20개)별 차이 없었음 😢sharding을 통해 DB 부하를 절반으로 줄여봄성능 개선됨 😊현재 서버 아키텍처 및 상황클라우드는 Naver Cloud Platform을 사용 중이다.nGrinder로 가상의 유저의 행동을 스크립트로 작성하고 이를 실행해보았다.한 유저가 회원가입 -> 로그인 -> 게시물 조회 100회, 게시물 생성 5회, 좋아요 누르기 15회, 북마크 누르기 15회하고 로그아웃 한다고 가정했다.- 즉, **한 유저 당 138개의 api를 호출**하게 된다.- connection pool(cp) size는 디폴트인 10이다.- 이러한 가상의 유저..
게시물 관련 정보들을 캐시했을 때와 하지 않았을 때의 성능(응답속도)을 비교해보자!!게시물 조회 로직에 캐시를 적용해야하는 이유유저가 게시물 단건 조회 시 아래와 같이 많은 정보를 모아서 리턴한다.게시물 정보이미지 정보게시물의 댓글 정보게시물 작성자 유저 정보이 정보들을 모두 DB에 질의해서 모아서 게시물 종합 정보를 리턴한다.문제점위 경우, posts/100 으로 게시물을 하나 조회하게 되면 DB에 최소 4번의 쿼리를 날려야 된다.SNS 도메인 특성 상, WRITE보단 READ의 비중이 훨씬 크기 때문에 READ의 성능을 개선할 필요가 있다.그래서 각 정보들을 Redis에 캐시해놓고 캐시된 데이터들을 조합해서 리턴하도록 코드를 리팩토링했다.각각 따로 캐시해놓고 조합해서 리턴하는 이유는 조합된 데이터를..
부하 테스트란...?실제 서비스 시작하기 전에, 현재 구축한 서버에서 어느정도 유저를 커버할 수 있는지, 대략 어느 시점부터 서버에 에러가 발생하기 시작하는지 알기 위해 부하를 부어보는 테스트다.실제 서비스할 서버 환경과 동일한 환경에서 부하를 늘려가면서 부어본다.⭐ nGrindernGrinder란?!네이버에서 진행한 오픈 소스 기반 플젝서버 부하 테스트를 위한 도구서비스 전에 서버가 얼마나 많은 사용자를 수용할 수 있는지 요청을 전송해봄으로써 서버의 성능을 측정해볼 수 있음nGrinder 주요 기능스크립트 레코딩웹 브라우저에서 사용자 동작을 녹화해 테스트 스크립트를 생성할 수 있음jpython을 사용해 스크립트 작성 가능분산 테스트다수의 agent 머신을 사용해 대규모 테스트 수행 가능실시간 모니터링테..