해결된 질문
작성
·
175
0
안녕하세요.
강의 내용 중에
"커넥션 풀을 사용하기 때문에 Parse-tree 를 캐시하고 재활용하는 부분이 매우 비효율적으로 바뀔 가능성이 높다"
라고 언급하신 부분이 있는데 이 부분이 잘 이해가 안되서 질문드리고 싶습니다.
히카리같은 커넥션 풀을 사용하면 커넥션이 닫히지 않고 계속 재활용하게 되서 이미 캐시된 Parse-tree를 재활용 할 수 있기 때문에 오히려 이점이 있는 것이 아닌가 단순하게 생각이 되는데요,
예를 들어 1번 커넥션에서 A쿼리 패턴으로 PreparedStatement 객체를 생성하여 mysql 서버에 캐시가 되었다면,
다시 동일한 1번 커넥션을 사용하여 A쿼리 패턴을 쓰게 된다면 이미 캐시된 Parse-tree를 재활용하는 것이 아닐까? 이렇게 생각했거든요.
어떤 점에서 비효율적으로 동작할 가능성이 있다는 것인지 궁금합니다. 바쁘신데 읽어주셔서 감사합니다.
답변 1
1
안녕하세요.
말씀주신 아래 내용은 맞습니다.
예를 들어 1번 커넥션에서 A쿼리 패턴으로 PreparedStatement 객체를 생성하여 mysql 서버에 캐시가 되었다면,
다시 동일한 1번 커넥션을 사용하여 A쿼리 패턴을 쓰게 된다면 이미 캐시된 Parse-tree를 재활용하는 것이 아닐까? 이렇게 생각했거든요.
근데, 조금 다른 관점으로 살펴보면,
이게 작동하려면, Connection 단위로 모든 PrepredStatement 객체가 삭제되지 않고 관리되어야 해요. 예를 들어서, 응용 프로그램에서 필요한 쿼리의 패턴이 만약 100개 정도가 있다고 가정해볼게요. 그러면 Connection 단위로 PreparedStatement가 100개씩 캐시되고 있어야, MySQL Server-side에서는 SQL의 Parse-tree라도 재활용될 수 있는거죠. 근데 만약 모든 응용 프로그램에서 사용하고 있는 Connection이 5000라고 가정(예를 들어서 AppServer가 100대이고, 각 AppServer가 Connection을 50개씩 가지는 경우)해보면, App Server에서는 각 서버별로 PreparedStatement 객체를 5000(50 x 100)개를 가지고 있어야 하고, MySQL 서버에서는 500000 (5000 x 100)개의 Parse-tree를 메모리에 가지고 있어야 하는거죠. 근데, MySQL 서버의 preparedstatement 개수는 지정된 개수만 캐시하게 되기 때문에, (동영상에서 언급했던) 또 다른 이슈도 생길 수 있는거죠.
결론은 Parse-Tree가 재활용되지 못한다는 의미가 아니라, 너무 많은 Parse-Tree가 관리되어야 한다는 부분을 지적한 내용이라고 보시면 될 것 같습니다.
감사합니다.