[BG-205]: 워크스페이스 가입 승인 요청이 10명 이상일 때 가입 승인 요청 API가 거절된다 (6h / 3h) #71
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why
일단 이 세가지를 다 해보고 결과를 비교해보다 보니 시간이 오래걸렸다.
How
일단 3가지 방법으로 락을 잡고 결과를 비교해보기 전에 TPS가 높을 것이라 예상한 순서는
1번, 2번, 3번 순서였다.
1번이 가장 빠를 것이라 생각한 이유
1번은 update 쿼리를 처리하는 시점을 제외하고는 따로 베타락을 잡지 않고 공유락만 걸리기 때문에 다른 요청에서 해당 레코드에 대한 요청을 처리하기 위해 대기하지 않아도 되기 때문에
DB 베타락을 걸어놓는 것이 두 번째라고 생각한 이유
베타락을 거는 것은 일반적으로 DB에 부담을 많이 줄 것이기 때문에 가장 느리다고 생각하기 쉽지만, 분산락을 잡는 것도 어차피 트랜잭션이 시작하기 전부터 트랜잭션이 끝날 때까지 잡으면 해당 요청의 흐름을 방해하는 것은 똑같기 때문에 추가적인 네트워크(레디스)를 또 타지 않는 베타락이 좀 더 빠를 것이라 생각했다.
하지만 결과는 2번, 1번, 3번 순서였다.
분산락이 가장 느릴 것이라 생각했던 예상은 맞았지만
2번이 가장 빠른것은 의외였기 때문에 멘토님께 질문드리고 싶어서 3가지 코드를 다 올려놨다.
Result
https://bald-risk-259.notion.site/9c53d96c2ae944f89868dfa0f409e5b3?pvs=4
Link
BG-205