하도록 만들어놨다 ㅋㅋㅋㅋㅋㅋ
문서화시키는 수준의 api에 대해서 전부
데이터 경합률 통계낼거고
경합 높아서 실패율 높은거는 따로 처리할거임.
이게 생산성 높은 방식이라고 생각한다.
로깅에 db처리 들어가서 성능 느려지긴 하는데
나 좆소야 ㅋㅋㅋ
좆소때 다 로깅하고 경험하고
어느경우에 데이터가 경합되는지 측정하고
경합을 허용하고 통과할지,
강한 락으로 막아버려서 무조건 해결하고 통과시킬지
아니면 그때가서
이거 사실 좋은 회피책있다
하고 생각하던지
여튼 감각이 먼저라고 판단했음.
모든 데이터에다가 경합 추적 달아놨음
경합 바로 차단시키면 당연히 ㅈ대니까 리트라이 달아놨음. 3번. 통계 api별로 저장해서 성공률 실패율 다 로깅하고 모니터링 가능함
이게 리트라이할때 또 튕길 확률이 더 높은건 아님. 왜냐면 트라이도중에 "커밋"이 들어올때만 실패하는거라 단순히 두개가 서로 얽혀있다고 계속 뭐 실패 실패 실패 하지 않음. 트랜잭션이 겹칠때 실패가 아님. 커밋이 이 찰나에 들어왔냐 에 따라서 실패가 결정됨
딱국아 운전면허 있냐
그리고 너 자취함? 세탁 요리 설거지 너가 함??
ㄴㄴㄴ 나 요즘 다시 프로그래밍 올인인생살아서 엄마가 좀 고생하고계심 ㅠㅠ
그렇군
apm같은 모니터링 툴을 도입햇단거임 아님 걍 로그만 찍엇다는거임?
모니터링이래봤자 별거없음. 좆소니까 대응 바로 안해도 되니까 그냥 뷰만 만들어놨음 보기 쉽게
어차피 걍 숫자만 찍는거야 진입횟수 에러횟수 종료횟수 종료시 최종적으로 해결이 안된 횟수 걍 도표로만 찍는거임
이거 애초에 데이터경합. 서비스 원활하게 해준답시고 만든거 아님. 뭐 완벽주의도 아님. 왜 만들었냐면 공부용임 ㅎㅎㅎㅎ. 이걸 해야 직원도 나도 발전하지. 동시성 어떻게 처리할지, 데이터를 기반으로 판단하는게 좋지 않겠음?
통계는 시발 미래예측 마법의 소라고동놀이하잡시고 하는거 아니지. 현 황을 투명하게 보여주는것. 그게 통계지
성능이 존나 중요한 영역은 로깅 빼면됨. 일단 좆소때 데이터 뽑아보고 이럴때 어떤일발생하는지 다 경험하고 사태파악하고 문제해결책 도입해보자고 로깅 다찍는거야
로깅 선택적으로만 넣을수 있음
근데 이거 만들어봤자, 직접적으로 트래픽 만들어서 시도해볼거 아니면 ㅋㅋㅋㅋ 실패율 0나오지 뭐 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
좆소라서