Conversation
ymkim97
requested review from
GeunJuLEE,
TaeHyoungKwon,
chichoon,
dhlee3994,
hemil0102,
jongfeel and
tttghost
ymkim97
added
2026
Street Coder: The Rules to Break and How to Break
|
우측에 있는 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a summary of chapters 7 to 9 of 'Street Coder', discussing optimization, scalability, and bug management. The review feedback focuses on improving technical terminology, such as using 'Doherty Threshold' and 'Jira', and clarifying the relationship between locking and scalability.
| ## 논의 내용 | ||
| * 최근에 어떠한 형태로든 최적화를 진행했던 경험에 대해서 얘기해보면 좋을 것 같습니다. | ||
| * p95가 1초대로 꽤 길게 잡히던 API가 있었는데요, Flame graph를 이용해서 시간이 오래 걸리는 지점을 찾아 100~200ms대로 최적화를 했었습니다. DB 쿼리 후 좀 길게 그래프가 구멍이 생겼었는데, 분석해보니 가져오는 row가 너무 많아(몇만 개, ORM 사용중) 조건을 넣어 대상 데이터를 좁히면서 해결되었습니다. |
There was a problem hiding this comment.
최근에는 성능관련해서 처리한부분은 없었던 것 같네요
과거에는 DB 쿼리 튜닝을 많이 했었습니다 말씀해주신 사례 처럼 latency가 긴 trace 기준으로 병목구간이 DB쪽인지 확인하고, DB일 경우에 쿼리 확인해보고 수정하는 방식으로 많이 작업 했었습니다
| ## 7장 ~ 9장 | ||
| --- | ||
| ## 논의 내용 | ||
| * 최근에 어떠한 형태로든 최적화를 진행했던 경험에 대해서 얘기해보면 좋을 것 같습니다. |
There was a problem hiding this comment.
(클로드가 알아서 최적화 해주게 시킨 경험 제외하고...)
저 역시도 DB에 데이터가 많이 쌓이게 되면 조금씩 응답 시간이 느려지는 경향 때문에 디버깅 해 보고 쿼리를 수정하는 방향으로 하는 작업이 더 많았던 것 같긴 합니다.
그 외에 웹 프론트 쪽에서도 느리게 로딩되는 부분에 대해 지연 로딩 방법을 써서 사이트가 로딩하는데 오래 걸린다는 느낌을 안받도록 바꿨던 적도 있습니다.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
| ## 논의 내용 | ||
| * 최근에 어떠한 형태로든 최적화를 진행했던 경험에 대해서 얘기해보면 좋을 것 같습니다. | ||
| * p95가 1초대로 꽤 길게 잡히던 API가 있었는데요, Flame graph를 이용해서 시간이 오래 걸리는 지점을 찾아 100~200ms대로 최적화를 했었습니다. DB 쿼리 후 좀 길게 그래프가 구멍이 생겼었는데, 분석해보니 가져오는 row가 너무 많아(몇만 개, ORM 사용중) 조건을 넣어 대상 데이터를 좁히면서 해결되었습니다. |
There was a problem hiding this comment.
저도 최근에는 딱히 없었던 것 같은데, 가장 어이없던 성능 최적화 경험은 임시 데이터가 많은 것이 보기 좋지 않아서 지웠더니 성능이 빨라졌던 경험이 있습니다. 아마 임시 데이터가 너무 많기도 하고 데이터들이 편향되어 있어서 그랬던 것 같은데, 확실한 이유를 짚고 넘어가지 않았던게 지금 생각해보면 좀 아쉽네요.
| --- | ||
| ## 논의 내용 | ||
| * 최근에 어떠한 형태로든 최적화를 진행했던 경험에 대해서 얘기해보면 좋을 것 같습니다. | ||
| * p95가 1초대로 꽤 길게 잡히던 API가 있었는데요, Flame graph를 이용해서 시간이 오래 걸리는 지점을 찾아 100~200ms대로 최적화를 했었습니다. DB 쿼리 후 좀 길게 그래프가 구멍이 생겼었는데, 분석해보니 가져오는 row가 너무 많아(몇만 개, ORM 사용중) 조건을 넣어 대상 데이터를 좁히면서 해결되었습니다. |
There was a problem hiding this comment.
성능 관련해서는 DB 조회에 대한 값에 스프링 캐싱을 추가하여 무의미하게 DB를 계속 조회하는 부분 제거를 한 정도 일거 같아요. 그거 말고는 호출 api 중 중요도 낮은걸 비동기로 변경하였습니다.
5 participants
Closes #652
이번 책도 재미있게 잘 읽었습니다.