<noscript></noscript>
<textarea style="DISPLAY: none" id="save_comment_36318">왜 php에서는 pool을 쓰기 쉽게 안해놨을까요??대용량 시스템에서는 필요한 거 아닌가요???</textarea><textarea style="DISPLAY: none" id="save_comment_36319">전역으로 사용하신다면 php.ini 에 로드시키는게 낳습니다.http://www.phpschool.com/bbs2/inc_view.html?id=10093&code=tnt2&start=0&mode=search&field=title&search_name=&operator=and&period=all&category_id=&s_que=sqlrelay</textarea><textarea style="DISPLAY: none" id="save_comment_36320">컨넥션풀의 의도는 좋지만 효용성이... ;1. 트랜잭션 등이 컨넥션 단위로 이뤄지므로, 이전 컨넥션을 디스컨넥 하지 않고 승계했을 때 발생하는 트랜잭션 관련 문제..2. 컨넥션풀을 쓴다 해도, 최대 컨넥션을 다 채웠을 경우는 도움이 되지 않는다.3. 컨넥션풀의 미들웨어(!)를 쓸 때 발생하는 속도저하문제...4. 컨넥션풀은 컨넥션을 하는 작업 자체가 과도한 부하(시간 및 cpu 자원등)를 유발할 때 해결책이 될 수 있는데,mysql 및 기타 대형DB 들도 컨넥션에 드는 부하는 그리 크지 않다... ;;-- jeon.</textarea><textarea style="DISPLAY: none" id="save_comment_36321">/jeon1. 트랜잭션은 커넥션 단위라기 보다는 디스커넥트 발생시 자동으로 comit 또는 rollback 등이 발생되는 개념이며, 명시적으로 또는 pool에서 이에 대한 commit / rollback을 지원한다.2. 커넥션 풀의 용도는 가용성이 아니라, 커넥션 생성에 드는 비용을 줄이기 위함이다.3. 속도저하 문제는 막연한 추측만으로 이룰 수 없다. 실제 프로파일러를 통해 산출물을 보면, 반영효과에 비해 상당히 미비하다.4. 커넥션에 드는 비용은 생각보다 크다. 또한, 시스템의 부하는 차치하고서라도, 커넥션 자체에 딜레이 되는 타임은 시스템의 규모에 따라 상당한 장애로 발생한다.</textarea><textarea style="DISPLAY: none" id="save_comment_36322">널리 쓰이는데는 그에 합당한 이유가 있기 </textarea><textarea style="DISPLAY: none" id="save_comment_36323">php에서 pool를 사용하여대용량시스템을 구축해보신경험이 있는 분들이 계신가요??왜 php에서는 널리쓰이질않는건지 궁금합니다..위에 장단점만을 봤을때는굳이 pool을 쓸필요가 있을까? 라는 생각이 드네요.</textarea><textarea style="DISPLAY: none" id="save_comment_36324">헤즐넛님이 적으신 글에 비슷한 문서가 있군요. 뭐 그래도 이렇게 한번 더 글을 올리면서 또 생각해볼수 있으니 도움이 되겠죠. 관련된 참고자료를 마지막에 추가하였습니다. 근데 헤즐넛님 어디서 계속 아이디는 본듯한데. 아닌가?</textarea><textarea style="DISPLAY: none" id="save_comment_36325">오해를 님에게 ~물론 님이 하신 말씀을 전혀 모르고 글을 올린 것은 아닙니다.. 제게 근거를 요구하셨듯이, 오해를님도 그에 대해 기술적인 근거를 제시할 수 있습니까.. ? 저처럼, 오해를 님도 나름대로의 경험과 지식에 근거할 뿐 아닐까요.논쟁을 할 필요까진 없어 보이니까... 님의 생각을 바꾸려 노력하거나 제가 변명하려 노력할 필요는 없어 보이구요.위 문제들 다 접어둔다 해도... 4 번 문제, 컨넥션에 드는 비용문제인데요.웬만한 DBMS 라면 자체에서 쓰레드풀을 구성하고, 요청에 대해 이 쓰레드풀내에서 컨넥션을 갖지 않나 싶습니다.쓰레드 생성 자체에 OS 마다 차이는 있지만 적지않은 부하가 있으니까요. 따라서, DB자체에서 쓰레드풀을 갖고 있는 만큼, 외부에서 별도의 쓰레드풀을 처리할 필요성은 없다고 보여집니다..이 외에, DB 가 처리하는 내부 메모리구조 등과 관련한 컨넥션 초기화에 드는 부하가 있겠지만, 이정도도 역시 DBMS 내에 처리루틴이 어느정도 있다고 생각됩니다. 이건 고난이도의 \＇아이디어\＇가 아니라, 아주 평범한 아이디어라서요... ;;또한 경험에 의해서도, 오라클이든 mysql이든, 다른 어떤 것이든 컨넥션 자체에 큰 부하를 느껴본 적은 없었습니다...;;이에 대해 저도 mysql 소스코드를 들여다보거나, 오라클 에 기술적 문의를 해보거나 한 적은 전혀 없으므로, 그냥 개인적인 \＇추측\＇일 뿐입니다.-- jeon.</textarea><textarea style="DISPLAY: none" id="save_comment_36326">전영규//당연히 고난이도의 아이디어가 아닙니다. 왜냐고요. JAVA에서 JDBC와 주로 쓰이는 것 이고, 웬만한 WAS라면 Connection pool은 필수적으로 있으니까요.</textarea><textarea style="DISPLAY: none" id="save_comment_36327">전영규//그리고 커넥션풀과, 쓰레드풀과는 전혀 연관이없는듯하군요. 쓰레드가 아무리 많다하더라도, 커넥션을 다시 맺으려면 expensive cost가 들게 되있으니까요.</textarea><textarea style="DISPLAY: none" id="save_comment_36328">개씨박님따라서 하고 싶은 말은 무엇인가요 ?외부에서 따로 구현하는 컨넥션풀에 대해 필요하다고 생각하는 입장인가요 ? 정확히 구분이 안가네요... 아니면 그것과 관계없이 제 말에 대해 \＇평가\＇ 하는 중인가요 ?가능하면 컨넥셕풀의 필요성에 대해 좀 분명한 말씀들을 해주시면 좋겠네요... -- jeon.</textarea><textarea style="DISPLAY: none" id="save_comment_36329">/jeon기술논쟁에서 제일 까다로운 최소한의 예의를 가장한 오기성 글이군요. (예의가 중요한게 아니라 정작 중요한 기술적인 논리가 부족하다는 의미입니다.)mysql은 몰라도 oracle 소스 들여다 보는 개발자들이 몇이나 있을까요? 소스를 들여다 봐야 모든 진리를 알 수 있다면, 대부분의 논쟁은 무의미 해질겁니다.4번에 대해 아주 자세한 근거를 대라면, 글쎄요. 커넥션풀 구성 이전과 이후의 프로파일러 레포트를 제출해야 할까요? 그럴 필요까지는 없겠죠. 너무나도 당연한 결과이니까. (또한 이러한 BMT 레포트들은 각 풀 사이트에 가셔도 대부분 상세히 나와 있을겁니다. 이 부분에 대해서 또 다시 왈가불가 할 필요는 없을 듯 합니다. 퍼나르는 노동밖에 되지 않을테니까요.)제가 지적한 것은 jeon님께서 추측성으로, 그러나 대부분 옳지않은 내용을 보고, 후배님들께서 \＇아 풀은 그다지 유용하지 않은거구나\＇ 또는 \＇트랜잭션등에서 문제가 생길 수 있으니 사용하면 안되겠구나, 오히려 부하가 더 걸릴수 도 있겠는걸.\＇ 하고 그릇된 판단을 할 수 있기에 지적해 드린 내용입니다.프로젝트 종결 후, 완료보고계가 올라가고 여기에는 스트레스 테스트, 프로파일러 레포트, 무결성 점검, 유닛테스트 보고서등이 제출되고, 이 산출물들을 기반으로 감사를 진행하게 되지요.제가 말하는 경험이란, 막연한 경험과 노하우를 말씀 드리는 것이 아니라, 실제 풀의 적용 이전과 이후에 따른 위의 절차를 거치면서 나온 결과이고, 전영규님의 경험이란 글쎄요, 단순한 느낌과 top등과 같은 간략한 시스템 트레이스 툴 정도를 이용한 추측 정도로 밖엔 보이지 않습니다. 이는 한번이라도 구체적인 레포트를 작성해 봤다면, 너무나도 숫자적으로 확연히 차이가 벌어지는 결과물이라 논쟁의 의미가 없어 보입니다.또한 기술적인 근거라 할 수는 없겠지만, 데이터베이스 관련 부분은 해당 프로덕트의 로컬 매니저들에게 감사를 받고, 최종적인 튜닝에 대한 자문도 구하는 단계에서 축적된 경험(jeon님께서 언급하신 기술적 문의등은 너무나도 당연히 이루어지겠지만, 그래도 단순한 경험에 분류될 뿐입니다. 예를들어, 오라클 소속 엔지니어라 해도, 담당 엔지니어의 성향이나 자질의 문제에 따라 상이한 결과가 나오기 때문이죠.), 또는 직접 테스트 유닛을 만들면서, 프로파일링을 할 가치조차 못 느낄 형편없는 결과물을 나왔었던 이러한 \＇안\＇ 좋았던 개인적인 경험을 제시할 수 있겠군요. 아시다시피 사람들은 끔찍했던 원인에 대해선 보다 선명히 기억하니까요.논쟁이라는 것이 막연한 추측만으론 정말 곤란합니다. 더군다나 이렇게 오픈된 자료들이 충만한 내용에 대해서도, 명확한 근거를 제시하라란 식의 말씀은 아무런 의미가 없어 보입니다. 마치 태권도가 왜 몸에 좋은가?에 대해 명확한 의미를 제시하라 한다면, 단순히 검색엔진에서 \＇태권도\＇ 라고 쳐 보거나, 태권도 협회 사이트에 들어가라고 밖엔 할말이 없겠죠. (커넥션풀에 대해서도 같은 답변을 드리고 싶습니다.)</textarea><textarea style="DISPLAY: none" id="save_comment_36330">오해를 / 적당한 설명이라고 봅니다.---커넥션풀에서 커넥션이 이루어 지고 끊어지는 부분에 대한 소비를 mysql 문서에 보면 일반적인 쿼리 보다 몇배가 더 소비된다고 나와있습니다. 대부분의 DB들이 실제 쿼리에 대한 처리량에 고심하고 있다는것을 본다면 커넥션부분에 대한 의존도를 다른 프로그램에서 처리해준다면 더할나위 없이 기쁘겠죠.. 게다가 풀을 만들면 다용도로 쓸수 있습니다. 여러 DB 서버를 활용할수 있고, 커넥션 이벤트 또는 디스 커넥션 이벤트에 따른 임의 사용자 프로그램 개발도 용이 하고.. 기타 등등..단순히 DB, 여기서 mysql에서의 쓰레드 방식과 커넥션풀을 비교 하는거 자체가 무리라고 보여집니다. 전님이 말씀 하신 형태라면 몇천만원이나 들이면서 미들웨어를 구입하는 사람들이 골빈 사람들이 되어 버리는 꼴이 될꺼 같다고 보여집니다..특히나 4번 사항에 대한 설명은 적절치 않습니다.. DB 활용에 따라 다른, 즉. 쿼리를 길게 잡고있는 놈들고 있고, 단타로 절라 많이 요청하는 것들도 있는데.. 그렇게 무턱대고 \"별로 없더라\" 식의 내용은 좀 이해가 안가네요... 정말 많은 수의 짧은 요청을 감당하는 경우도 있다는걸 염두에 두셔야 할것 같습니다.좀더 자세한 사항을 알고 싶으면 미들웨어 프로그램의 feature 부분을 보시는것도 좋겠네요..</textarea><textarea style="DISPLAY: none" id="save_comment_36331">아 추가로 개인적으로는일반적인 사용에서는 개인이 커넥션풀까지 쓸 일은 거의 없다라고 느낍니다.. 이 상황에서는 전님의 의견과 비슷한 부분이 되겠죠.... 물론 대형DB에서는 틀리구요..</textarea><textarea style="DISPLAY: none" id="save_comment_36332">전영규님께 대규모 프로젝트를 해보았는지 여쭤보고 싶습니다.몇번의 컨넥션만 이루어지는 단순한 작업은 컨넥션 풀을 쓸필요는 없지만 대규모 프로젝트에서는 상당히 많은컨넥션이 요청될 경우 수많은 컨넥션이 동시에 생기면서데이터베이스가 죽는 상황도 생깁니다.그렇기 때문에 컨넥션 풀을 사용하는거지요.그리고 컨넥션 풀에 대해서 몇가지 잘못 알고 계신 것 같은데요.오해를 님이 적절하게 잘 설명해주신 것 같아서따로 드릴 말씀은 없네요. 컨넥션 풀은 이미 많은 곳에적용되어 있고 상용 WAS 에서도 지원하고 있습니다.그 효능은 이미 입증되었다고 봐도 괜찮을 것 같습니다.</textarea><textarea style="DISPLAY: none" id="save_comment_36333">위에 제게 반박글 써주신 분들께 감사드립니다.윗분들 말대로 커넥션풀이란 미들웨어를 씀으로서 얻는 컨넥션 부하 단축의 효과가 있을 거란 것은 전혀 무시하는 바가 아닙니다.그러나, 과연 그 효과가 어느정도인지 구체적으로 아시는 분 계십니까 ?뭐, 10% 향상이라던가 400% 향상이라던가.그리고, 이게 벤더의 말이 아니라, 실제로 테스트를 진행하여 얻은 결과인지도 알고 싶군요.제가 제 경험과 추측으로 글을 쓰는 것은 순전히 \＇제 의견\＇ 일 수 있습니다. 그러나 여러분들이 쓰는 글은 \＇벤더\＇와 \＇일반적인 선배들의 지침\＇에 의존하는 것은 아닌지 더욱 궁금해집니다.오기를 부리는 것이라고 생각되시나요 ?전혀 그렇지 않습니다.저는 오히려 궁금한 것이 있는데, 확실한 답을 구할 수 없기 때분에 답답합니다. 확실한 답이 구해지면, 저도 제가 잘못 알고 있다는 것을 당당히 인정할 수 있고, 이 코멘트들을 읽게 될 다른 후배들(?)에게도 좋은 간접경험과 지식이 될 것입니다.그러나, 확실한 답을 구할 수 없다면,여전히 저는 제 생각을 멈출 수 없을테고, 여러분은 또 여러분대로 답답한 마음으로 저를 바라볼 겁니다.계속해서 \＇답답하다\＇고 토로하는 것은 의미가 없습니다.구체적인 수치를 제시할 수 있습니까 ? 그렇지 않다면 본 토론은 진전이 없습니다.위에 글들을 자세히 읽어 보세요. 제가 했던 말이나 여러분이 했던 말이나 계속 반복되고 확장 될 뿐, 다른 안건이 제시되지 않고 있습니다.-- jeon.</textarea><textarea style="DISPLAY: none" id="save_comment_36334">까다로운 분이시네요.말씀하시는대로 하자면 두개의 알고리즘이 있는데그 중 하나의 알고리즘이 성능이 다른 하나보다 떨어질 경우성능이 좋은 알고리즘이 과연 안좋은 알고리즘의 정확히몇배의 효율을 가지고 있는지 아주 정확히 따지고 씁니까?그리고 풀링의 장점들은 이미 위에서도 설명되었고 더 정확한자료는 검색해보면 많이 나옵니다. 더욱더 정확한 답을원하신다면 더 드릴 말씀은 없습니다. 언젠가 본인이직접 경험해보면 알게될겁니다. :)</textarea><textarea style="DISPLAY: none" id="save_comment_36335">풀의 개념은 성능 향샹이라는 목적도 있지만, 가용 자원을 제한할려는 목적도 있습니다.mysql 이 과부하로 사이트 자체가 죽어버리는 것보다 , 어느정도 사용자가 증가하면(connection 개수가 증가하면) 특정 컨텐츠나 서비스에 더이상 사용자가 접근하지 않도록 할수도 있는거죠.동일 mysql를 쓰는 사이트에서, A 서비스가 max 10개의 컨넥션을 쓰고, B서비스가 max 10개의 컨넥션, C에서 max 10개의 컨넥션을 쓴다고 했을때, A서비스에 10개 이상의 접속요청이 들어오더라도 B,C에서는 정상적으로 서비스가 되죠. A에서 컨넥션을 다 소비해버려서 A,B,C 서비스 모두가 중단되는 경우는 안생기는거죠. 게시판의 경우 mysql로 쓰는경우가 많은데, 사용자 접속이 특히 많은 게시판만 따로 pool을 구성해서 쓰다면, 게시판 접속이 폭주해서 사이트가 마비되는 경우를 막을수 있겠죠.php에서 connection 풀을 제대로 사용할수 있다면, 쓰는게 훨씬 좋습니다. 그런데,, php가 apache의 fork 기반(아파치2.0은 제외) 프로세스를 쓴다면 컨넥션 풀을 사용하기 위해서 socket나 pipe 로 연결을 해야 할텐데..여기에 과부하가 걸리면 어떻게 되는건지? 쉐어드 메모리를 통해서 서비스 되는것인지.그리고, 풀 자체가 c로 작성된 데몬 같은데, 풀이 오류로 죽어버리면 어떻게 되죠? 그만큼 안정성에 문제가 없어야 할것 같은데.. 프로세스 기반으로 작동되는 apache에서 pool 이라는 개념이 잘 안 맞는것 같네요.</textarea><textarea style="DISPLAY: none" id="save_comment_36336">명랑폐인님 말씀이 맞아 보이는군요. 저희가 토론해야 될것은전영규님처럼 정확히 어느정도 효율이 있는지를 따지기 보다는과연 프로세스 기반에서의 풀이 과연 효율적인지를 따져보는것이 옳은게 아닐까요?</textarea><textarea style="DISPLAY: none" id="save_comment_36337">명량폐인에 동감</textarea><textarea style="DISPLAY: none" id="save_comment_36338">우와님께제가 좀 까다로운 면이 있습니다. 개발자라면, 까다로울 때 까다로워야 하는 거 아닌가 싶군요.그 알고리즘이 효율적이지 않다는 것은 위에 제가 처음 코멘트 단 것에 이미 밝혔고, 그 이후에도 계속 같은 입장입니다.그렇기 때문에, 수치 데이타가 없다면 별로 라는 입장이구요.명량폐인님 말씀엔 당연히 동의합니다.새로운 관점에서 컨넥션풀을 바라보는 방법을 주셨네요.맞습니다. db 서버는 1 개 이고, 이에 접속하는 아파치나 어플이 다수일 때 컨넥션풀은 각각의 접속서버에서 제한을 주는 용도로 사용될 수 있을 것입니다.여러 경우의 수가 있겠지만, 전반적으로 이 아이디어는 유용하다고 보여집니다.그러나, 명량폐인님 역시 그 이후 말씀에서 컨넥션풀 자체의 유용성에 대해서는 다시 적절한 수용이 필요하다는 언급을 하셨군요. 비온뒤 님께. 제 생각엔 필요없다 입니다.-- jeon.</textarea><textarea style="DISPLAY: none" id="save_comment_36339">명량폐인님께... 이건 다소 본 토론과 별 관계가 없는 거라서.. 언급을 피하고 싶은 부분이긴 한데요.php가 apache의 fork 기반(아파치2.0은 제외) 프로세스를 쓴다면 컨넥션 풀을 사용하기 위해서 socket나 pipe 로 연결을 해야 할텐데..여기에 과부하가 걸리면 어떻게 되는건지?--> 쓰레드 기반이라도 socket나 pipe 로 연결을 해야겠지요. ipc 프로토콜로 알려져 있다면, 쓰레드도 부모 프로세스기반이므로, ipc 프로토콜을 벗어날 수가 없으니까요..따라서, 프로세스기반이기 때문에 컨넥션풀이 안좋다.. 라는 건 적절한 결론이 아닙니다.. ;;이후 와우 님께도 마찬가지 말씀을 드리고 싶군요.그보다는, 컨넥션 풀 자체의 안정성이나 부하문제, 컨넥션타임을 과연 얼마나 줄여줄 것인가에 대한 수치데이타 문제 등이 여전히 중요변수 아닐까요... -- jeon.</textarea><textarea style="DISPLAY: none" id="save_comment_36340">혹시 도움이 될까 몇자 적어 봅니다.저희는 php 에 oracle9i를 이용하고 있습니다.현재는 php DB pooling 중 sqlrelay를 이용하고 있습니다.테스트 머신 : X86 Linux (Redhat)DB : oracle 9iLANG : php이용 목적:1.php 에서 oracle9i의 disconnect 가 제대로 안되는 문제와 2. 사용자가 몰렸을 경우 위의 문제로 db connect 을 많이 물게되어 db 서버의 리소스를 많이 잡는 문제장점과 테스트시 향상율 1. db 서버의 부하감소 20%2. 속도향상(ab를 이용 테스트 10~20% 향상됨)3. 웹서버의 메모리 사용량 감소..(이부분은 기존의 oracle 펑션을 이용하지 않고 sqlrelay의 펑션를 이용하면서 아마도 오라클 클라이언트 모듈이 로딩되지 않아서 일까 추측 됩니다. 예전에는 httpd 데몬 하나가 50M 이상 잡아먹던게 5~6M가로 줄었습니다.)덕분에.. 웹서버의 메모리 사용량도 줄이게 됐습니다.단점1. 단점이라면 아직 오라클(오라클만 테스트해봤음^^)을 제대로 지원하지 못하는 문제단점보다는 우리쪽에 장점이 많아 올 8월 부터 지금까지 쭈욱 이용하고 있습니다.</textarea><textarea style="DISPLAY: none" id="save_comment_36341">몬아라드꺼따...@.@</textarea><textarea style="DISPLAY: none" id="save_comment_36342">하늘너굴님 좋은 자료 감사드립니다.크게 보아 20% 정도 향상이 있다고 보여지네요.그리고 조언드리자면..disconnect 가 잘 안되는 현상은 php 나 오라클쪽 설정문제를 좀 더 보시면 해결되지 않을까 싶네요. 저는 그런 현상을 거의 보지 못했었는데... 아마 특수상황이 아닐까 싶습니다.3.번 사항은 .. 정말 그렇다면 큰 수확이군요.그런데 역시 일반상황은 아닐 거 같다는 생각이 드네요.. ;;httpd 데몬 하나가 50M 이상 잡아먹는 상황이 해소된 상태라면.. 아마 성능향상도 이 메모리해소에 맞물려 이룩된 성과일 지 모릅니다.따라서, sqlrelay 를 쓰지 않고서 php-oracle 간 조율을 해주면 현재 이룩한 성과와 같은 성과를 얻을 수도 있겠다는 생각이 듭니다.물론, 현재 잘 쓰고 있다면 굳이 그런 실험을 하실 필요는 없겠지만요.... ;;-- jeon.</textarea><textarea style="DISPLAY: none" id="save_comment_36343">전영규//쓰레드 기반이라도 socket이나 pipe로 연결하는게 맞습니다. 제가 예를 잘못 들었네요.. 웹서버가(apache나 tomcat같은) 직접 pool을 관리하는 형태가 아니라면, socket이나 pipe로 연결하는 것입니다.자바의 경우 어플리케이션 내부적으로 pool을 관리함으로, 코드에서 메소드만 호출하면 pool을 사용할수 있습니다.그러니까 apache 서버에서 직접 pool을 관리하는 형태가 아니라면, php가 풀 demon 에게 socket 이나 pipe로 연결하여 쓰는 형태라면, 그에 따른 부하처리는 어떻게 할수 있느냐 하는것입니다. php프로세스가 증가하고, 데몬에 접속하는 socket이나 pipe도 늘어날텐데.. 이것도 성능에 영향을 끼칠수 있다는 것입니다.</textarea><textarea style="DISPLAY: none" id="save_comment_36344">물론이지요.단지 명량폐인님 말씀처럼 쓰레드라고 해서 ipc 를 소켓이나 파이프 아닌 다른 것으로 하는 것은 아닌데, 그에 대한 것만 지적해 드린 것이구요말씀처럼, 컨넥션풀은 기본적인 부하가 있습니다.그에 대한 것을 앞에 계속 말씀드렸던 것이구요... 제가 쓴 첫 글에서 3 번 항목과 유사한 사항이네요..3. 컨넥션풀의 미들웨어(!)를 쓸 때 발생하는 속도저하문제...-- jeon.</textarea><textarea style="DISPLAY: none" id="save_comment_36345">위에 .. 4번과도 관련이 있지만, 3번에 더 관련이 있다는 뜻입니다...-- jeon.</textarea><textarea style="DISPLAY: none" id="save_comment_36346">문태준님의 글을 이곳 php 커뮤니티에서 보게되다니...ㅇㅇ팬입니다. :ㅡ)</textarea><textarea style="DISPLAY: none" id="save_comment_36347">php, mysql 관련된 사이트에서 커넥션 풀링과 관련된 자료를 찾아보아도 그다지 자료가 나오는게 없군요. 위에 토론을 보다보니 궁금해지기는 해서요.저야 자세한 내용까지는 모르겠지만 전영규님 말대로 정확한 근거와 수치를 제시하는것은 필요하다는 생각이 들어요. 저도 잘 못하는 것이기는 하지만 이렇게 이렇게 하는것이 더 좋지 않겠냐는 말은 막연한 것이 있지요. (그래도 아무런 말을 하지 않는것도바는 막연하게라도 표현하는게 더 낫긴한데...)전영규님이 다른 분들한테 계속 억지주장을 하는게 아니라 사람들이 커넥션 풀이 유용하다고 하는데 그에 대한 실증적인 내용과 분명한 근거를 알고 싶다는 의견같네요. 맞나요?좀 다른 이야기지만 이런 것도 있지요. 예를 들어 http 1.1 에서는 keepalive를 지원하며 웹서버에 접속한 경우 일정한 시간동안 연결을 유지시켜줍니다. 그런데 사이트에 접속자가 많으면 오히려 유휴프로세서를 많이 생기게하여 문제를 발생시키는 경우가 생깁니다. keepalive를 off로 하면 시스템상에서 프로세서를 더 자주 생성시키고 소멸시키기때문에 시스템의 부하는 전체적으로 높여지지만 오히려 웹성능자체는 향상될수가 있습니다. 지속적인 연결을 하는 것과 tiemout 값이 접속자가 많은 경우 상당히 많은 영향을 미치지요.DB에서 새로 DB프로세서를 생성하는것이 쿼리를 실행하는 것에 비하면 더 부하를 주는 것이지만 이것이 정말 심각할 정도로 영향을 주는 문제인가 이런 궁금함이 생기네요.커넥션 풀이 나름대로의 장점을 가지고 있다고 하더라도 정말 이것이 커넥션풀을 쓰지 않는 것에 비하여 엄청나게 많은 장점을 가지고 있는것인지 이런 의문은 충분히 가질수 있다는 생각이 듭니다.좀더 나아가면 어떤 경우에 커넥션풀을 쓰는게 더 적합한지 이런 것을 생각할 수 있을듯. 여러가지 경우에 따라 적합한 것이 다를 수 있으니깐요.하늘너굴님이 올린 자료는 좀더 실증적인 자료인데 예를 들어 벤치마킹을 한다면 동시사용자를 올리면서 동시접속처리수와 반응시간에 대한 내용을 함께 알 수 있다면 좀더 도움이 되겠지요. 동시접속자수에 따라 벤치마크 결과가 전혀 다르게 나올수 있기 때문이이죠.SQL Relay도 제공하는 기능이 속도도 있지만 확장성, 여러 디비에 분산 엑세스, 지원되지 않는 플랫폿에서의 db접근등이 있네요.시간여유가 있으면 좀더 자료를 뒤져보고 찾아보고싶지만 지금은 시간이 안되어.음. 쓰고나니 좀 두리뭉실한 글이 되어버렸네요.아 그리고 요즘엔 여기 글을 쓰지 않기는 하지만 예전에 가끔 글을 올린적이 있었지요. 오래되어서 기억이 잘 안나지만.</textarea><textarea style="DISPLAY: none" id="save_comment_36348">오~ 비록 대부분이 알아들을수 없는 얘기지만, 읽는 사람(초보인입장)으로 하여금 정말 공부하고 싶게 만들어주는 토론이네요. 스쿨의 가장 큰 미덕이 아닐까 하네요. 긴 토론 하신분들 모두 감사합니다.</textarea><textarea style="DISPLAY: none" id="save_comment_36349">문태준님 좋은 정리글에 감사드립니다.프로그래밍이나 어느분야에서나... 개인적으로 가장 경계하는 것은 비판없이 수용하는 것입니다.특히 우리같은 개발쪽 분야예선, 이건 거꾸로 우리 자신에게 커다란 억압이 됩니다.다행인 것은 적어도 개발쪽에서는, 실험을 통해 결과를 알 수가 있으니 분명한 결론을 얻기위해 노력이라도 할 수 있어 좋습니다.. (물론 이론적 추론도 가능하고.. )이 문제에 대해 나중에라도 증명할 기회가 있으면 좋겠습니다.어느쪽의 말이 맞든지간에... 지금은 다들 추론 상태니까요.토론에 참여해주신 분들께 감사드립니다... -- jeon.</textarea><textarea style="DISPLAY: none" id="save_comment_36350">mysql 및 기타 대형DB 들도 컨넥션에 드는 부하는 그리 크지 않다 <-- 이부분은 근거가 있는건가요?커넥션의 부하때문에 고심해본적이 있어서 여쭈어봅니다.</textarea><textarea style="DISPLAY: none" id="save_comment_36351">참고하세요... 몇번 테스트해본 결과입니다.컨넥션...mysql : 0.00042sec (한가한 개인서버)oracle : 0.04969sec (좀 비지한 운영서버)-- jeon.</textarea><textarea style="DISPLAY: none" id="save_comment_36352">/jeon추론 상태가 아니라, 이미 많은 자료들이 존재하는 내용이기에 더 이상 언급되지 않는 것 입니다. (또는 이전 글에서 말씀 드렸다시피 사내문서라 오픈을 할 수 없거나, 귀찮은 부분이 가장 크겠지요.)조금만 노력하신다면 관련 자료들은 읽어 보기도 벅찰 정도로 차고도 넘칩니다. 구태여 하나 집어 드리자면, javaservice.net에서 이원영씨의 글이나 직접 검색해 보셔도 많은 사례를 보실 수 있을겁니다. 이러한 명확하고 충분히 스스로들 찾아볼 수 있는 내용에 대해서 증명을 운운한다는 것 자체가 이해하기 힘드네요.또한 단순히 마이크로타임을 찍어, 커넥션 시간을 측정하는 방식으로는 아무것도 알 수가 없습니다. (차라리 스트레스테스트툴을 구하셔서 조금씩 강도를 높여 가면서 측정하시는 것이 정확하실 겁니다.)토론에 발언권을 가진 발언자는 최소한의 참여 자격이 있습니다. 몇몇 잘못된 지식을 버젓이 언급한 후, 그 부분에 대한 지적은 유야무야 흐리고, 예의바른? 감정적 대응으로 넘어가는 것은 초급 개발자들에게는 잘못된 상식을 안겨주고, 중/고급 개발자에게는 씁쓸한 기분을 주어서 참여 자체를 막게 됩니다.이런 부분들이 참으로 아쉽네요.토론은 명확한 본인의 지식을 기반에 두고, 서로간에 배워가는 장 입니다. (최소한 본인이 아는것은 명확히 언급을 하고, 모르는 부분에 대해서는 겸허히 받아들여야 한다는 의미입니다.) 그 최소한의 지식의 기반없이는 아무런 진전없이 상투적인 대화들만 오가겠지요.</textarea><textarea style="DISPLAY: none" id="save_comment_36353">다만 한가지, 비판없이 수용하는 것을 경계한다는 말에는 전적으로 동의를 합니다.다만, 그 부분 역시 서비스 지향 아키텍쳐니 모델 드리븐이니, method/1은 너무 낡지 않았는가, 로즈 보다는 투게더가 더 훌륭한 툴이지 않은가등과 같이 항상 구체적으로 답을 내리기 힘든 부분들에 어울리는 내용이라 생각됩니다.즉, 구체적인 지식과 명확한 결론이 있는 토론과, 개인의 깊은 사색이 필요한 토론은 애초에 분리되어 있다는 의미이기도 합니다.</textarea><textarea style="DISPLAY: none" id="save_comment_36354">찾아봐도 구체적인 성능향상 수치는 없던데요.. ?자바쪽에선 컨넥션풀을 상당히 비중있게 생각하는 듯 한데, 좀 맹목적이군요. 왜 쓰는지에 대한 설명은 간략하고, \＇사용법\＇에 대한 설명은 90% 를 넘는 지면을 쓰고 있습니다.오해를님말씀은 잘 하시는데, 수치를 제공하고 증명해야할 사람은 바로 \＇오해를\＇ 님이 아닌가 싶군요. 제가 찾는것보단 훨씬 양질의 자료를 이미 갖고 계시지 않습니까... 계속 토론을 이어가고 싶다면 자료를 제시하면서 저에 대해 반박하는 것이 방법같군요. 백마디 말보다 한줄의 수치제시면 끝입니다. 계속해서 인문사회학적 토론을 하기 싫으시다면요.-- jeon.</textarea><textarea style="DISPLAY: none" id="save_comment_36355">전제 : 저희 회사에서 풀링을 이용한 전제는 db서버의 성능 향상과 관계가 있고 웹서버의 부하를 줄이고자 하는 목적은 아니였습니다. 참고로 현재 한개의 db 서버에 4개의 웹서버가 연동하고 있습니다.php4 와 오라클9i의 디스커넥션이 지원되는 않는 문제는운영하시는 분이 계시면 테스트 바랍니다..저희의 테스트 결과는 disconnect() 함수에 의해서가 아닌 php프로세스 소멸과 함께 oracle의 커넥션이 끊기는것 같다는 것입니다.1. 저도 월요일 출근을 하게 되면 이 부분에 대한 테스트를 다시 해보도록 하겠습니다.2. 저번 올린 자료의 뒷받침 할 만한 자료(스트레스 테스트 자료)를 업로드 하도록 하겠습니다.</textarea><textarea style="DISPLAY: none" id="save_comment_36356">php4 + oracle8i(Enterprise with MTS) 으로 돌려봤었는데동시접속 100명이상 거뜬 합니다.(WebLog 1G/일 이상 사이트였습니다.) ^^; dedicate 로는 종종 DB가 죽는 상황이 있었는데 MTS로 돌린후에는 그런일이 없었지요. disconnect()도 잘 되었습니다.MTS쓰고 나서는 connection pooling을 굳이 찾을 필요가 없었습니다.</textarea><textarea style="DISPLAY: none" id="save_comment_36357">지나가다 우연히 글을 봤는데 서로 소모적인 논쟁을 하는 것 같네요.위에서 어떤 분이 언급하셨듯이 하나의 기술이 모든 상황에 절대적으로 적용되는 것은 아니라고 생각합니다. 만약 많은 사용자가 새로운 커넥션을 요청하는 일이 빈번하다면 커넥션 풀을 사용하고 사용자가 적다면 굳이 거추장스럽게 커넥션 풀 같은걸 사용할 필요는 없겠지요. 제가 보기엔 두 주장 다 일리가 있는데 서로 자신의 상황에 비추어서만 글들을 남기시는것 같습니다.커넥션 풀 기법이 무가치하지 않다는건 알고 계실테고, 만약 우리가 모든 일을 논하는데 있어 수치를 제시해야 한다면 의견 교환은 매우 더뎌질 수 밖에 없을 것입니다. 또한 CPU가 성능이 50% 개선되었는데 CPU만 갈면 시스템 성능이 50% 개선 되느냐 하면 그렇지 않고 실제 전체 성능 개선은 그보다 훨씬 못하다는 것은 다들 아실겁니다.저는 절대적인것은 없다라고 생각합니다. 모든 경우가 일반적이라면 왜 개발 툴은 이렇게 많으며 왜 DBMS는 이렇게 종류가 많을걸까요? 결국 그 상황에 맞게 선택하는게 중요한 것 같습니다.</textarea><textarea style="DISPLAY: none" id="save_comment_36358">MySQL은 의외로 제가 써본 경험에 의하면 커넥션 클로즈가 제대로 안돼어서 죽는경우가 많습니다. 설정에서 시간 설정에 짧게 잡아도 어는 마진이 필요하기때문에 완전히 끈는데는 시간이 걸리는데요..그사이 계속 커넥션 요청이 들어오면 DB 다운 _ _;; 이런 경우가 생깁니다. 그리고 oracle에서 MTS와 DEDICATE연결은 커넥션 풀하고는 거리가 먼 문제인거 같은데요..분석툴로 한번 보시면 왜 데디케이트에서 죽는지 알아내실수 있을듯 하네여.</textarea><textarea style="DISPLAY: none" id="save_comment_36359">망게님께 한표...이리저리 검색해봤는데전 nt기반에서 놀다보니 커넥션풀에 대해 무지했습니다.ms가 시키는대로만 했으니... ㅋㅋ찾아보니 ms는 이미 커넥션풀을 제공하더군요.그러나 오라클 경우는 프로그래머가 직접 작업해야 한다고 하네요. 이래나 저래나..다들 부하걸리게시리 db에 의존하고 계시나요? html생성도 좀 하시고 클라이언트단의 변수에 데이타도 좀 넣어놓고 그러세요.그럼 커넥션풀을 쓸 일 별로 없을껍니다.</textarea><textarea style="DISPLAY: none" id="save_comment_36360">참고로... 니가 뭘 아느냐 혹은 니글은 여기에 해당되는 글이 아니다 라면서 면서 태클 거실 분 있을텐데요..관련있습니다. 목적은 부하 안걸리고 잘 돌리는거니깐요.참고 : phpschool 이나 야후코리아보다 더 부하 많이 걸리는 곳에서 전 일하고 있습니다.</textarea>
쇼크렛 06-03-10 16:03<textarea style="DISPLAY: none" id="save_comment_45211">저는 C프로그래머입니다. 주로 소켓과 네트워크 프로그래밍을 해왔는데,그전에 통신사 프로젝트할때, 일반적으로 하나의 프로세스 또는 하나의 쓰레드에서접속을 열고 패킷을 주고 받고, 접속을 끊는 방식으로 하니까 로드러너 툴로 300TPS정도 나오더군요.한데, 아파치 서버 소스를 참조해서 커넥션풀 방식으로 바꾸니까 1000TPS 정도 나오더군요.아파치 서버는 한 1500TPS 나오더라구여. PHP만 짜시지 마시고, 아파치 서버의 C소스를 보세여.그럼 커넥션풀이 얼마나 좋은건지 아실겁니다. ㅋ</textarea>
컨넥션풀의 의도는 좋지만 효용성이... ;
1. 트랜잭션 등이 컨넥션 단위로 이뤄지므로, 이전 컨넥션을 디스컨넥 하지 않고 승계했을 때 발생하는 트랜잭션 관련 문제..
2. 컨넥션풀을 쓴다 해도, 최대 컨넥션을 다 채웠을 경우는 도움이 되지 않는다.
3. 컨넥션풀의 미들웨어(!)를 쓸 때 발생하는 속도저하문제...
4. 컨넥션풀은 컨넥션을 하는 작업 자체가 과도한 부하(시간 및 cpu 자원등)를 유발할 때 해결책이 될 수 있는데,
mysql 및 기타 대형DB 들도 컨넥션에 드는 부하는 그리 크지 않다... ;;
-- jeon.
1. 트랜잭션 등이 컨넥션 단위로 이뤄지므로, 이전 컨넥션을 디스컨넥 하지 않고 승계했을 때 발생하는 트랜잭션 관련 문제..
2. 컨넥션풀을 쓴다 해도, 최대 컨넥션을 다 채웠을 경우는 도움이 되지 않는다.
3. 컨넥션풀의 미들웨어(!)를 쓸 때 발생하는 속도저하문제...
4. 컨넥션풀은 컨넥션을 하는 작업 자체가 과도한 부하(시간 및 cpu 자원등)를 유발할 때 해결책이 될 수 있는데,
mysql 및 기타 대형DB 들도 컨넥션에 드는 부하는 그리 크지 않다... ;;
-- jeon.
/jeon
1. 트랜잭션은 커넥션 단위라기 보다는 디스커넥트 발생시 자동으로 comit 또는 rollback 등이 발생되는 개념이며, 명시적으로 또는 pool에서 이에 대한 commit / rollback을 지원한다.
2. 커넥션 풀의 용도는 가용성이 아니라, 커넥션 생성에 드는 비용을 줄이기 위함이다.
3. 속도저하 문제는 막연한 추측만으로 이룰 수 없다. 실제 프로파일러를 통해 산출물을 보면, 반영효과에 비해 상당히 미비하다.
4. 커넥션에 드는 비용은 생각보다 크다. 또한, 시스템의 부하는 차치하고서라도, 커넥션 자체에 딜레이 되는 타임은 시스템의 규모에 따라 상당한 장애로 발생한다.
1. 트랜잭션은 커넥션 단위라기 보다는 디스커넥트 발생시 자동으로 comit 또는 rollback 등이 발생되는 개념이며, 명시적으로 또는 pool에서 이에 대한 commit / rollback을 지원한다.
2. 커넥션 풀의 용도는 가용성이 아니라, 커넥션 생성에 드는 비용을 줄이기 위함이다.
3. 속도저하 문제는 막연한 추측만으로 이룰 수 없다. 실제 프로파일러를 통해 산출물을 보면, 반영효과에 비해 상당히 미비하다.
4. 커넥션에 드는 비용은 생각보다 크다. 또한, 시스템의 부하는 차치하고서라도, 커넥션 자체에 딜레이 되는 타임은 시스템의 규모에 따라 상당한 장애로 발생한다.
php에서 pool를 사용하여
대용량시스템을 구축해보신경험이 있는 분들이 계신가요??
왜 php에서는 널리쓰이질않는건지 궁금합니다..
위에 장단점만을 봤을때는
굳이 pool을 쓸필요가 있을까? 라는 생각이 드네요.
대용량시스템을 구축해보신경험이 있는 분들이 계신가요??
왜 php에서는 널리쓰이질않는건지 궁금합니다..
위에 장단점만을 봤을때는
굳이 pool을 쓸필요가 있을까? 라는 생각이 드네요.
헤즐넛님이 적으신 글에 비슷한 문서가 있군요. 뭐 그래도 이렇게 한번 더 글을 올리면서 또 생각해볼수 있으니 도움이 되겠죠. 관련된 참고자료를 마지막에 추가하였습니다. 근데 헤즐넛님 어디서 계속 아이디는 본듯한데. 아닌가?
오해를 님에게 ~
물론 님이 하신 말씀을 전혀 모르고 글을 올린 것은 아닙니다.. 제게 근거를 요구하셨듯이, 오해를님도 그에 대해 기술적인 근거를 제시할 수 있습니까.. ? 저처럼, 오해를 님도 나름대로의 경험과 지식에 근거할 뿐 아닐까요.
논쟁을 할 필요까진 없어 보이니까... 님의 생각을 바꾸려 노력하거나 제가 변명하려 노력할 필요는 없어 보이구요.
위 문제들 다 접어둔다 해도... 4 번 문제, 컨넥션에 드는 비용문제인데요.
웬만한 DBMS 라면 자체에서 쓰레드풀을 구성하고, 요청에 대해 이 쓰레드풀내에서 컨넥션을 갖지 않나 싶습니다.
쓰레드 생성 자체에 OS 마다 차이는 있지만 적지않은 부하가 있으니까요. 따라서, DB자체에서 쓰레드풀을 갖고 있는 만큼, 외부에서 별도의 쓰레드풀을 처리할 필요성은 없다고 보여집니다..
이 외에, DB 가 처리하는 내부 메모리구조 등과 관련한 컨넥션 초기화에 드는 부하가 있겠지만, 이정도도 역시 DBMS 내에 처리루틴이 어느정도 있다고 생각됩니다.
이건 고난이도의 \＇아이디어\＇가 아니라, 아주 평범한 아이디어라서요... ;;
또한 경험에 의해서도, 오라클이든 mysql이든, 다른 어떤 것이든 컨넥션 자체에 큰 부하를 느껴본 적은 없었습니다...;;
이에 대해 저도 mysql 소스코드를 들여다보거나, 오라클 에 기술적 문의를 해보거나 한 적은 전혀 없으므로, 그냥 개인적인 \＇추측\＇일 뿐입니다.
-- jeon.
물론 님이 하신 말씀을 전혀 모르고 글을 올린 것은 아닙니다.. 제게 근거를 요구하셨듯이, 오해를님도 그에 대해 기술적인 근거를 제시할 수 있습니까.. ? 저처럼, 오해를 님도 나름대로의 경험과 지식에 근거할 뿐 아닐까요.
논쟁을 할 필요까진 없어 보이니까... 님의 생각을 바꾸려 노력하거나 제가 변명하려 노력할 필요는 없어 보이구요.
위 문제들 다 접어둔다 해도... 4 번 문제, 컨넥션에 드는 비용문제인데요.
웬만한 DBMS 라면 자체에서 쓰레드풀을 구성하고, 요청에 대해 이 쓰레드풀내에서 컨넥션을 갖지 않나 싶습니다.
쓰레드 생성 자체에 OS 마다 차이는 있지만 적지않은 부하가 있으니까요. 따라서, DB자체에서 쓰레드풀을 갖고 있는 만큼, 외부에서 별도의 쓰레드풀을 처리할 필요성은 없다고 보여집니다..
이 외에, DB 가 처리하는 내부 메모리구조 등과 관련한 컨넥션 초기화에 드는 부하가 있겠지만, 이정도도 역시 DBMS 내에 처리루틴이 어느정도 있다고 생각됩니다.
이건 고난이도의 \＇아이디어\＇가 아니라, 아주 평범한 아이디어라서요... ;;
또한 경험에 의해서도, 오라클이든 mysql이든, 다른 어떤 것이든 컨넥션 자체에 큰 부하를 느껴본 적은 없었습니다...;;
이에 대해 저도 mysql 소스코드를 들여다보거나, 오라클 에 기술적 문의를 해보거나 한 적은 전혀 없으므로, 그냥 개인적인 \＇추측\＇일 뿐입니다.
-- jeon.
개씨박님
따라서 하고 싶은 말은 무엇인가요 ?
외부에서 따로 구현하는 컨넥션풀에 대해 필요하다고 생각하는 입장인가요 ? 정확히 구분이 안가네요...
아니면 그것과 관계없이 제 말에 대해 \＇평가\＇ 하는 중인가요 ?
가능하면 컨넥셕풀의 필요성에 대해 좀 분명한 말씀들을 해주시면 좋겠네요...
-- jeon.
따라서 하고 싶은 말은 무엇인가요 ?
외부에서 따로 구현하는 컨넥션풀에 대해 필요하다고 생각하는 입장인가요 ? 정확히 구분이 안가네요...
아니면 그것과 관계없이 제 말에 대해 \＇평가\＇ 하는 중인가요 ?
가능하면 컨넥셕풀의 필요성에 대해 좀 분명한 말씀들을 해주시면 좋겠네요...
-- jeon.
/jeon
기술논쟁에서 제일 까다로운 최소한의 예의를 가장한 오기성 글이군요. (예의가 중요한게 아니라 정작 중요한 기술적인 논리가 부족하다는 의미입니다.)
mysql은 몰라도 oracle 소스 들여다 보는 개발자들이 몇이나 있을까요? 소스를 들여다 봐야 모든 진리를 알 수 있다면, 대부분의 논쟁은 무의미 해질겁니다.
4번에 대해 아주 자세한 근거를 대라면, 글쎄요. 커넥션풀 구성 이전과 이후의 프로파일러 레포트를 제출해야 할까요? 그럴 필요까지는 없겠죠. 너무나도 당연한 결과이니까. (또한 이러한 BMT 레포트들은 각 풀 사이트에 가셔도 대부분 상세히 나와 있을겁니다. 이 부분에 대해서 또 다시 왈가불가 할 필요는 없을 듯 합니다. 퍼나르는 노동밖에 되지 않을테니까요.)
제가 지적한 것은 jeon님께서 추측성으로, 그러나 대부분 옳지않은 내용을 보고, 후배님들께서 \＇아 풀은 그다지 유용하지 않은거구나\＇ 또는 \＇트랜잭션등에서 문제가 생길 수 있으니 사용하면 안되겠구나, 오히려 부하가 더 걸릴수 도 있겠는걸.\＇ 하고 그릇된 판단을 할 수 있기에 지적해 드린 내용입니다.
프로젝트 종결 후, 완료보고계가 올라가고 여기에는 스트레스 테스트, 프로파일러 레포트, 무결성 점검, 유닛테스트 보고서등이 제출되고, 이 산출물들을 기반으로 감사를 진행하게 되지요.
제가 말하는 경험이란, 막연한 경험과 노하우를 말씀 드리는 것이 아니라, 실제 풀의 적용 이전과 이후에 따른 위의 절차를 거치면서 나온 결과이고, 전영규님의 경험이란 글쎄요, 단순한 느낌과 top등과 같은 간략한 시스템 트레이스 툴 정도를 이용한 추측 정도로 밖엔 보이지 않습니다. 이는 한번이라도 구체적인 레포트를 작성해 봤다면, 너무나도 숫자적으로 확연히 차이가 벌어지는 결과물이라 논쟁의 의미가 없어 보입니다.
또한 기술적인 근거라 할 수는 없겠지만, 데이터베이스 관련 부분은 해당 프로덕트의 로컬 매니저들에게 감사를 받고, 최종적인 튜닝에 대한 자문도 구하는 단계에서 축적된 경험(jeon님께서 언급하신 기술적 문의등은 너무나도 당연히 이루어지겠지만, 그래도 단순한 경험에 분류될 뿐입니다. 예를들어, 오라클 소속 엔지니어라 해도, 담당 엔지니어의 성향이나 자질의 문제에 따라 상이한 결과가 나오기 때문이죠.), 또는 직접 테스트 유닛을 만들면서, 프로파일링을 할 가치조차 못 느낄 형편없는 결과물을 나왔었던 이러한 \＇안\＇ 좋았던 개인적인 경험을 제시할 수 있겠군요. 아시다시피 사람들은 끔찍했던 원인에 대해선 보다 선명히 기억하니까요.
논쟁이라는 것이 막연한 추측만으론 정말 곤란합니다. 더군다나 이렇게 오픈된 자료들이 충만한 내용에 대해서도, 명확한 근거를 제시하라란 식의 말씀은 아무런 의미가 없어 보입니다.
마치 태권도가 왜 몸에 좋은가?에 대해 명확한 의미를 제시하라 한다면, 단순히 검색엔진에서 \＇태권도\＇ 라고 쳐 보거나, 태권도 협회 사이트에 들어가라고 밖엔 할말이 없겠죠. (커넥션풀에 대해서도 같은 답변을 드리고 싶습니다.)
기술논쟁에서 제일 까다로운 최소한의 예의를 가장한 오기성 글이군요. (예의가 중요한게 아니라 정작 중요한 기술적인 논리가 부족하다는 의미입니다.)
mysql은 몰라도 oracle 소스 들여다 보는 개발자들이 몇이나 있을까요? 소스를 들여다 봐야 모든 진리를 알 수 있다면, 대부분의 논쟁은 무의미 해질겁니다.
4번에 대해 아주 자세한 근거를 대라면, 글쎄요. 커넥션풀 구성 이전과 이후의 프로파일러 레포트를 제출해야 할까요? 그럴 필요까지는 없겠죠. 너무나도 당연한 결과이니까. (또한 이러한 BMT 레포트들은 각 풀 사이트에 가셔도 대부분 상세히 나와 있을겁니다. 이 부분에 대해서 또 다시 왈가불가 할 필요는 없을 듯 합니다. 퍼나르는 노동밖에 되지 않을테니까요.)
제가 지적한 것은 jeon님께서 추측성으로, 그러나 대부분 옳지않은 내용을 보고, 후배님들께서 \＇아 풀은 그다지 유용하지 않은거구나\＇ 또는 \＇트랜잭션등에서 문제가 생길 수 있으니 사용하면 안되겠구나, 오히려 부하가 더 걸릴수 도 있겠는걸.\＇ 하고 그릇된 판단을 할 수 있기에 지적해 드린 내용입니다.
프로젝트 종결 후, 완료보고계가 올라가고 여기에는 스트레스 테스트, 프로파일러 레포트, 무결성 점검, 유닛테스트 보고서등이 제출되고, 이 산출물들을 기반으로 감사를 진행하게 되지요.
제가 말하는 경험이란, 막연한 경험과 노하우를 말씀 드리는 것이 아니라, 실제 풀의 적용 이전과 이후에 따른 위의 절차를 거치면서 나온 결과이고, 전영규님의 경험이란 글쎄요, 단순한 느낌과 top등과 같은 간략한 시스템 트레이스 툴 정도를 이용한 추측 정도로 밖엔 보이지 않습니다. 이는 한번이라도 구체적인 레포트를 작성해 봤다면, 너무나도 숫자적으로 확연히 차이가 벌어지는 결과물이라 논쟁의 의미가 없어 보입니다.
또한 기술적인 근거라 할 수는 없겠지만, 데이터베이스 관련 부분은 해당 프로덕트의 로컬 매니저들에게 감사를 받고, 최종적인 튜닝에 대한 자문도 구하는 단계에서 축적된 경험(jeon님께서 언급하신 기술적 문의등은 너무나도 당연히 이루어지겠지만, 그래도 단순한 경험에 분류될 뿐입니다. 예를들어, 오라클 소속 엔지니어라 해도, 담당 엔지니어의 성향이나 자질의 문제에 따라 상이한 결과가 나오기 때문이죠.), 또는 직접 테스트 유닛을 만들면서, 프로파일링을 할 가치조차 못 느낄 형편없는 결과물을 나왔었던 이러한 \＇안\＇ 좋았던 개인적인 경험을 제시할 수 있겠군요. 아시다시피 사람들은 끔찍했던 원인에 대해선 보다 선명히 기억하니까요.
논쟁이라는 것이 막연한 추측만으론 정말 곤란합니다. 더군다나 이렇게 오픈된 자료들이 충만한 내용에 대해서도, 명확한 근거를 제시하라란 식의 말씀은 아무런 의미가 없어 보입니다.
마치 태권도가 왜 몸에 좋은가?에 대해 명확한 의미를 제시하라 한다면, 단순히 검색엔진에서 \＇태권도\＇ 라고 쳐 보거나, 태권도 협회 사이트에 들어가라고 밖엔 할말이 없겠죠. (커넥션풀에 대해서도 같은 답변을 드리고 싶습니다.)
오해를 / 적당한 설명이라고 봅니다.
---
커넥션풀에서 커넥션이 이루어 지고 끊어지는 부분에 대한 소비를 mysql 문서에 보면 일반적인 쿼리 보다 몇배가 더 소비된다고 나와있습니다. 대부분의 DB들이 실제 쿼리에 대한 처리량에 고심하고 있다는것을 본다면 커넥션부분에 대한 의존도를 다른 프로그램에서 처리해준다면 더할나위 없이 기쁘겠죠.. 게다가 풀을 만들면 다용도로 쓸수 있습니다. 여러 DB 서버를 활용할수 있고, 커넥션 이벤트 또는 디스 커넥션 이벤트에 따른 임의 사용자 프로그램 개발도 용이 하고.. 기타 등등..
단순히 DB, 여기서 mysql에서의 쓰레드 방식과 커넥션풀을 비교 하는거 자체가 무리라고 보여집니다. 전님이 말씀 하신 형태라면 몇천만원이나 들이면서 미들웨어를 구입하는 사람들이 골빈 사람들이 되어 버리는 꼴이 될꺼 같다고 보여집니다..
특히나 4번 사항에 대한 설명은 적절치 않습니다.. DB 활용에 따라 다른, 즉. 쿼리를 길게 잡고있는 놈들고 있고, 단타로 절라 많이 요청하는 것들도 있는데.. 그렇게 무턱대고 \"별로 없더라\" 식의 내용은 좀 이해가 안가네요... 정말 많은 수의 짧은 요청을 감당하는 경우도 있다는걸 염두에 두셔야 할것 같습니다.
좀더 자세한 사항을 알고 싶으면 미들웨어 프로그램의 feature 부분을 보시는것도 좋겠네요..
---
커넥션풀에서 커넥션이 이루어 지고 끊어지는 부분에 대한 소비를 mysql 문서에 보면 일반적인 쿼리 보다 몇배가 더 소비된다고 나와있습니다. 대부분의 DB들이 실제 쿼리에 대한 처리량에 고심하고 있다는것을 본다면 커넥션부분에 대한 의존도를 다른 프로그램에서 처리해준다면 더할나위 없이 기쁘겠죠.. 게다가 풀을 만들면 다용도로 쓸수 있습니다. 여러 DB 서버를 활용할수 있고, 커넥션 이벤트 또는 디스 커넥션 이벤트에 따른 임의 사용자 프로그램 개발도 용이 하고.. 기타 등등..
단순히 DB, 여기서 mysql에서의 쓰레드 방식과 커넥션풀을 비교 하는거 자체가 무리라고 보여집니다. 전님이 말씀 하신 형태라면 몇천만원이나 들이면서 미들웨어를 구입하는 사람들이 골빈 사람들이 되어 버리는 꼴이 될꺼 같다고 보여집니다..
특히나 4번 사항에 대한 설명은 적절치 않습니다.. DB 활용에 따라 다른, 즉. 쿼리를 길게 잡고있는 놈들고 있고, 단타로 절라 많이 요청하는 것들도 있는데.. 그렇게 무턱대고 \"별로 없더라\" 식의 내용은 좀 이해가 안가네요... 정말 많은 수의 짧은 요청을 감당하는 경우도 있다는걸 염두에 두셔야 할것 같습니다.
좀더 자세한 사항을 알고 싶으면 미들웨어 프로그램의 feature 부분을 보시는것도 좋겠네요..
아 추가로 개인적으로는
일반적인 사용에서는 개인이 커넥션풀까지 쓸 일은 거의 없다라고 느낍니다.. 이 상황에서는 전님의 의견과 비슷한 부분이 되겠죠.... 물론 대형DB에서는 틀리구요..
일반적인 사용에서는 개인이 커넥션풀까지 쓸 일은 거의 없다라고 느낍니다.. 이 상황에서는 전님의 의견과 비슷한 부분이 되겠죠.... 물론 대형DB에서는 틀리구요..
전영규님께 대규모 프로젝트를 해보았는지 여쭤보고 싶습니다.
몇번의 컨넥션만 이루어지는 단순한 작업은 컨넥션 풀을
쓸필요는 없지만 대규모 프로젝트에서는 상당히 많은
컨넥션이 요청될 경우 수많은 컨넥션이 동시에 생기면서
데이터베이스가 죽는 상황도 생깁니다.
그렇기 때문에 컨넥션 풀을 사용하는거지요.
그리고 컨넥션 풀에 대해서 몇가지 잘못 알고 계신 것 같은데요.
오해를 님이 적절하게 잘 설명해주신 것 같아서
따로 드릴 말씀은 없네요. 컨넥션 풀은 이미 많은 곳에
적용되어 있고 상용 WAS 에서도 지원하고 있습니다.
그 효능은 이미 입증되었다고 봐도 괜찮을 것 같습니다.
몇번의 컨넥션만 이루어지는 단순한 작업은 컨넥션 풀을
쓸필요는 없지만 대규모 프로젝트에서는 상당히 많은
컨넥션이 요청될 경우 수많은 컨넥션이 동시에 생기면서
데이터베이스가 죽는 상황도 생깁니다.
그렇기 때문에 컨넥션 풀을 사용하는거지요.
그리고 컨넥션 풀에 대해서 몇가지 잘못 알고 계신 것 같은데요.
오해를 님이 적절하게 잘 설명해주신 것 같아서
따로 드릴 말씀은 없네요. 컨넥션 풀은 이미 많은 곳에
적용되어 있고 상용 WAS 에서도 지원하고 있습니다.
그 효능은 이미 입증되었다고 봐도 괜찮을 것 같습니다.
위에 제게 반박글 써주신 분들께 감사드립니다.
윗분들 말대로 커넥션풀이란 미들웨어를 씀으로서 얻는 컨넥션 부하 단축의 효과가 있을 거란 것은 전혀 무시하는 바가 아닙니다.
그러나, 과연 그 효과가 어느정도인지 구체적으로 아시는 분 계십니까 ?
뭐, 10% 향상이라던가 400% 향상이라던가.
그리고, 이게 벤더의 말이 아니라, 실제로 테스트를 진행하여 얻은 결과인지도 알고 싶군요.
제가 제 경험과 추측으로 글을 쓰는 것은 순전히 \＇제 의견\＇ 일 수 있습니다. 그러나 여러분들이 쓰는 글은 \＇벤더\＇와 \＇일반적인 선배들의 지침\＇에 의존하는 것은 아닌지 더욱 궁금해집니다.
오기를 부리는 것이라고 생각되시나요 ?
전혀 그렇지 않습니다.
저는 오히려 궁금한 것이 있는데, 확실한 답을 구할 수 없기 때분에 답답합니다. 확실한 답이 구해지면, 저도 제가 잘못 알고 있다는 것을 당당히 인정할 수 있고, 이 코멘트들을 읽게 될 다른 후배들(?)에게도 좋은 간접경험과 지식이 될 것입니다.
그러나, 확실한 답을 구할 수 없다면,
여전히 저는 제 생각을 멈출 수 없을테고, 여러분은 또 여러분대로 답답한 마음으로 저를 바라볼 겁니다.
계속해서 \＇답답하다\＇고 토로하는 것은 의미가 없습니다.
구체적인 수치를 제시할 수 있습니까 ?
그렇지 않다면 본 토론은 진전이 없습니다.
위에 글들을 자세히 읽어 보세요. 제가 했던 말이나 여러분이 했던 말이나 계속 반복되고 확장 될 뿐, 다른 안건이 제시되지 않고 있습니다.
-- jeon.
윗분들 말대로 커넥션풀이란 미들웨어를 씀으로서 얻는 컨넥션 부하 단축의 효과가 있을 거란 것은 전혀 무시하는 바가 아닙니다.
그러나, 과연 그 효과가 어느정도인지 구체적으로 아시는 분 계십니까 ?
뭐, 10% 향상이라던가 400% 향상이라던가.
그리고, 이게 벤더의 말이 아니라, 실제로 테스트를 진행하여 얻은 결과인지도 알고 싶군요.
제가 제 경험과 추측으로 글을 쓰는 것은 순전히 \＇제 의견\＇ 일 수 있습니다. 그러나 여러분들이 쓰는 글은 \＇벤더\＇와 \＇일반적인 선배들의 지침\＇에 의존하는 것은 아닌지 더욱 궁금해집니다.
오기를 부리는 것이라고 생각되시나요 ?
전혀 그렇지 않습니다.
저는 오히려 궁금한 것이 있는데, 확실한 답을 구할 수 없기 때분에 답답합니다. 확실한 답이 구해지면, 저도 제가 잘못 알고 있다는 것을 당당히 인정할 수 있고, 이 코멘트들을 읽게 될 다른 후배들(?)에게도 좋은 간접경험과 지식이 될 것입니다.
그러나, 확실한 답을 구할 수 없다면,
여전히 저는 제 생각을 멈출 수 없을테고, 여러분은 또 여러분대로 답답한 마음으로 저를 바라볼 겁니다.
계속해서 \＇답답하다\＇고 토로하는 것은 의미가 없습니다.
구체적인 수치를 제시할 수 있습니까 ?
그렇지 않다면 본 토론은 진전이 없습니다.
위에 글들을 자세히 읽어 보세요. 제가 했던 말이나 여러분이 했던 말이나 계속 반복되고 확장 될 뿐, 다른 안건이 제시되지 않고 있습니다.
-- jeon.
까다로운 분이시네요.
말씀하시는대로 하자면 두개의 알고리즘이 있는데
그 중 하나의 알고리즘이 성능이 다른 하나보다 떨어질 경우
성능이 좋은 알고리즘이 과연 안좋은 알고리즘의 정확히
몇배의 효율을 가지고 있는지 아주 정확히 따지고 씁니까?
그리고 풀링의 장점들은 이미 위에서도 설명되었고 더 정확한
자료는 검색해보면 많이 나옵니다. 더욱더 정확한 답을
원하신다면 더 드릴 말씀은 없습니다. 언젠가 본인이
직접 경험해보면 알게될겁니다. :)
말씀하시는대로 하자면 두개의 알고리즘이 있는데
그 중 하나의 알고리즘이 성능이 다른 하나보다 떨어질 경우
성능이 좋은 알고리즘이 과연 안좋은 알고리즘의 정확히
몇배의 효율을 가지고 있는지 아주 정확히 따지고 씁니까?
그리고 풀링의 장점들은 이미 위에서도 설명되었고 더 정확한
자료는 검색해보면 많이 나옵니다. 더욱더 정확한 답을
원하신다면 더 드릴 말씀은 없습니다. 언젠가 본인이
직접 경험해보면 알게될겁니다. :)
풀의 개념은 성능 향샹이라는 목적도 있지만, 가용 자원을 제한할려는 목적도 있습니다.
mysql 이 과부하로 사이트 자체가 죽어버리는 것보다 , 어느정도 사용자가 증가하면(connection 개수가 증가하면) 특정 컨텐츠나 서비스에 더이상 사용자가 접근하지 않도록 할수도 있는거죠.
동일 mysql를 쓰는 사이트에서, A 서비스가 max 10개의 컨넥션을 쓰고, B서비스가 max 10개의 컨넥션, C에서 max 10개의 컨넥션을 쓴다고 했을때, A서비스에 10개 이상의 접속요청이 들어오더라도 B,C에서는 정상적으로 서비스가 되죠. A에서 컨넥션을 다 소비해버려서 A,B,C 서비스 모두가 중단되는 경우는 안생기는거죠. 게시판의 경우 mysql로 쓰는경우가 많은데, 사용자 접속이 특히 많은 게시판만 따로 pool을 구성해서 쓰다면, 게시판 접속이 폭주해서 사이트가 마비되는 경우를 막을수 있겠죠.
php에서 connection 풀을 제대로 사용할수 있다면, 쓰는게 훨씬 좋습니다.
그런데,, php가 apache의 fork 기반(아파치2.0은 제외) 프로세스를 쓴다면 컨넥션 풀을 사용하기 위해서 socket나 pipe 로 연결을 해야 할텐데..여기에 과부하가 걸리면 어떻게 되는건지? 쉐어드 메모리를 통해서 서비스 되는것인지.
그리고, 풀 자체가 c로 작성된 데몬 같은데, 풀이 오류로 죽어버리면 어떻게 되죠? 그만큼 안정성에 문제가 없어야 할것 같은데.. 프로세스 기반으로 작동되는 apache에서 pool 이라는 개념이 잘 안 맞는것 같네요.
mysql 이 과부하로 사이트 자체가 죽어버리는 것보다 , 어느정도 사용자가 증가하면(connection 개수가 증가하면) 특정 컨텐츠나 서비스에 더이상 사용자가 접근하지 않도록 할수도 있는거죠.
동일 mysql를 쓰는 사이트에서, A 서비스가 max 10개의 컨넥션을 쓰고, B서비스가 max 10개의 컨넥션, C에서 max 10개의 컨넥션을 쓴다고 했을때, A서비스에 10개 이상의 접속요청이 들어오더라도 B,C에서는 정상적으로 서비스가 되죠. A에서 컨넥션을 다 소비해버려서 A,B,C 서비스 모두가 중단되는 경우는 안생기는거죠. 게시판의 경우 mysql로 쓰는경우가 많은데, 사용자 접속이 특히 많은 게시판만 따로 pool을 구성해서 쓰다면, 게시판 접속이 폭주해서 사이트가 마비되는 경우를 막을수 있겠죠.
php에서 connection 풀을 제대로 사용할수 있다면, 쓰는게 훨씬 좋습니다.
그런데,, php가 apache의 fork 기반(아파치2.0은 제외) 프로세스를 쓴다면 컨넥션 풀을 사용하기 위해서 socket나 pipe 로 연결을 해야 할텐데..여기에 과부하가 걸리면 어떻게 되는건지? 쉐어드 메모리를 통해서 서비스 되는것인지.
그리고, 풀 자체가 c로 작성된 데몬 같은데, 풀이 오류로 죽어버리면 어떻게 되죠? 그만큼 안정성에 문제가 없어야 할것 같은데.. 프로세스 기반으로 작동되는 apache에서 pool 이라는 개념이 잘 안 맞는것 같네요.
명랑폐인님 말씀이 맞아 보이는군요. 저희가 토론해야 될것은
전영규님처럼 정확히 어느정도 효율이 있는지를 따지기 보다는
과연 프로세스 기반에서의 풀이 과연 효율적인지를 따져보는
것이 옳은게 아닐까요?
전영규님처럼 정확히 어느정도 효율이 있는지를 따지기 보다는
과연 프로세스 기반에서의 풀이 과연 효율적인지를 따져보는
것이 옳은게 아닐까요?
우와님께
제가 좀 까다로운 면이 있습니다. 개발자라면, 까다로울 때 까다로워야 하는 거 아닌가 싶군요.
그 알고리즘이 효율적이지 않다는 것은 위에 제가 처음 코멘트 단 것에 이미 밝혔고, 그 이후에도 계속 같은 입장입니다.
그렇기 때문에, 수치 데이타가 없다면 별로 라는 입장이구요.
명량폐인님 말씀엔 당연히 동의합니다.
새로운 관점에서 컨넥션풀을 바라보는 방법을 주셨네요.
맞습니다. db 서버는 1 개 이고, 이에 접속하는 아파치나 어플이 다수일 때 컨넥션풀은 각각의 접속서버에서 제한을 주는 용도로 사용될 수 있을 것입니다.
여러 경우의 수가 있겠지만, 전반적으로 이 아이디어는 유용하다고 보여집니다.
그러나, 명량폐인님 역시 그 이후 말씀에서 컨넥션풀 자체의 유용성에 대해서는 다시 적절한 수용이 필요하다는 언급을 하셨군요.
비온뒤 님께. 제 생각엔 필요없다 입니다.
-- jeon.
제가 좀 까다로운 면이 있습니다. 개발자라면, 까다로울 때 까다로워야 하는 거 아닌가 싶군요.
그 알고리즘이 효율적이지 않다는 것은 위에 제가 처음 코멘트 단 것에 이미 밝혔고, 그 이후에도 계속 같은 입장입니다.
그렇기 때문에, 수치 데이타가 없다면 별로 라는 입장이구요.
명량폐인님 말씀엔 당연히 동의합니다.
새로운 관점에서 컨넥션풀을 바라보는 방법을 주셨네요.
맞습니다. db 서버는 1 개 이고, 이에 접속하는 아파치나 어플이 다수일 때 컨넥션풀은 각각의 접속서버에서 제한을 주는 용도로 사용될 수 있을 것입니다.
여러 경우의 수가 있겠지만, 전반적으로 이 아이디어는 유용하다고 보여집니다.
그러나, 명량폐인님 역시 그 이후 말씀에서 컨넥션풀 자체의 유용성에 대해서는 다시 적절한 수용이 필요하다는 언급을 하셨군요.
비온뒤 님께. 제 생각엔 필요없다 입니다.
-- jeon.
명량폐인님께...
이건 다소 본 토론과 별 관계가 없는 거라서.. 언급을 피하고 싶은 부분이긴 한데요.
php가 apache의 fork 기반(아파치2.0은 제외) 프로세스를 쓴다면 컨넥션 풀을 사용하기 위해서 socket나 pipe 로 연결을 해야 할텐데..여기에 과부하가 걸리면 어떻게 되는건지?
--> 쓰레드 기반이라도 socket나 pipe 로 연결을 해야겠지요. ipc 프로토콜로 알려져 있다면, 쓰레드도 부모 프로세스기반이므로, ipc 프로토콜을 벗어날 수가 없으니까요..
따라서, 프로세스기반이기 때문에 컨넥션풀이 안좋다.. 라는 건 적절한 결론이 아닙니다.. ;;
이후 와우 님께도 마찬가지 말씀을 드리고 싶군요.
그보다는, 컨넥션 풀 자체의 안정성이나 부하문제, 컨넥션타임을 과연 얼마나 줄여줄 것인가에 대한 수치데이타 문제 등이 여전히 중요변수 아닐까요...
-- jeon.
이건 다소 본 토론과 별 관계가 없는 거라서.. 언급을 피하고 싶은 부분이긴 한데요.
php가 apache의 fork 기반(아파치2.0은 제외) 프로세스를 쓴다면 컨넥션 풀을 사용하기 위해서 socket나 pipe 로 연결을 해야 할텐데..여기에 과부하가 걸리면 어떻게 되는건지?
--> 쓰레드 기반이라도 socket나 pipe 로 연결을 해야겠지요. ipc 프로토콜로 알려져 있다면, 쓰레드도 부모 프로세스기반이므로, ipc 프로토콜을 벗어날 수가 없으니까요..
따라서, 프로세스기반이기 때문에 컨넥션풀이 안좋다.. 라는 건 적절한 결론이 아닙니다.. ;;
이후 와우 님께도 마찬가지 말씀을 드리고 싶군요.
그보다는, 컨넥션 풀 자체의 안정성이나 부하문제, 컨넥션타임을 과연 얼마나 줄여줄 것인가에 대한 수치데이타 문제 등이 여전히 중요변수 아닐까요...
-- jeon.
혹시 도움이 될까 몇자 적어 봅니다.
저희는 php 에 oracle9i를 이용하고 있습니다.
현재는 php DB pooling 중 sqlrelay를 이용하고 있습니다.
테스트 머신 : X86 Linux (Redhat)
DB : oracle 9i
LANG : php
이용 목적:
1. php 에서 oracle9i의 disconnect 가 제대로 안되는 문제와
2. 사용자가 몰렸을 경우 위의 문제로 db connect 을 많이 물게되어 db 서버의 리소스를 많이 잡는 문제
장점과 테스트시 향상율
1. db 서버의 부하감소 20%
2. 속도향상(ab를 이용 테스트 10~20% 향상됨)
3. 웹서버의 메모리 사용량 감소..
(이부분은 기존의 oracle 펑션을 이용하지 않고 sqlrelay의 펑션를 이용하면서 아마도 오라클 클라이언트 모듈이 로딩되지 않아서 일까 추측 됩니다. 예전에는 httpd 데몬 하나가 50M 이상 잡아먹던게 5~6M가로 줄었습니다.)
덕분에.. 웹서버의 메모리 사용량도 줄이게 됐습니다.
단점
1. 단점이라면 아직 오라클(오라클만 테스트해봤음^^)을 제대로 지원하지 못하는 문제
단점보다는 우리쪽에 장점이 많아 올 8월 부터 지금까지 쭈욱 이용하고 있습니다.
저희는 php 에 oracle9i를 이용하고 있습니다.
현재는 php DB pooling 중 sqlrelay를 이용하고 있습니다.
테스트 머신 : X86 Linux (Redhat)
DB : oracle 9i
LANG : php
이용 목적:
1. php 에서 oracle9i의 disconnect 가 제대로 안되는 문제와
2. 사용자가 몰렸을 경우 위의 문제로 db connect 을 많이 물게되어 db 서버의 리소스를 많이 잡는 문제
장점과 테스트시 향상율
1. db 서버의 부하감소 20%
2. 속도향상(ab를 이용 테스트 10~20% 향상됨)
3. 웹서버의 메모리 사용량 감소..
(이부분은 기존의 oracle 펑션을 이용하지 않고 sqlrelay의 펑션를 이용하면서 아마도 오라클 클라이언트 모듈이 로딩되지 않아서 일까 추측 됩니다. 예전에는 httpd 데몬 하나가 50M 이상 잡아먹던게 5~6M가로 줄었습니다.)
덕분에.. 웹서버의 메모리 사용량도 줄이게 됐습니다.
단점
1. 단점이라면 아직 오라클(오라클만 테스트해봤음^^)을 제대로 지원하지 못하는 문제
단점보다는 우리쪽에 장점이 많아 올 8월 부터 지금까지 쭈욱 이용하고 있습니다.
하늘너굴님 좋은 자료 감사드립니다.
크게 보아 20% 정도 향상이 있다고 보여지네요.
그리고 조언드리자면..
disconnect 가 잘 안되는 현상은 php 나 오라클쪽 설정문제를 좀 더 보시면 해결되지 않을까 싶네요. 저는 그런 현상을 거의 보지 못했었는데... 아마 특수상황이 아닐까 싶습니다.
3.번 사항은 .. 정말 그렇다면 큰 수확이군요.
그런데 역시 일반상황은 아닐 거 같다는 생각이 드네요.. ;;
httpd 데몬 하나가 50M 이상 잡아먹는 상황이 해소된 상태라면.. 아마 성능향상도 이 메모리해소에 맞물려 이룩된 성과일 지 모릅니다.
따라서, sqlrelay 를 쓰지 않고서 php-oracle 간 조율을 해주면 현재 이룩한 성과와 같은 성과를 얻을 수도 있겠다는 생각이 듭니다.
물론, 현재 잘 쓰고 있다면 굳이 그런 실험을 하실 필요는 없겠지만요.... ;;
-- jeon.
크게 보아 20% 정도 향상이 있다고 보여지네요.
그리고 조언드리자면..
disconnect 가 잘 안되는 현상은 php 나 오라클쪽 설정문제를 좀 더 보시면 해결되지 않을까 싶네요. 저는 그런 현상을 거의 보지 못했었는데... 아마 특수상황이 아닐까 싶습니다.
3.번 사항은 .. 정말 그렇다면 큰 수확이군요.
그런데 역시 일반상황은 아닐 거 같다는 생각이 드네요.. ;;
httpd 데몬 하나가 50M 이상 잡아먹는 상황이 해소된 상태라면.. 아마 성능향상도 이 메모리해소에 맞물려 이룩된 성과일 지 모릅니다.
따라서, sqlrelay 를 쓰지 않고서 php-oracle 간 조율을 해주면 현재 이룩한 성과와 같은 성과를 얻을 수도 있겠다는 생각이 듭니다.
물론, 현재 잘 쓰고 있다면 굳이 그런 실험을 하실 필요는 없겠지만요.... ;;
-- jeon.
전영규//쓰레드 기반이라도 socket이나 pipe로 연결하는게 맞습니다. 제가 예를 잘못 들었네요.. 웹서버가(apache나 tomcat같은) 직접 pool을 관리하는 형태가 아니라면, socket이나 pipe로 연결하는 것입니다.
자바의 경우 어플리케이션 내부적으로 pool을 관리함으로, 코드에서 메소드만 호출하면 pool을 사용할수 있습니다.
그러니까 apache 서버에서 직접 pool을 관리하는 형태가 아니라면, php가 풀 demon 에게 socket 이나 pipe로 연결하여 쓰는 형태라면, 그에 따른 부하처리는 어떻게 할수 있느냐 하는것입니다. php프로세스가 증가하고, 데몬에 접속하는 socket이나 pipe도 늘어날텐데.. 이것도 성능에 영향을 끼칠수 있다는 것입니다.
자바의 경우 어플리케이션 내부적으로 pool을 관리함으로, 코드에서 메소드만 호출하면 pool을 사용할수 있습니다.
그러니까 apache 서버에서 직접 pool을 관리하는 형태가 아니라면, php가 풀 demon 에게 socket 이나 pipe로 연결하여 쓰는 형태라면, 그에 따른 부하처리는 어떻게 할수 있느냐 하는것입니다. php프로세스가 증가하고, 데몬에 접속하는 socket이나 pipe도 늘어날텐데.. 이것도 성능에 영향을 끼칠수 있다는 것입니다.
물론이지요.
단지 명량폐인님 말씀처럼 쓰레드라고 해서 ipc 를 소켓이나 파이프 아닌 다른 것으로 하는 것은 아닌데, 그에 대한 것만 지적해 드린 것이구요
말씀처럼, 컨넥션풀은 기본적인 부하가 있습니다.
그에 대한 것을 앞에 계속 말씀드렸던 것이구요...
제가 쓴 첫 글에서 3 번 항목과 유사한 사항이네요..
3. 컨넥션풀의 미들웨어(!)를 쓸 때 발생하는 속도저하문제...
-- jeon.
단지 명량폐인님 말씀처럼 쓰레드라고 해서 ipc 를 소켓이나 파이프 아닌 다른 것으로 하는 것은 아닌데, 그에 대한 것만 지적해 드린 것이구요
말씀처럼, 컨넥션풀은 기본적인 부하가 있습니다.
그에 대한 것을 앞에 계속 말씀드렸던 것이구요...
제가 쓴 첫 글에서 3 번 항목과 유사한 사항이네요..
3. 컨넥션풀의 미들웨어(!)를 쓸 때 발생하는 속도저하문제...
-- jeon.
php, mysql 관련된 사이트에서 커넥션 풀링과 관련된 자료를 찾아보아도 그다지 자료가 나오는게 없군요. 위에 토론을 보다보니 궁금해지기는 해서요.
저야 자세한 내용까지는 모르겠지만 전영규님 말대로 정확한 근거와 수치를 제시하는것은 필요하다는 생각이 들어요. 저도 잘 못하는 것이기는 하지만 이렇게 이렇게 하는것이 더 좋지 않겠냐는 말은 막연한 것이 있지요. (그래도 아무런 말을 하지 않는것도바는 막연하게라도 표현하는게 더 낫긴한데...)
전영규님이 다른 분들한테 계속 억지주장을 하는게 아니라 사람들이 커넥션 풀이 유용하다고 하는데 그에 대한 실증적인 내용과 분명한 근거를 알고 싶다는 의견같네요. 맞나요?
좀 다른 이야기지만 이런 것도 있지요. 예를 들어 http 1.1 에서는 keepalive를 지원하며 웹서버에 접속한 경우 일정한 시간동안 연결을 유지시켜줍니다. 그런데 사이트에 접속자가 많으면 오히려 유휴프로세서를 많이 생기게하여 문제를 발생시키는 경우가 생깁니다. keepalive를 off로 하면 시스템상에서 프로세서를 더 자주 생성시키고 소멸시키기때문에 시스템의 부하는 전체적으로 높여지지만 오히려 웹성능자체는 향상될수가 있습니다. 지속적인 연결을 하는 것과 tiemout 값이 접속자가 많은 경우 상당히 많은 영향을 미치지요.
DB에서 새로 DB프로세서를 생성하는것이 쿼리를 실행하는 것에 비하면 더 부하를 주는 것이지만 이것이 정말 심각할 정도로 영향을 주는 문제인가 이런 궁금함이 생기네요.
커넥션 풀이 나름대로의 장점을 가지고 있다고 하더라도 정말 이것이 커넥션풀을 쓰지 않는 것에 비하여 엄청나게 많은 장점을 가지고 있는것인지 이런 의문은 충분히 가질수 있다는 생각이 듭니다.
좀더 나아가면 어떤 경우에 커넥션풀을 쓰는게 더 적합한지 이런 것을 생각할 수 있을듯. 여러가지 경우에 따라 적합한 것이 다를 수 있으니깐요.
하늘너굴님이 올린 자료는 좀더 실증적인 자료인데 예를 들어 벤치마킹을 한다면 동시사용자를 올리면서 동시접속처리수와 반응시간에 대한 내용을 함께 알 수 있다면 좀더 도움이 되겠지요. 동시접속자수에 따라 벤치마크 결과가 전혀 다르게 나올수 있기 때문이이죠.
SQL Relay도 제공하는 기능이 속도도 있지만 확장성, 여러 디비에 분산 엑세스, 지원되지 않는 플랫폿에서의 db접근등이 있네요.
시간여유가 있으면 좀더 자료를 뒤져보고 찾아보고싶지만 지금은 시간이 안되어.
음. 쓰고나니 좀 두리뭉실한 글이 되어버렸네요.
아 그리고 요즘엔 여기 글을 쓰지 않기는 하지만 예전에 가끔 글을 올린적이 있었지요. 오래되어서 기억이 잘 안나지만.
저야 자세한 내용까지는 모르겠지만 전영규님 말대로 정확한 근거와 수치를 제시하는것은 필요하다는 생각이 들어요. 저도 잘 못하는 것이기는 하지만 이렇게 이렇게 하는것이 더 좋지 않겠냐는 말은 막연한 것이 있지요. (그래도 아무런 말을 하지 않는것도바는 막연하게라도 표현하는게 더 낫긴한데...)
전영규님이 다른 분들한테 계속 억지주장을 하는게 아니라 사람들이 커넥션 풀이 유용하다고 하는데 그에 대한 실증적인 내용과 분명한 근거를 알고 싶다는 의견같네요. 맞나요?
좀 다른 이야기지만 이런 것도 있지요. 예를 들어 http 1.1 에서는 keepalive를 지원하며 웹서버에 접속한 경우 일정한 시간동안 연결을 유지시켜줍니다. 그런데 사이트에 접속자가 많으면 오히려 유휴프로세서를 많이 생기게하여 문제를 발생시키는 경우가 생깁니다. keepalive를 off로 하면 시스템상에서 프로세서를 더 자주 생성시키고 소멸시키기때문에 시스템의 부하는 전체적으로 높여지지만 오히려 웹성능자체는 향상될수가 있습니다. 지속적인 연결을 하는 것과 tiemout 값이 접속자가 많은 경우 상당히 많은 영향을 미치지요.
DB에서 새로 DB프로세서를 생성하는것이 쿼리를 실행하는 것에 비하면 더 부하를 주는 것이지만 이것이 정말 심각할 정도로 영향을 주는 문제인가 이런 궁금함이 생기네요.
커넥션 풀이 나름대로의 장점을 가지고 있다고 하더라도 정말 이것이 커넥션풀을 쓰지 않는 것에 비하여 엄청나게 많은 장점을 가지고 있는것인지 이런 의문은 충분히 가질수 있다는 생각이 듭니다.
좀더 나아가면 어떤 경우에 커넥션풀을 쓰는게 더 적합한지 이런 것을 생각할 수 있을듯. 여러가지 경우에 따라 적합한 것이 다를 수 있으니깐요.
하늘너굴님이 올린 자료는 좀더 실증적인 자료인데 예를 들어 벤치마킹을 한다면 동시사용자를 올리면서 동시접속처리수와 반응시간에 대한 내용을 함께 알 수 있다면 좀더 도움이 되겠지요. 동시접속자수에 따라 벤치마크 결과가 전혀 다르게 나올수 있기 때문이이죠.
SQL Relay도 제공하는 기능이 속도도 있지만 확장성, 여러 디비에 분산 엑세스, 지원되지 않는 플랫폿에서의 db접근등이 있네요.
시간여유가 있으면 좀더 자료를 뒤져보고 찾아보고싶지만 지금은 시간이 안되어.
음. 쓰고나니 좀 두리뭉실한 글이 되어버렸네요.
아 그리고 요즘엔 여기 글을 쓰지 않기는 하지만 예전에 가끔 글을 올린적이 있었지요. 오래되어서 기억이 잘 안나지만.
오~ 비록 대부분이 알아들을수 없는 얘기지만, 읽는 사람(초보인입장)으로 하여금 정말 공부하고 싶게 만들어주는 토론이네요. 스쿨의 가장 큰 미덕이 아닐까 하네요. 긴 토론 하신분들 모두 감사합니다.
문태준님 좋은 정리글에 감사드립니다.
프로그래밍이나 어느분야에서나...
개인적으로 가장 경계하는 것은 비판없이 수용하는 것입니다.
특히 우리같은 개발쪽 분야예선, 이건 거꾸로 우리 자신에게 커다란 억압이 됩니다.
다행인 것은 적어도 개발쪽에서는, 실험을 통해 결과를 알 수가 있으니 분명한 결론을 얻기위해 노력이라도 할 수 있어 좋습니다.. (물론 이론적 추론도 가능하고.. )
이 문제에 대해 나중에라도 증명할 기회가 있으면 좋겠습니다.
어느쪽의 말이 맞든지간에... 지금은 다들 추론 상태니까요.
토론에 참여해주신 분들께 감사드립니다...
-- jeon.
프로그래밍이나 어느분야에서나...
개인적으로 가장 경계하는 것은 비판없이 수용하는 것입니다.
특히 우리같은 개발쪽 분야예선, 이건 거꾸로 우리 자신에게 커다란 억압이 됩니다.
다행인 것은 적어도 개발쪽에서는, 실험을 통해 결과를 알 수가 있으니 분명한 결론을 얻기위해 노력이라도 할 수 있어 좋습니다.. (물론 이론적 추론도 가능하고.. )
이 문제에 대해 나중에라도 증명할 기회가 있으면 좋겠습니다.
어느쪽의 말이 맞든지간에... 지금은 다들 추론 상태니까요.
토론에 참여해주신 분들께 감사드립니다...
-- jeon.
참고하세요... 몇번 테스트해본 결과입니다.
컨넥션...
mysql : 0.00042sec (한가한 개인서버)
oracle : 0.04969sec (좀 비지한 운영서버)
-- jeon.
컨넥션...
mysql : 0.00042sec (한가한 개인서버)
oracle : 0.04969sec (좀 비지한 운영서버)
-- jeon.
/jeon
추론 상태가 아니라, 이미 많은 자료들이 존재하는 내용이기에 더 이상 언급되지 않는 것 입니다. (또는 이전 글에서 말씀 드렸다시피 사내문서라 오픈을 할 수 없거나, 귀찮은 부분이 가장 크겠지요.)
조금만 노력하신다면 관련 자료들은 읽어 보기도 벅찰 정도로 차고도 넘칩니다. 구태여 하나 집어 드리자면, javaservice.net에서 이원영씨의 글이나 직접 검색해 보셔도 많은 사례를 보실 수 있을겁니다.
이러한 명확하고 충분히 스스로들 찾아볼 수 있는 내용에 대해서 증명을 운운한다는 것 자체가 이해하기 힘드네요.
또한 단순히 마이크로타임을 찍어, 커넥션 시간을 측정하는 방식으로는 아무것도 알 수가 없습니다. (차라리 스트레스테스트툴을 구하셔서 조금씩 강도를 높여 가면서 측정하시는 것이 정확하실 겁니다.)
토론에 발언권을 가진 발언자는 최소한의 참여 자격이 있습니다. 몇몇 잘못된 지식을 버젓이 언급한 후, 그 부분에 대한 지적은 유야무야 흐리고, 예의바른? 감정적 대응으로 넘어가는 것은 초급 개발자들에게는 잘못된 상식을 안겨주고, 중/고급 개발자에게는 씁쓸한 기분을 주어서 참여 자체를 막게 됩니다.
이런 부분들이 참으로 아쉽네요.
토론은 명확한 본인의 지식을 기반에 두고, 서로간에 배워가는 장 입니다. (최소한 본인이 아는것은 명확히 언급을 하고, 모르는 부분에 대해서는 겸허히 받아들여야 한다는 의미입니다.) 그 최소한의 지식의 기반없이는 아무런 진전없이 상투적인 대화들만 오가겠지요.
추론 상태가 아니라, 이미 많은 자료들이 존재하는 내용이기에 더 이상 언급되지 않는 것 입니다. (또는 이전 글에서 말씀 드렸다시피 사내문서라 오픈을 할 수 없거나, 귀찮은 부분이 가장 크겠지요.)
조금만 노력하신다면 관련 자료들은 읽어 보기도 벅찰 정도로 차고도 넘칩니다. 구태여 하나 집어 드리자면, javaservice.net에서 이원영씨의 글이나 직접 검색해 보셔도 많은 사례를 보실 수 있을겁니다.
이러한 명확하고 충분히 스스로들 찾아볼 수 있는 내용에 대해서 증명을 운운한다는 것 자체가 이해하기 힘드네요.
또한 단순히 마이크로타임을 찍어, 커넥션 시간을 측정하는 방식으로는 아무것도 알 수가 없습니다. (차라리 스트레스테스트툴을 구하셔서 조금씩 강도를 높여 가면서 측정하시는 것이 정확하실 겁니다.)
토론에 발언권을 가진 발언자는 최소한의 참여 자격이 있습니다. 몇몇 잘못된 지식을 버젓이 언급한 후, 그 부분에 대한 지적은 유야무야 흐리고, 예의바른? 감정적 대응으로 넘어가는 것은 초급 개발자들에게는 잘못된 상식을 안겨주고, 중/고급 개발자에게는 씁쓸한 기분을 주어서 참여 자체를 막게 됩니다.
이런 부분들이 참으로 아쉽네요.
토론은 명확한 본인의 지식을 기반에 두고, 서로간에 배워가는 장 입니다. (최소한 본인이 아는것은 명확히 언급을 하고, 모르는 부분에 대해서는 겸허히 받아들여야 한다는 의미입니다.) 그 최소한의 지식의 기반없이는 아무런 진전없이 상투적인 대화들만 오가겠지요.
다만 한가지, 비판없이 수용하는 것을 경계한다는 말에는 전적으로 동의를 합니다.
다만, 그 부분 역시 서비스 지향 아키텍쳐니 모델 드리븐이니, method/1은 너무 낡지 않았는가, 로즈 보다는 투게더가 더 훌륭한 툴이지 않은가등과 같이 항상 구체적으로 답을 내리기 힘든 부분들에 어울리는 내용이라 생각됩니다.
즉, 구체적인 지식과 명확한 결론이 있는 토론과, 개인의 깊은 사색이 필요한 토론은 애초에 분리되어 있다는 의미이기도 합니다.
다만, 그 부분 역시 서비스 지향 아키텍쳐니 모델 드리븐이니, method/1은 너무 낡지 않았는가, 로즈 보다는 투게더가 더 훌륭한 툴이지 않은가등과 같이 항상 구체적으로 답을 내리기 힘든 부분들에 어울리는 내용이라 생각됩니다.
즉, 구체적인 지식과 명확한 결론이 있는 토론과, 개인의 깊은 사색이 필요한 토론은 애초에 분리되어 있다는 의미이기도 합니다.
찾아봐도 구체적인 성능향상 수치는 없던데요.. ?
자바쪽에선 컨넥션풀을 상당히 비중있게 생각하는 듯 한데, 좀 맹목적이군요. 왜 쓰는지에 대한 설명은 간략하고, \＇사용법\＇에 대한 설명은 90% 를 넘는 지면을 쓰고 있습니다.
오해를님
말씀은 잘 하시는데, 수치를 제공하고 증명해야할 사람은 바로 \＇오해를\＇ 님이 아닌가 싶군요. 제가 찾는것보단 훨씬 양질의 자료를 이미 갖고 계시지 않습니까...
계속 토론을 이어가고 싶다면 자료를 제시하면서 저에 대해 반박하는 것이 방법같군요. 백마디 말보다 한줄의 수치제시면 끝입니다.
계속해서 인문사회학적 토론을 하기 싫으시다면요.
-- jeon.
자바쪽에선 컨넥션풀을 상당히 비중있게 생각하는 듯 한데, 좀 맹목적이군요. 왜 쓰는지에 대한 설명은 간략하고, \＇사용법\＇에 대한 설명은 90% 를 넘는 지면을 쓰고 있습니다.
오해를님
말씀은 잘 하시는데, 수치를 제공하고 증명해야할 사람은 바로 \＇오해를\＇ 님이 아닌가 싶군요. 제가 찾는것보단 훨씬 양질의 자료를 이미 갖고 계시지 않습니까...
계속 토론을 이어가고 싶다면 자료를 제시하면서 저에 대해 반박하는 것이 방법같군요. 백마디 말보다 한줄의 수치제시면 끝입니다.
계속해서 인문사회학적 토론을 하기 싫으시다면요.
-- jeon.
전제 : 저희 회사에서 풀링을 이용한 전제는 db서버의 성능 향상과 관계가 있고 웹서버의 부하를 줄이고자 하는 목적은 아니였습니다.
참고로 현재 한개의 db 서버에 4개의 웹서버가 연동하고 있습니다.
php4 와 오라클9i의 디스커넥션이 지원되는 않는 문제는
운영하시는 분이 계시면 테스트 바랍니다..
저희의 테스트 결과는 disconnect() 함수에 의해서가 아닌 php프로세스 소멸과 함께 oracle의 커넥션이 끊기는것 같다는 것입니다.
1. 저도 월요일 출근을 하게 되면 이 부분에 대한 테스트를 다시 해보도록 하겠습니다.
2. 저번 올린 자료의 뒷받침 할 만한 자료(스트레스 테스트 자료)를 업로드 하도록 하겠습니다.
참고로 현재 한개의 db 서버에 4개의 웹서버가 연동하고 있습니다.
php4 와 오라클9i의 디스커넥션이 지원되는 않는 문제는
운영하시는 분이 계시면 테스트 바랍니다..
저희의 테스트 결과는 disconnect() 함수에 의해서가 아닌 php프로세스 소멸과 함께 oracle의 커넥션이 끊기는것 같다는 것입니다.
1. 저도 월요일 출근을 하게 되면 이 부분에 대한 테스트를 다시 해보도록 하겠습니다.
2. 저번 올린 자료의 뒷받침 할 만한 자료(스트레스 테스트 자료)를 업로드 하도록 하겠습니다.
php4 + oracle8i(Enterprise with MTS) 으로 돌려봤었는데
동시접속 100명이상 거뜬 합니다.(WebLog 1G/일 이상 사이트였습니다.) ^^;
dedicate 로는 종종 DB가 죽는 상황이 있었는데 MTS로 돌린후에는 그런일이 없었지요. disconnect()도 잘 되었습니다.
MTS쓰고 나서는 connection pooling을 굳이 찾을 필요가 없었습니다.
동시접속 100명이상 거뜬 합니다.(WebLog 1G/일 이상 사이트였습니다.) ^^;
dedicate 로는 종종 DB가 죽는 상황이 있었는데 MTS로 돌린후에는 그런일이 없었지요. disconnect()도 잘 되었습니다.
MTS쓰고 나서는 connection pooling을 굳이 찾을 필요가 없었습니다.
지나가다 우연히 글을 봤는데 서로 소모적인 논쟁을 하는 것 같네요.
위에서 어떤 분이 언급하셨듯이 하나의 기술이 모든 상황에 절대적으로 적용되는 것은 아니라고 생각합니다. 만약 많은 사용자가 새로운 커넥션을 요청하는 일이 빈번하다면 커넥션 풀을 사용하고 사용자가 적다면 굳이 거추장스럽게 커넥션 풀 같은걸 사용할 필요는 없겠지요. 제가 보기엔 두 주장 다 일리가 있는데 서로 자신의 상황에 비추어서만 글들을 남기시는것 같습니다.
커넥션 풀 기법이 무가치하지 않다는건 알고 계실테고, 만약 우리가 모든 일을 논하는데 있어 수치를 제시해야 한다면 의견 교환은 매우 더뎌질 수 밖에 없을 것입니다. 또한 CPU가 성능이 50% 개선되었는데 CPU만 갈면 시스템 성능이 50% 개선 되느냐 하면 그렇지 않고 실제 전체 성능 개선은 그보다 훨씬 못하다는 것은 다들 아실겁니다.
저는 절대적인것은 없다라고 생각합니다. 모든 경우가 일반적이라면 왜 개발 툴은 이렇게 많으며 왜 DBMS는 이렇게 종류가 많을걸까요? 결국 그 상황에 맞게 선택하는게 중요한 것 같습니다.
위에서 어떤 분이 언급하셨듯이 하나의 기술이 모든 상황에 절대적으로 적용되는 것은 아니라고 생각합니다. 만약 많은 사용자가 새로운 커넥션을 요청하는 일이 빈번하다면 커넥션 풀을 사용하고 사용자가 적다면 굳이 거추장스럽게 커넥션 풀 같은걸 사용할 필요는 없겠지요. 제가 보기엔 두 주장 다 일리가 있는데 서로 자신의 상황에 비추어서만 글들을 남기시는것 같습니다.
커넥션 풀 기법이 무가치하지 않다는건 알고 계실테고, 만약 우리가 모든 일을 논하는데 있어 수치를 제시해야 한다면 의견 교환은 매우 더뎌질 수 밖에 없을 것입니다. 또한 CPU가 성능이 50% 개선되었는데 CPU만 갈면 시스템 성능이 50% 개선 되느냐 하면 그렇지 않고 실제 전체 성능 개선은 그보다 훨씬 못하다는 것은 다들 아실겁니다.
저는 절대적인것은 없다라고 생각합니다. 모든 경우가 일반적이라면 왜 개발 툴은 이렇게 많으며 왜 DBMS는 이렇게 종류가 많을걸까요? 결국 그 상황에 맞게 선택하는게 중요한 것 같습니다.
MySQL은 의외로 제가 써본 경험에 의하면 커넥션 클로즈가 제대로 안돼어서 죽는경우가 많습니다. 설정에서 시간 설정에 짧게 잡아도 어는 마진이 필요하기때문에 완전히 끈는데는 시간이 걸리는데요..그사이 계속 커넥션 요청이 들어오면 DB 다운 _ _;; 이런 경우가 생깁니다. 그리고 oracle에서 MTS와 DEDICATE연결은 커넥션 풀하고는 거리가 먼 문제인거 같은데요..분석툴로 한번 보시면 왜 데디케이트에서 죽는지 알아내실수 있을듯 하네여.
망게님께 한표...
이리저리 검색해봤는데
전 nt기반에서 놀다보니 커넥션풀에 대해 무지했습니다.
ms가 시키는대로만 했으니... ㅋㅋ
찾아보니 ms는 이미 커넥션풀을 제공하더군요.
그러나 오라클 경우는 프로그래머가 직접 작업해야 한다고 하네요. 이래나 저래나..
다들 부하걸리게시리 db에 의존하고 계시나요? html생성도 좀 하시고 클라이언트단의 변수에 데이타도 좀 넣어놓고 그러세요.
그럼 커넥션풀을 쓸 일 별로 없을껍니다.
이리저리 검색해봤는데
전 nt기반에서 놀다보니 커넥션풀에 대해 무지했습니다.
ms가 시키는대로만 했으니... ㅋㅋ
찾아보니 ms는 이미 커넥션풀을 제공하더군요.
그러나 오라클 경우는 프로그래머가 직접 작업해야 한다고 하네요. 이래나 저래나..
다들 부하걸리게시리 db에 의존하고 계시나요? html생성도 좀 하시고 클라이언트단의 변수에 데이타도 좀 넣어놓고 그러세요.
그럼 커넥션풀을 쓸 일 별로 없을껍니다.
참고로... 니가 뭘 아느냐 혹은 니글은 여기에 해당되는 글이 아니다 라면서 면서 태클 거실 분 있을텐데요..
관련있습니다. 목적은 부하 안걸리고 잘 돌리는거니깐요.
참고 : phpschool 이나 야후코리아보다 더 부하 많이 걸리는 곳에서 전 일하고 있습니다.
관련있습니다. 목적은 부하 안걸리고 잘 돌리는거니깐요.
참고 : phpschool 이나 야후코리아보다 더 부하 많이 걸리는 곳에서 전 일하고 있습니다.
쇼크렛 06-03-10 16:03저는 C프로그래머입니다. 주로 소켓과 네트워크 프로그래밍을 해왔는데,
그전에 통신사 프로젝트할때, 일반적으로 하나의 프로세스 또는 하나의 쓰레드에서
접속을 열고 패킷을 주고 받고, 접속을 끊는 방식으로 하니까 로드러너 툴로 300TPS정도 나오더군요.
한데, 아파치 서버 소스를 참조해서 커넥션풀 방식으로 바꾸니까 1000TPS 정도 나오더군요.
아파치 서버는 한 1500TPS 나오더라구여. PHP만 짜시지 마시고, 아파치 서버의 C소스를 보세여.
그럼 커넥션풀이 얼마나 좋은건지 아실겁니다. ㅋ
그전에 통신사 프로젝트할때, 일반적으로 하나의 프로세스 또는 하나의 쓰레드에서
접속을 열고 패킷을 주고 받고, 접속을 끊는 방식으로 하니까 로드러너 툴로 300TPS정도 나오더군요.
한데, 아파치 서버 소스를 참조해서 커넥션풀 방식으로 바꾸니까 1000TPS 정도 나오더군요.
아파치 서버는 한 1500TPS 나오더라구여. PHP만 짜시지 마시고, 아파치 서버의 C소스를 보세여.
그럼 커넥션풀이 얼마나 좋은건지 아실겁니다. ㅋ
출처 - http://www.phpschool.com/gnuboard4/bbs/board.php?bo_table=tipntech&wr_id=36317&sca=DBMS&page=8
'연구개발 > Linux' 카테고리의 다른 글
| [UNIX/LINUX] Shell Script 기본 - 1.if문 (1) 기본 사용법 (0) | 2014.05.04 |
|---|---|
| centos 6.x max process 값 튜닝 for mysql (0) | 2014.04.13 |
| linux 방화벽 해제 (0) | 2014.04.01 |
| YUM 설치시 (0) | 2014.04.01 |
| CentOS6 레드마인 최신 버전 설치기 (redmine) (0) | 2014.03.24 |