웹페이지 새로 고침 질문 사항입니다.

[박대권]

안녕하세요 -

---
개발의 90% 가량 완료되어 슬슬 운영으로 반영을 준비중입니다.
이런 차에 고객측에서 성능 테스트를 한다고 하면서 2~3분이 데모 사이트에 접속하여
f5 (새로고침)을 무한정 반복을 하였습니다.
그리고, db쪽는 tns 오류 발생하면서 화면에 db 연결 오류가 발생하자 성능 부분에 대해서
상당히 강하게 압력을 가하네요 ...
---
운영 환경은 tomcat 6 + oracle 11g 입니다.
spring 3.0.2 기반으로 개발을 하였는데 솔직히 저렇게 하니 ... 답이 없더군요.
db 쪽 담당자에게 이야기하여 process 갯수랑 open_cursor 갯수를 증가 시키고
톰갯쪽 설정에서 maxthread, minsparethread 등의 값을 변경해보았지만 해결책은 될것 같지 않네요 -

spring 쪽 혹은 db 캐시 등과 같은걸로 어느정도 상호 보완을 고려중입니다만
어떻게 보안을 해가는게 좋을까요?

[김성국]

좀더 자세한 설명이 필요해 보입니다.

현재 DB커넥션 풀 갯수 및 대략적인 환경이 어떻게 되는지..

2~3명이 F5무한반복 스트레스 테스트를 해서 문제가 발생했을 때 나타난 오류메시지는 무엇인지..

퍼시스턴트 계층에 프레임은 어떤걸 사용했는지...

겨우 2~3분깨서 F5를 무한반복한다고 문제가 발생한다면 구현 방법 자체에 문제가 없는지 검토해봐야 할 듯 합니다.

tns오류이면.... 커넥션을 더이상 가져올 수 없어서 생기는 문제인가요????

보통 웹에서는 DB에 대한 커넥션을 오래가져가는 경우가 거의 없을껀데요.. (몇몇 특이한 경우는 제외하겠습니다..)

실제로 800~1000명정도의 사용자가 수시로 사용하는(동시접속은 아니구요...) 업무페이지도 커넥션풀은 30개로 충분히 돌아갑니다.

실행되는 쿼리중에 실행시간이 오래걸리는 쿼리들을 찾아서 쿼리나 인덱스등을 지정하는건 당연한거라서 예기하기도 그렇네요..

2차 캐시로 EHCache와 같은걸 사용하는 것도 손쉽게 성능을 올릴 수는 있지만,

그렇다고 궁극적인 해결책이 되진 못할 것 같습니다. 

메인페이지는 여러 항목을 한꺼번에 보여주는 경우가 많기 때문에.. 

단시간 내에 동일한 내용이 조회되지 않도록 신경쓸 필요가 있습니다.

이중에 변경이 거의 없는 질의내용이 있다면 이쪽을 DB에 질의 조차 하지 않도록 하는 것도 성능에 많은 도움이 됩니다.

대표적인 예로 코드성 데이터들이 있겠네요... 셀렉트 박스 달랑 하나 그리자고 매 요청마다 DB에 쿼리를 던지기 보단...

Map과 같은 형태로 스프링 빈을 등록한 뒤에 사용하는 방법을 사용하길 권합니다.

실제로 예전에 다른분이 메뉴 항목 하나 조회할때마다 메뉴트리 쿼리를 질의하도록 구현한걸,

개발중에도 사이트가 너무 느린 느낌이 들어서 메뉴 전체를 메모리에 올리도록 새로 짜버린 뒤에 체감속도가 몰라보게 빨라진 경험도 있습니다.

메뉴는... DB에서 관리하고자 할 경우 모든 페이지에 들어가고.. 거의 변경이 없는 데이터이면서 쿼리비용이 비싼 대표적인 엔티티라고 할 수 있죠...

날 Java코딩으로 작업할 때는 DB리소스 반환을 제대로 처리안하는 몇몇 개발자 때문에 DB쪽문제를 겪어본적 있지만..

스프링을 사용하면 상대적으로 리소스 반환과 같은 부분에 신경쓰는 일이 없어서 오히려 DB쪽은 신경을 안쓰게 되던데요..

오히려 JVM의 Heap메모리쪽으로 더 스트레스를 받았었는데 특이한 경우 같습니다.

아는데로 끄적였습니다만 저도 하수인지라..... ^^

2012년 4월 22일 오전 3:53, 박대권 <pran...@gmail.com>님의 말:

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

--
-----------------------------------
sungko...@gmail.com
010-3339-1286
김 성국
-----------------------------------

[코바(이수홍)]

