21.02.16 01:55 작성
·
934
1
안녕하세요 김영한님,
querydsl 강의를 수강중인 학생입니다.
수강중에 문득 querydsl 은 동적으로 query 를 만들어주는 도구이다 보니
jdbctemplate 와 querydsl 간의 성능에 따른 차이가 있을것으로 생각되어 검색을 해보았습니다.
아래의 stackover flow 에 기재된 내용으로는 약 6배 정도 차이가 난다고 적혀있는데요
실무에서 이정도의 성능적인 차이가 발생하는지 궁금합니다.
https://stackoverflow.com/questions/38123217/performance-tests-between-querydsl-sql-vs-jdbctemplate
만약에 이렇게 성능적으로 차이가 많이 발생하게 된다면
실제 service 단계에서도 서버의 메모리나 확장에 관해서도 많은 리소스가 추가로 투입이 되어야할것 같습니다.
최근들어 쿠버네티스를 통해서 이러한 성능적이슈를 효율적으로 관리한다고 귓동냥으로 듣기는 했습니다.
저의 생각으로는
휴먼리소스를 투입해서 jdbctemplate 으로 코딩 할것인가 아니면 자본을 투입하여 문제를 해결할것인가의 문제로 보여 어떤것에 가치를 두냐에따라 답이 다른것같습니다.
이러한 jpa, jdbctemplate 의 성능적인 관점에서 김영한님 생각이 궁금합니다.
약간은 수업의 방향에 어긋나는것 같은 질문이라 조심스럽습니다...
(ps. jpa 와 querydsl 의 성능을 비교하게 비슷할까요..? )
답변 1
5
2021. 02. 16. 23:05
안녕하세요. 동하님 좋은 질문입니다.
결론부터 말씀드리면 실무에서 성능 차이는 거의 0에 가깝습니다.
왜냐하면 암달의 법칙 때문이지요.
실무에서 성능 지연이 있는 대부분의 경우는 애플리케이션 메모리 영역의 문제가 아니라 DB의 문제입니다.
예를들어서 상황에 따라 다르겠지만 전체 시간이 100ms가 걸린다고 하면
애플리케이션에서 차지하는 비중이 10ms 정도 되고, DB나 네트워크에서 차지하는 비중이 90ms가 됩니다.
애플리케이션 메모리의 속도를 50% 줄여도 5ms 밖에 절약이 안되는 것이지요.
따라서 실무에서는 대부분 네트워크나 데이터베이스 속도에 성능이 좌우되고, 애플리케이션 메모리에서 동작하는 기능은 거의 영향을 주지 않습니다. (실제로는 말씀드린 예제보다 훨씬 더 데이터베이스에 영향을 받습니다.)
그래서 애플리케이션 메모리나 CPU는 많이 사용하더라도, 개발을 더 생산적으로 그리고 효율적으로 할 수 있는 방법이 중요합니다.
그리고 성능 튜닝의 경우 정말 많은 사용자가 사용하는 특정 지점을 대상으로 일부 튜닝을 하는 것이 좋습니다.
도움이 되셨길 바래요.