connection pooling 은 client stack(클라이언트에서 구현하는 영역) 이며 각종 ADO(ole db, odbc, jdbc, ado.net 등) 에서 모두 다른 코드로 구현되어 있습니다. .net 4.0 부터는 사용자가 강제로 pooling 을 disable 하지 않는한 default 로 pooling 을 사용합니다. profiler 나 extended events 에서 sp_reset_connection 이 모니터링 된다면 잘 사용한다고 할 수 있습니다. 테스트 프로그램을 작성한다면 connection 을 10번 open/close 하는 프로그램을 짜고 실행시키면 첫 번째만 실제 connection 을 open 하고 일정 기간동안 server 에서는 삭제하지 않고 가지고 있으며 이는  sys.dm_exec_sessions 에서 dormant 상태로 나타납니다. 나머지 9번은 sp_reset_connection 을 보내 connection 을 재 사용하게 됩니다. (주제 범위를 조금 넘어서지만 sp_reset_connection 은 by design 으로 반드시 사용해야 합니다. 초창기 .net framework 에서는 sp_reset_connection 을 사용하지 않는 방법이 있었지만 이제는 없습니다. sp_reset_connection 이 없다면 시간으로 connection 을 차단하는 logon trigger 를 만들수 없고, 실제 open / close 와 같은 수준의 완전한 conection 의 초기화가 불가능 하기 때문입니다. ) profiler 나 extended events 의 login/logout 으로 실제 login logout 을 알 수 있고, perfmon counter 로는 .NET Data Provider for SqlClient (client connection pool information, per process) 와 SQL Server:General statistics (counters are logins/sec, logouts/sec, connection resets/sec, logical connections) 등이 있습니다.

500 명 이상에서 버벅거림은 다른 wait 를 조사해 보는것이 좋을듯 하며, wait 는 extended evnts 로 명확히 알 수 있습니다. extended events 는 이제 전공 필수 이구요~ sqltag book 2 에 잘 설명되어 있습니다. 쿨럭~

dedicate 와 shared

http://docs.oracle.com/cd/B28359_01/server.111/b28310/manproc001.htm

이는 oracle process 모델이 shared server 로 설정되어 있을때 dedicate 모드로 접속하고 싶다면 net service name 에 server=dedicate 를 명시해라 라고 되어 있습니다. oracle 은 1개의 connection 당 오라클 process 는 약 20MB (이는 버전마다 틀리고 마이그레이션 메모리사이즈의 주요한 고려 요소 중 하나입니다.)의 메모리 리소스를 사용합니다. sql server 의 경우 thread 모델을 사용하고 아키텍처에 따라 틀립니다. (x86=512KB, x64=2MB, IA64=4MB) sql server 보다 oracle 의 process 모델은 메모리를 엄청나게 크게 사용하죠 예를들어 오라클 dedicate 모드에서 100개 연결을 맺는다고 한다면 2GB 의 메모리가 필요하게 됩니다. 이 경우 buffer pool 메모리가 부족하게 되는 경우가 있겠죠 한마디로 캐시 영역이 작아집니다. sql server 는 아까 말한것과 같이 thread 모델을 사용하고 max worker threads 에 설정된 값보다 쿼리 요청수가 작으면 스레드당 하나의 쿼리가 사용되고 그 값보다 많은 쿼리 요청수가 있으면 내부에서 pooling (이때부터 oracle 의 shared 이죠) 합니다. 그러나 1개의 쿼리에서 여러 thread 를 사용할 수도 있습니다. 그래서 병렬 쿼리 thread deadlock 같은게 생기기도 하고 그렇죠. 그러므로 sql server 에서 사용한다면 shared 이냐 dedicated 이냐를 고민할 필요는 없을듯 합니다. 또 worker thread 가 많으면 일을 잘 하느냐? 못 하는냐? ..... 이것도 it depends on 인데요 실제 processor 가 몇개 있느냐? 쿼리는 어떤 타입의 쿼리이냐? 에 따라서 틀립니다. 이는 multi thread application 을 많이 짜보았다면 느낌 오실겁니다. 이런거 저런거 다 모르면 물리코어 숫자에 따른 가이드가 msdn 에 있습니다. https://msdn.microsoft.com/ko-kr/library/ms190219(v=sql.120).aspx 가이드는 가이드일뿐 입력되는 쿼리에따라 이 숫자는 튜닝이 필요합니다.

오라클의 dedicate 에서 shared 로 설정해 빨라진 것은 dedicate 로 설정해 500개의 connection 을 맺었다면 500*20MB = 10GB 가 프로세스 메모리로 사용되고 있었고 16GB 장비였다면 buffer pool 용량이 상대적으로 작았을 겁니다. 이로인해 buffer cache hit ratio 가 작았을 것이므로 disk 응답속도에 가까운 응답이 있었을 것이고, shared 로 바꾼 후 상대적으로 buffer pool 용량이 많아져 buffer cache hit ratio 가 좋아져서 응답 속도가 빨라진 거겠지요.......