정보가 좀 부족하네요

새로고침 아무리해도 DB에 연결 오류가 생긴다는게 좀 이상하네요

프로그램쪽 문제가 있는게 아닐지 조심스럽게 의심되구요

느리다는건 이해가지만 저렇게 에러나는건 뭔가 문제 있어 보입니다.

물론 커넥션풀 옵션을 타이트하게 조절 했거나 하면 문제가 생길 수도 있지만

그런건 아닌것 같은느낌인데

캐시나 다른 문제를 보지 마시고 전체적인 프로그램 부분을 한번 보고 고칠게 있는지 확인해보는게 어떠 신지요

물론 웹쪽 최적화는 캐시나 gzip사용이나 스크립트 최적화 등을 하면됩니다만

말씀하신부분은 조금 의심스럽네요

[고종봉]

고생이 많으십니다. ^^;

제가 경험하고, 알고 있는 지식으로는,, 

스프링을 사용했다고 db 커넥션에 문제가 생기지는 않습니다.. 왜냐하면 실제로 db 커넥션을 담당하는 부분은

dbcp 설정으로 사용하고 있는 dbcp 라이브러리가 될테니까요.

앞서 말씀하신 것처럼,, 새로 고침을 반복했을 때 오라클 TNS 에러가 났다고 하는 것은 (원인이 새로고침 때문이라고 한다면..)

분명히 커넥션이 제대로 반환이 되지 않는 등의 구현에 문제가 있는 것으로 보입니다.

다만,, 코드 상에서 커넥션 반환이 제대로 안되었는지 (예전 개발 방식처럼.. 코드 상에서 직접 커넥션 반환을 했다면..)

또는,, dbcp 라이브러리 버전을 확인해보는 것이 좋을 듯 합니다.

apache-commons-dbcp 라이브러리 자체도 완벽하다고 신뢰할 수는 없으며,, 특정 버전에서 커넥션 반환에 문제가 있는것이 발견되어 패치된 경우가 있는 것으로 알고 있습니다.

저희 쪽에서 사용하고 있는 소스를 지금 확인하기 어려워 구체적으로 답변드리지는 못하지만,

충분히 사용자가 많은 서비스인데도 커넥션은 (톰캣)서버당 10개를 넘기지 않고 있습니다. 

dbcp 라이브러리 쪽을 확인해보시고,, 버전 변경이나 패치버전 적용 등의 시도를 해보시는 것을 권장드립니다.!! ^^;

수고하세요.

2012년 4월 22일 오전 3:53, 박대권 <pran...@gmail.com>님의 말:

안녕하세요 -

[박대권]

답변 고맙습니다.

처음 설정할때 기본 spring connection pool을 설정해서 계속 사용했습니다.
(org.springframework.jdbc.datasource.DriverManagerDataSource)
이 부분을 dbcp 으로 변경해서 하니 어느정도 해결은 되었습니다.
(org.apache.commons.dbcp.BasicDataSource 1.4 )

ibatis, dbcp 설정은 기본 설정으로 유지하여 테스트를 진행하니 java heap size 쪽에 에러를 출력하더군요.
데모 환경은 windows 7
tomcat 6.0.23 - spring mvc - spring - ibatis - oracle 11g

실제 운영할 환경은 amazon cloud ec2 서버( 일본 위치 )
cpu 4 / ram 7.5gb 입니다. 클라우드 서비스를 하니 실제 서비스 보단 조금 반응(?)이 느리더군요 ^^;

ibatis의 설정
useStatementNamespaces="true"
lazyLoadingEnabled="true"
cacheModelsEnabled="true"
enhancementEnabled="true"

tomcat server.conf
maxThreads="1024" minSpareThreads="126" maxSpareThreads="512" acceptCoubt="100"

으로 설정해서 사용하였습니다.

^^; 계속 적으로 변경해가면서 테스트를 해보겠지만 ...
특하지 않은 환경( 아마존 클라우드 )이 발생함에 따라 머리가 좀 아프네요 ^^;

[Sanghyuk Jung]

안녕하세요, 여담이지만, DriverManagerDataSource은  실제로는 connection pool이 아닙니다.. 웹쪽 시스템이라면 이 클래스는 거의 테스트 용도라고 보셔도 됩니다.

 결국 spring 자체적으로 connection pool은 제공하지 않으므로 'spring connection pool'이라는 용어는 혼동의 여지가 있다고 생각합니다~^^

2012년 4월 23일 오전 1:22, 박대권 <pran...@gmail.com>님의 말:

[코바(이수홍)]

톰캣 JNDI를 사용 안하시고 직접 DBCP 셋팅을 해주셨다면

