대머리개발자

부하 :  nGrinder  R2DBC + 레디스R2DBC + mysql 쿼리 수행시간이 평균 4ms으로 나오는 EndPoint  ( 레디스 )쿼리 수행시간이 평균 5ms으로 나오는 EndPoint  ( mysql )  레디스가 약 63%로 빠르다. 레디스를 적재적소에 사용을 하면 최적화된 피드백을 전달할 수 있다.!!당영한 이야기지..괜히 캐쉬로 쓰는것이 아니다. webflux, 논-블로킹, 비동기,..을 사용하는 이유는... 최소한의 자원으로 최대한의 효과를 얻기 위함이다.  성능 향상 keyword- 논-블로킹으로 처리를 하더라도 step by step으로 하는 것이 아니라 필요에 따라서 동시(병렬)로 처리- 엔티티가 아닌 DTO로 처리 -> 바인딩하는데 좀 더 걸린다. : 별다른 로직이 없는데 쿼..

매번 할 때마다 찾아보는..녀석이라...정리 좀 하자.이해를 정확하게 못했기 때문에 매번 찾아본다고 생각한다. ㅠㅠ 또또 정리하자..// I/O 작업이나 블로킹 작업을 처리하기 위한 스케줄러입니다Schedulers.boundedElastic()// 별도 외부 API 호출할때나 혹은 대용량 엑셀 혹은 파일처리 할 때 기타.. 등등 좋겠다.// 짧은 시간 내에 끝나는 CPU 바운드 작업을 처리하기 위한 스케줄러입니다.Schedulers.parallel()// 한방 쿼리를 좋아하지만..어째거나 여러개의 쿼리를 쨉쨉이 날리 때 기닽.. 등등 좋겠다.// 두 친구의 차이는 반환값이 있고 없고Mono.fromRunnable() vs Mono.fromCallable()  비동기로 처리해도 문제 없는 것들은 비동기로..

집에선 맥미니를 사용하고 있고 회사에선 데스크탑을 사용하고 있다. 빌드에 대한 궁금증이 밀려와 급 테스트 진행ㅋ 기본적인 CPU 성능은 13600K가 우세하다. M2-PRO하고 비교해도 성능은 조금 더 13600K가 우세하다. 성능적 수치는 월등하지만 개발자로서 체감할 수 있는 구동(빌드)시간으로 테스트 해보자고 한다. 결론부터 말하자면 맥의 승리였다. CPU의 성능은 81:58이였지만 I5-13600K 32GB : 게시판 모듈 구동 맥 미니 M1 16GB : 게시판 모듈 구동 인텔리J가 맥에서 좀 더 많이많이 최적화가 되어있다고 생각이 드는 부분이다. 왜 개발자들이 맥맥 거리는 이유가 있다. 난 윈도우가 좋타 ㅋ ### 네이버 VM [Standard] vCPU 2EA, Memory 8GB , [SSD]..

일정이 잡혀있으니... 올만에 쫄렸다. 러프하게 생각했는데.. ㅇ1렇게 공부했음 인서울은.... 지금 다시 수능 보다해도 ㅋㅋ 지방대겠쥬. 평가(?)에 집착하지 말규 잼나게 하자^^ 처음 부터 다시 시작하자!! 이제 2회차닷!! ㅋ 이벤트 서버의 성능 테스트 시작(1) 에서 작성 했고 참고 했던 링크 걸어둔 블로그를 다시 확인해봤다. 놓친부분이 있는지.. 오히려 이해 안가는 부분이 포착되었다. https://hudi.blog/distributed-lock-with-redis/ (일부 캡쳐) https://dkswnkk.tistory.com/712(일부 캡쳐) 락을 획득 못하면 예외처리가 된다. 그럼 선착순이 맞나??? 오잉.. 해서 로그 심어서 비슷하게 테스트.. 32번째로 요청했던 친구는 락 획득 못하..

몇 가지 테스트를 더 해봐야겠지만 아래의 성능 차이는 역시 돈이다. 네이버 클라우드에서 제공해주는 로드 밸런서는 부하 처리 성능을 설정할 수 있다. Small과 Large 차이로 인한 TPS차이....돈이면 안되는거 없제! 그래도 애저나 아마존 비하면^^ 너무나도 훌륭하죵!! 2분 부하를 주는 동안 다른 메뉴들이 버버버벅!!! ※ 인그레스 콘트롤러만! 2개로 장착하고 테스트! 확실히 안정적이다. 진행하는 동안 다른 메뉴에서의 버벅임 존재 없음! 스케일 아웃을 하는 이유라고 본다. : Err Rate 비율도 내려갔다. ※ 이벤트 서버만 2개로 장착 : 그냥 알것 같아서 패스! TPS가 조금 상승하겠지 뭐.. ※ 인그레스 2 + 이벤트 서버 2 : Try 유의미한 결과로 훈훈하게 끝날줄 알았다.. 선착순 승..

일단 아르메리아가...핀포인트에 요청이 정상적으로 집계되지 않아서... ㅠ 단순 스프링으로 전환해서 진행하였다. (이것도 일이다. ㅡㅡㅎ) 아오!!! 일단 이미 결과를 리포팅 했지만 이제서야 글을 정리한다 진정 하는것 없이 바쁘다 논-블록킹으로 처리 되는 서비스에서만 유용하기 때문에 무조건적으로 좋은 것이 아니다... 오히려 블록킹이되는 코드가 있으면 역효과가 날 수 있기 때문에..무조건적으로 도입할 이유는 없다. 두가지 케이스가 같은 response을 주긴 하지만 1. webMvc는 스프링 시큐리티에서 제공해 주는 Oauth를 이용하였고 2. webFlux는 딱 원하는 기능만 자체 개발했기 때문에 비교 자체가 애매 하긴 하지만 우리가 얼마나 웰메이드 된 친구보다 효율적으로 만들었는지 증거가 될 수 있기..

모든 지표나 설명이 webFlux!! 와우!! 하고 있다. 그럼 나도? 어 너도? VS Webflux WebMVC Oauth2.0 직접 구현 org.springframework.security.oauth spring-security-oauth2 Stack Reactive Stack armeria-spring-boot2-webflux-starter Servlet Stack spring-boot-starter-web db 연결 방식 r2dbc jdbc 공통 레디스, 마리아DB 내가 마든 webflux가 느려도 너무 느리다. (TPS가 두배가 안 된다.) 불행중 다행인건.. 리소스는 알고 있던대로 효율이 좋았다!! 왜 느린지! 일단 아르메리는..pinpoint에서 샘플링을 못한다. ㅠㅠ

로깅 서버를 통해서 이미 한번은 진행해 봤지만 또 해보자잉! async, non-blocking에 대한 성능이 체감할 수 있을까?? 부하툴 : ngrinder (https://naver.github.io/ngrinder/) 서버 Sepc. : Standard_D2s_v3 (azureprice.net) Azure VM Comparison azureprice.net ## 부하는 로컬에서 CPU와 메모리가 Full 차도록 줘보자!! ## 테스트 시나리오 1. 인증코드를 받는다. 2. 인증코드를 통해서 토큰을 발급 받는다. 그루비 !! @Test public void test() { HttpRequest request_code = HttpRequest.get( "http://4.230.35.161/oauth/a..