스프링에서 C3P0 커넷 풀이 좋다고 들었습니다.

<bean id="abstractDataSource"
class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-
method="close" abstract="true">
<property name="initialPoolSize" value="5" />
<property name="maxPoolSize" value="20" />
<property name="minPoolSize" value="5" />
<property name="acquireIncrement" value="5" />
<property name="acquireRetryAttempts" value="30" />
<property name="acquireRetryDelay" value="1000" />
<property name="driverClass" value="클래스" />
<property name="jdbcUrl" value="접속정보" />
<property name="user" value="아이디" />
<property name="password" value="패스워드" />
</bean>

이것도 한번 사용해보시지요
무슨 문제인지는 정확히 모르겠지만
이것저것 시도 해보는것도 괜찮을듯합니다.

On 4월22일, 오후8시48분, 고종봉 <mercujj...@gmail.com> wrote:
> 고생이 많으십니다. ^^;
>
> 제가 경험하고, 알고 있는 지식으로는,,
>
> 스프링을 사용했다고 db 커넥션에 문제가 생기지는 않습니다.. 왜냐하면 실제로 db 커넥션을 담당하는 부분은
>
> dbcp 설정으로 사용하고 있는 dbcp 라이브러리가 될테니까요.
>
> 앞서 말씀하신 것처럼,, 새로 고침을 반복했을 때 오라클 TNS 에러가 났다고 하는 것은 (원인이 새로고침 때문이라고 한다면..)
>
> 분명히 커넥션이 제대로 반환이 되지 않는 등의 구현에 문제가 있는 것으로 보입니다.
>
> 다만,, 코드 상에서 커넥션 반환이 제대로 안되었는지 (예전 개발 방식처럼.. 코드 상에서 직접 커넥션 반환을 했다면..)
>
> 또는,, dbcp 라이브러리 버전을 확인해보는 것이 좋을 듯 합니다.
>
> apache-commons-dbcp 라이브러리 자체도 완벽하다고 신뢰할 수는 없으며,, 특정 버전에서 커넥션 반환에 문제가 있는것이
> 발견되어 패치된 경우가 있는 것으로 알고 있습니다.
>
> 저희 쪽에서 사용하고 있는 소스를 지금 확인하기 어려워 구체적으로 답변드리지는 못하지만,
>
> 충분히 사용자가 많은 서비스인데도 커넥션은 (톰캣)서버당 10개를 넘기지 않고 있습니다.
>

> *dbcp 라이브러리 쪽을 확인해보시고,, 버전 변경이나 패치버전 적용 등의 시도를 해보시는 것을 권장드립니다.!! ^^;*
>
> 수고하세요.
>
> 2012년 4월 22일 오전 3:53, 박대권 <pranl...@gmail.com>님의 말:

[wonhee]

ORA-12519 오류가 계속 나타나는 거라면 우선 processes갯수가 톰캣의 풀 max 설정갯수 x 톰캣 갯수 보다 큰지 우선 확인하시고요.
myBatis의 캐싱도 적극적으로 활용해 보세요. 가능하면 memcached 도입하고 etags 등등을 비교해서 값이 변경된 경우만 DB에서 데이터를 읽어오도록 고친다던가 하시고요..
요청이 밀리는 경우 queue 때문에 계속 서비스가 밀리는 걸 방지하기 위해서 DB/Tomcat 등의 connection timeout, read timeout 등등의 파라메터 등도 손볼 필요가 있을 것 같습니다.

프로파일러나 디버깅 모드 등을 통해서 혹시나 불필요한 객체 생성이나 DB쿼리가 발생하고 있지는 않은지도 테스트를 해보시고요.

그리고 좀 말이 안될수도 있겠지만 계약내용에 성능테스트에 대한 부분이라든가 보장해야 되는 성능에 대해서 어떻게 명시를 해놨는지를 찾아보세요.
물론 성능튜닝이 필요하다고 생각하지만 그냥 여러명 와서 F5를 주구장창 누르고 있으면서 성능테스트라고 하는것도 좀 그렇네요. 운영으로의 반영을 준비중이라면 이미 database 도 상용기쪽으로 옮기고 Tomcat도 충분히 준비가 된 상태인지요?

좀 다른 이야길수도 있겠지만, 마지막으로 오류 메세지도 일부 수정할 필요가 있을 같습니다. 시스템 오류(네트워크 연결오류/DB 오류 등등) 등은 사용자 화면에 보여줘 봐야 사용자가 뭘 할 수 있는것도 아니니까, 그냥 서비스가 지연되고 있다든가 하는 무난한 메세를 보여주는 것도 괜찮을 것 같네요.