2011.04.17 추가..
옛날에 올린 글인데, 의외로 아직까지 매일 히트수가 좀 되네요..
아직도 딱히 효율적인 튜닝 지식을 얻지 못해, 성능이 중요한 상황에서는 윈도우+아파치+톰캣 조합은 사용하지 않기로 했습니다.. 리눅스+아차피+톰캣 조합이 특별한 튜닝을 하지 않아도 괜찮은 성능이 나오는 반면, 윈도우상에서는 저 같은 초보는 성능 이끌어 내는 것이 쉽지 않은 것 같습니다.. 분명 잘 사용하시는 분들도 계실텐데.. 관련된 튜닝서적이나 정보들을 모으면 다시 점검을 해봐야겠습니다.. 언제나 그럴 시간이 날지는 모르겠습니다만..
솔직히.. 국내 SI 상황만 아니면.. 리눅스에선 PHP로, 윈도우에서는 ASP나 ASP.NET으로 개발하고 싶습니다.. 전 개인적으로 솔직히 동일한 스펙의 H/W라면 자바가 가장 느리다고 생각합니다.. 하지만, 엄청난 차이가 나진 않을 것이니 중요치 않구요, 윈도우에서 톰캣 돌려야 하는 상황이 생각보다 많다는게 아쉽지만, 현실이구요.. 맘 같아선 톰캣은 개발자 개인 개발용으로만 쓰고 싶지만, 현실은 그렇지 않으니..
뭐, 경험과 실력이 미천한.. 그래서 그냥 별다른 튜닝 없이도 어느 정도 성능 나오주길 기대한 허접 톰캣 사용자의 넋두리라고 보심 되겠습니다.. ㅋㅋㅋ
작년에 진행했던 프로젝트 중에 12대의 서버에 Tomcat을 설치해 진행했던 프로젝트가 있다.. 최대 접속자를 늘리기 위해 여러가지 세팅 값을 바꾸고 최대 성능을 낼 수 있도록 조정을 했었는데 원하는 만큼 속도가 안 나오는게 문제였다.. 우리는 Tomcat과 JSP로 충분한 속도를 낼 수 있다고 했고, 고객사에서는 IIS와 ASP.NET이 훨씬 빠르니 초기접속 및 핵심 페이지 몇개를 ASP.NET으로 바꾸자고 했다..
물론, 앞에 아파치 웹서버를 붙이면 성능에 훨씬 도움이 될 것이라는 것은 알았지만 정적 페이지들은 거의 없었고 디자인을 위한 이미지 파일들도 최소화 시켜둔 상태였다.. 하지만, 그래도 찜찜해하는 고객사 분들 때문에 이 파일들도 모두 IIS 쪽으로 돌렸다..
Windows 2003 서버 12대에 MS SQL 2000 DB 서버가 1대가 운영되었는데, 웹서버에는 IIS와 톰캣이 포트를 달리하여 모두 설치되어 있었다.. 우리는 톰캣이 어느 정도 성능을 내줄 것으로 기대를 했었다.. 아파치는 다른 어떤 웹서버에 비해서도 떨어지지 않는 성능을 보여줬지 않는가.. 톰캣 역시 제우스나 웹로직 같은 상용 WAS에 못지 않는, 혹은 떨어진다고 해도 약간 떨어지는 정도의 성능을 보여줄 것으로 기대를 했었다.. 하지만, 역시 상용 WAS 보다는 성능이 훨씬 못 미치는가 보다..
몇번의 부하 테스트를 통해 톰캣은 원하는 성능이 나오지 못함을 확인했다.. 하지만, 부하가 많이 걸릴 것으로 예상되는 몇개 페이지를 ASP.NET으로 만들어 같은 성능 테스트를 해보니 훨씬 좋게 나왔다.. Tomcat이 상용 서버만큼의 속도가 나올 것이라는 기대를 하는 것은 너무한 기대였을까? IIS + ASP.NET + Windows 2003 서버에 비해 절반 정도의 성능 밖에 안 나오다니.. 리눅스에서 돌리지 않고 윈도우에서 돌려서 그런가? 아무튼 톰캣, 왕 실망이다..
물론, 몇개 페이지만 가지고 단편적인 실험을 통해 이렇게 이야기 하는 것이 좀 무리이긴 하지만 말이다.. 언제 심심하면 Tomcat의 성능비교 자료를 함 찾아봐야겠다..
2008.04.09
댓글로 Tomcat이 그렇게 성능이 떨어지지 않는다며 정보를 주셨던 nokarma님께서 Tomcat, 정말 실망이야..? 라는 글을 통해 좀 더 구체적인 정보를 제공해주심.. 하지만, 구체적으로 Tomcat을 어떻게 튜닝 혹은 세팅값을 변경해야 하며 또는 프로그래밍시 어떤 부분들을 어떻게 하는게 좋다는 구체적인 내용을 담은 자료는 없다.. 나도, 톰캣으로 좋은 성능을 내는 사이트가 있을 것으로 생각한다.. 하지만, 나도 그렇게 하고 싶은데 어떻게 해야 하는지를 모른다는 것이다.. 반면 IIS는 특별한 튜닝 혹은 세팅 없이도 Tomcat 보다 월등한(?) 성능을 내고 있다.. 퍼포먼스 테스트는 다른 방법을 취한게 아니라 실제로 사람이 붙어서 했다.. 8천명 정도가 5~10분 사이에 일제히 들어와 사이트를 사용하는 것인데.. 톰캣은 에러나는 페이지를 많이 보인 반면, IIS+ASP.NET의 조합은 잘 버텨냈다..
geek이나 hacker 수준의 실력을 갖춰 세밀한 튜닝을 해야 Tomcat이 성능을 발휘한다면 (물론, 그렇게 하면 최상의 성능을 발휘할 것이라 믿어 의심치 않는다..) 하지만, 그런 정보가 공개되어 있지 않은 상태에서 Tomcat은 좋은데 니가 몰라서 그런거야.. 라면.. 별 수 없다.. 그걸 알기 전까지는 Tomcat 별로라고 안쓰며, 한편으로는 성능을 내기 위한 자료 열심히 찾아보는 수 밖에.. 영어를 잘 못해 그런가.. 암튼, Tomcat의 성능 최대화 세팅을 위한 정보는 찾기가 쉽지 않다.. 뭐, 그래도 계속 더 찾아보는 수 밖에..
하긴, 몰라서 제대로 사용할 줄 모르는 것인데 톰캣 욕하고 있어봐야 해결될 것은 없다.. 하지만, 몰라서 그런지 몰라도 성능을 내기 위한 세부 세팅에 대한 가이드 라인 정보를 구하는 것도 쉽지 않다.. 노력 없이 문제해결을 하려는 날로 먹을 속셈.. 맞다.. 하지만, 공개된 정보들도 보면 남들은 이렇게 성능 냈다더라는 정보 말고는 구체적인 도움을 받을 만한 정보는 없는 것 같다.. 물론, 이것도 내 검색 실력이 부족한 탓이리라.. 다른 프로젝트에서는 톰캣을 잘 활용하기 위해서라도 정보 수집을 해봐야겠다..
옛날에 올린 글인데, 의외로 아직까지 매일 히트수가 좀 되네요..
아직도 딱히 효율적인 튜닝 지식을 얻지 못해, 성능이 중요한 상황에서는 윈도우+아파치+톰캣 조합은 사용하지 않기로 했습니다.. 리눅스+아차피+톰캣 조합이 특별한 튜닝을 하지 않아도 괜찮은 성능이 나오는 반면, 윈도우상에서는 저 같은 초보는 성능 이끌어 내는 것이 쉽지 않은 것 같습니다.. 분명 잘 사용하시는 분들도 계실텐데.. 관련된 튜닝서적이나 정보들을 모으면 다시 점검을 해봐야겠습니다.. 언제나 그럴 시간이 날지는 모르겠습니다만..
솔직히.. 국내 SI 상황만 아니면.. 리눅스에선 PHP로, 윈도우에서는 ASP나 ASP.NET으로 개발하고 싶습니다.. 전 개인적으로 솔직히 동일한 스펙의 H/W라면 자바가 가장 느리다고 생각합니다.. 하지만, 엄청난 차이가 나진 않을 것이니 중요치 않구요, 윈도우에서 톰캣 돌려야 하는 상황이 생각보다 많다는게 아쉽지만, 현실이구요.. 맘 같아선 톰캣은 개발자 개인 개발용으로만 쓰고 싶지만, 현실은 그렇지 않으니..
뭐, 경험과 실력이 미천한.. 그래서 그냥 별다른 튜닝 없이도 어느 정도 성능 나오주길 기대한 허접 톰캣 사용자의 넋두리라고 보심 되겠습니다.. ㅋㅋㅋ
작년에 진행했던 프로젝트 중에 12대의 서버에 Tomcat을 설치해 진행했던 프로젝트가 있다.. 최대 접속자를 늘리기 위해 여러가지 세팅 값을 바꾸고 최대 성능을 낼 수 있도록 조정을 했었는데 원하는 만큼 속도가 안 나오는게 문제였다.. 우리는 Tomcat과 JSP로 충분한 속도를 낼 수 있다고 했고, 고객사에서는 IIS와 ASP.NET이 훨씬 빠르니 초기접속 및 핵심 페이지 몇개를 ASP.NET으로 바꾸자고 했다..
물론, 앞에 아파치 웹서버를 붙이면 성능에 훨씬 도움이 될 것이라는 것은 알았지만 정적 페이지들은 거의 없었고 디자인을 위한 이미지 파일들도 최소화 시켜둔 상태였다.. 하지만, 그래도 찜찜해하는 고객사 분들 때문에 이 파일들도 모두 IIS 쪽으로 돌렸다..
Windows 2003 서버 12대에 MS SQL 2000 DB 서버가 1대가 운영되었는데, 웹서버에는 IIS와 톰캣이 포트를 달리하여 모두 설치되어 있었다.. 우리는 톰캣이 어느 정도 성능을 내줄 것으로 기대를 했었다.. 아파치는 다른 어떤 웹서버에 비해서도 떨어지지 않는 성능을 보여줬지 않는가.. 톰캣 역시 제우스나 웹로직 같은 상용 WAS에 못지 않는, 혹은 떨어진다고 해도 약간 떨어지는 정도의 성능을 보여줄 것으로 기대를 했었다.. 하지만, 역시 상용 WAS 보다는 성능이 훨씬 못 미치는가 보다..
몇번의 부하 테스트를 통해 톰캣은 원하는 성능이 나오지 못함을 확인했다.. 하지만, 부하가 많이 걸릴 것으로 예상되는 몇개 페이지를 ASP.NET으로 만들어 같은 성능 테스트를 해보니 훨씬 좋게 나왔다.. Tomcat이 상용 서버만큼의 속도가 나올 것이라는 기대를 하는 것은 너무한 기대였을까? IIS + ASP.NET + Windows 2003 서버에 비해 절반 정도의 성능 밖에 안 나오다니.. 리눅스에서 돌리지 않고 윈도우에서 돌려서 그런가? 아무튼 톰캣, 왕 실망이다..
물론, 몇개 페이지만 가지고 단편적인 실험을 통해 이렇게 이야기 하는 것이 좀 무리이긴 하지만 말이다.. 언제 심심하면 Tomcat의 성능비교 자료를 함 찾아봐야겠다..
2008.04.09
댓글로 Tomcat이 그렇게 성능이 떨어지지 않는다며 정보를 주셨던 nokarma님께서 Tomcat, 정말 실망이야..? 라는 글을 통해 좀 더 구체적인 정보를 제공해주심.. 하지만, 구체적으로 Tomcat을 어떻게 튜닝 혹은 세팅값을 변경해야 하며 또는 프로그래밍시 어떤 부분들을 어떻게 하는게 좋다는 구체적인 내용을 담은 자료는 없다.. 나도, 톰캣으로 좋은 성능을 내는 사이트가 있을 것으로 생각한다.. 하지만, 나도 그렇게 하고 싶은데 어떻게 해야 하는지를 모른다는 것이다.. 반면 IIS는 특별한 튜닝 혹은 세팅 없이도 Tomcat 보다 월등한(?) 성능을 내고 있다.. 퍼포먼스 테스트는 다른 방법을 취한게 아니라 실제로 사람이 붙어서 했다.. 8천명 정도가 5~10분 사이에 일제히 들어와 사이트를 사용하는 것인데.. 톰캣은 에러나는 페이지를 많이 보인 반면, IIS+ASP.NET의 조합은 잘 버텨냈다..
geek이나 hacker 수준의 실력을 갖춰 세밀한 튜닝을 해야 Tomcat이 성능을 발휘한다면 (물론, 그렇게 하면 최상의 성능을 발휘할 것이라 믿어 의심치 않는다..) 하지만, 그런 정보가 공개되어 있지 않은 상태에서 Tomcat은 좋은데 니가 몰라서 그런거야.. 라면.. 별 수 없다.. 그걸 알기 전까지는 Tomcat 별로라고 안쓰며, 한편으로는 성능을 내기 위한 자료 열심히 찾아보는 수 밖에.. 영어를 잘 못해 그런가.. 암튼, Tomcat의 성능 최대화 세팅을 위한 정보는 찾기가 쉽지 않다.. 뭐, 그래도 계속 더 찾아보는 수 밖에..
하긴, 몰라서 제대로 사용할 줄 모르는 것인데 톰캣 욕하고 있어봐야 해결될 것은 없다.. 하지만, 몰라서 그런지 몰라도 성능을 내기 위한 세부 세팅에 대한 가이드 라인 정보를 구하는 것도 쉽지 않다.. 노력 없이 문제해결을 하려는 날로 먹을 속셈.. 맞다.. 하지만, 공개된 정보들도 보면 남들은 이렇게 성능 냈다더라는 정보 말고는 구체적인 도움을 받을 만한 정보는 없는 것 같다.. 물론, 이것도 내 검색 실력이 부족한 탓이리라.. 다른 프로젝트에서는 톰캣을 잘 활용하기 위해서라도 정보 수집을 해봐야겠다..
공유하기 버튼
|
|


![TLC - Crazysexycool [수입 재발매]](http://image.aladin.co.kr/product/626/10/coveroff/3581137143_1.jpg)


















덧글
제가 써본 것이 톰캣, 웹로직, 제우스를 써봤는데 톰캣하고 성능차이가 생각보다 꽤 납니다. 그보다 유지보수 측면에서 톰캣쪽이 정신적/육체적으로 압박이더군요 ; (특히나 납품형 프로젝트의 경우에는 더욱-_-)
웹컨테이너들이 대규모(?)가 되면 모르겠지만 어느정도 프론트 100대급 이하의 소규모에서는 php/asp... 정확히는 IIS/Apache+PHP 에 비해 성능적으로 우위점이 전혀 없었습니다.
navis님 : 음.. 해보겠습니다..
가우리언님 : 아무래도 성능차이가 많이 나는 듯 합니다..
http://tomcat.apache.org/tomcat-5.5-doc/config/index.html
찾아보면 의외로 만질 수 있는 값이 많이 있다는걸 알 수 있는데, 톰캣은 기본적으로 대충 설치해도 동작하도록 설정이 느슨하게 제공됩니다. server.xml을 열어보면 이것저것 엄청나게 많지만 대부분 예제일 뿐이죠.
튜닝의 시작은 server.xml의 필요없는 항목은 모두 제거하고 webapps 폴더 안의 필요없는 폴더도 모두 삭제한 후, Connectors의 파라마터와 Context의 파라마터를 조정해 가면서 테스트합니다.
그밖의 유의할점은 톰캣은 단일 jvm process에서 동작하는데 OS에는 한 process에서 open할 수 있는 file의 수나 thread 수, 사용할 수 있는 메모리 등에 제한이 있어서 튜닝값을 그 이상으로 올려도 의미가 없습니다. 단순히 CPU 사용량만 보고 과다하게 높여잡은 파라마터가 오히려 퍼포먼스를 깍아먹는 경우도 있었습니다.
한 process에 요구되는 부하가 클 경우 아파치나 IIS 등과 AJP로 연동해서 한 서버에서 톰캣을 2개 이상 띄우는 것도 괜찮은 선택입니다. 시스템의 효율은 높아지지만 단점은 데이터 이동 경로가 길어집니다. 그래도 이 선택이 더 나을 경우도 있습니다.
프로그래밍시 주의할 점이라면.. 너무 많아서 이미 책이 나와있을 정도라 생략하고 가끔은 프레임웍을 안쓰고 날코딩으로 하는게 더 빠를 때도 있습니다. (아마 유지보수는 지옥이 될 가능성이 있겠지만요.)
마지막으로 IIS 같은 경우는 약간 반칙이 있는데, IOCP 같은 공개된 기능 말고도 다른 일부 기능이 커널 레벨에서 동작한다고 들은 적이 있습니다. 그래서 윈도우 서버가 있고 ASP 계열 개발자가 있고 어플리케이션 요구사항이 '유닉스 서버를 도입할지도 모르니 대비해 주세요'라고 하는 경우가 아니라면 그냥 그 환경을 이용하는게 최선입니다.
aromi님 : 문서를 뒤져가며 테스트라.. 흠.. 그게 쉽지가 않은 어려움이 좀 있습니다.. 매일 항상 사용하는 시스템이 아니라서리.. 한번 사용할때 왕창 붙고, 한동안 사용 안하다 사용하고 이래서, 테스트할때 인력동원한 내용을 가지고 시스템 설정을 바꿔가며 최적치를 찾아내는게 쉽지 않습니다.. 어느 정도 최적화된 수치값 등이 공개된게 있으면 큰 도움이 될 것 같습니다..
MS Windows server, IIS, ASP.NET, SQL*Server는 이미 그 조합으로 end-to-end 튜닝되어서 나오는 종합 선물 세트나 마찬가지라고 봅니다.
실전에서 Apache/Tomcat을 Windows server, IIS, SQL*Server와 쓴 예는 본적이 없는것 같군요.
tomcat 기반 production 시스템은 거의 epoll 지원하는 Linux 2.6 64bit version에 Apache, Tomcat, 64bit JVM에 오라클 씁니다. 이 조합 경험 전문가는 쉽게 구할수 있습니다만. Windows, IIS, Tomcat, SQL*Server 조합 경험 전문가는 별로 구하기 쉽지 않을것 같군요. 한국은 또 다를수도 있겠습니다만.
IIS, Tomcat, SQL*Server쓰는 경우에는 IIS와 tomcat 연결 시켜주는 component가 병목일수도 있고, tomcat 자체 설정이 문제일수도 있고, JVM설정이 문제일수도 있고, database connection pool이 병목일수도 있고, SQL*Server JDBC driver가 문제일수도 있습니다. 사람 7,8천명이 실제로 로드테스트한다는 경우는 처음 들어보네요. 확실히 한국은 사람값이 싸다는 생각이 드는군요. consistent하게 로드테스트 결과 비교하려면 이것도 툴써서 전문가에게 시켜야 될 일입니다. 성능이 일정수준에 달할때까지 반복해서 돌리면서 병목을 찾아 제거해야 되거든요.
그리고 로드테스트 시나리오도 여러가지로 변경하면서 해야되구요.
램프업 타임은 제외해줘야 되고, 특정 시나리오의 목표 피크로드에서 어느정도 버텨줘야 된다는 계획에 부합하는 로드를 생성시켜서 테스트해야 합니다.
한마디로 요약하면, 공부는 따로하시고 프로젝트에서는 전문가 시키세요.
페이지 소개해야할 것 같습니다.
테스트 과정은 개발중에는 특정시간에 사이트로 몇초간격을 두고 접속해보는 프로그램을 작성해 내려보내서 합니다.. 인프라가 되니 이런건 편하더군요..
실제로 사람이 붙어서 테스트를 하는 것은 사실 시스템 테스트 보다는 사람들에게 시험보는 환경을 경험시키고, 직무평가의 중요성을 알리기 위해서 하더군요.. 개발하는 입장에서는 고맙지요.. 연수원에 들어가 보던 시험을 온라인평가로 대치하는 과정이라 가능한 일이지요.. 한국이 사람값 싸서 가능한 일은 아닙니다.. 국내의 큰 은행 직원들인데, 싼 인력이 아니지요..
kenu님 : nokarma님이 좋은 정보 많이 주셨지요~ ^^
MS에서 제공하는 JDBC 드라이버는.. 은근히 심각한 성능상의 문제가 있습니다.. ;;
그냥 jTDS 쓰시는 것 추천..
특히 DB 서버를... MS-SQL을 쓰신다면... 그냥 ASP.NET 쪽이 성능이 나을 가능성이 높죠.. 별다른 설정 안해줘도 잘 나오고..
대형 은행 정도 되는 조직이면 이미 내부 web 어플리케이션 load test팀이 있거나, 주로 거래하고 있는 외부 로드테스트 서비스 업체가 있는게 정상이구요.
Mercury Interactive같은데서 이런 서비스를 지원을 했었는데, HP로 합병되었으니 HP쪽을 컨택하면 어떤식으로 로드테스트 해야하는지에 관한 정보를 얻을수 있을겁니다.
Sun의 제품을 사용했다면, Client JVM 방식이 아니라 Server JVM 방식으로 설정하고.. GC 알고리즘을 수정한 뒤에, JVM 힙 영역의 크기 같은 것도 조절해 주신 뒤에 비교하셔야 합니다.
그리고 코드 측면에서 미친 병아리님께서 작성한 코드가 ASP.NET과 JSP에서 동일한 코드라고 볼 수가 없습니다. 동일한 동작을 하는 응용 프로그램을 interface로 추상화 해서 설계를 마친 후에 구현만 ASP.NET, JSP 이렇게 따로 해서 비교를 하는 것이 어떨런지요.
객체 그래프에 참여하는 인스턴스가 상이하고, 구동 되는 가상 머신의 GC 알고리즘 방식 등이 다른데다가 정량적인 판단을 할 수 있는 동일한 클라이언트가 아닌 메뉴얼 방식의 승인 테스트(Acceptance Test) 방식으로 테스트한 것으로 Tomcat을 판단하면 신뢰도가 떨어지는 테스트가 됩니다.
톰캣은 약간의 성능향상을 할 수 있게 JNI 방식의 DLL도 지원합니다. 이것도 마찬가지로 추가를 해주셔야 합니다.
만약 정확한 비교를 원하시면 JSP와 ASP.NET 쪽 코드를 공개해 주시는 것도..(모든 코드가 아니라 부하가 심했던 부분만이라도..) 괜찮을 듯 합니다.
톰캣은 설정을 좀 해야해설^^;;
보통 성능 문제는 infrastructure쪽 보다는 application에서 더 많이 생깁니다.
ASP.NET 쪽 구현한 사람과 Java쪽 구현한 사람의 optimal한 시스템 구현 스킬이 비슷해야 공정하게 비교할 수 있는 코드가 나옵니다.
nokarma님 : 맞습니다.. 하지만, 국내 SI에서 그런 전문가에 대한 비용을 확보하면서 제대로 프로젝트 할 수 있는 PM이 몇이나 될까 하는 생각도 듭니다.. 상황이 이런데도 해보겠다고 하는 내가 바보 아닐까 하는 생각도 가끔 합니다..
임은천님 : 사이트의 모든 기능을 JSP와 ASP.NET, 모두 구현한 것은 아니고 특정 몇 페이지만 작성했습니다.. 정확히 3개 페이지 이며, 정확한 테스트를 위해 다른 준비를 할 만큼 복잡한 페이지도 아니며 단순히 리스트 뿌려주는게 전부입니다.. 따라서 개발자의 능력에 따라 성능이 차이날 페이지도 아니지요.. 소스코드를 공개하는 것이 이 논의를 진행하는데 얼마나 도움이 될 지 모르겠지만, 조만간 가장 비교가 되는 한 페이지를 정리를 해서 올려보도록 하지요..
하지만, 제가 이야기 하고자 했던 핵심은 톰캣의 경우 이래 저래 신경을 많이 써야 성능이 나오는 반면, IIS는 별다른 설정 없이도 일정 성능이 나온다는 것이었습니다.. 제 글의 제목이 낚시성이라 문제가 되었던 것 같습니다..
mangdee님 : 설정을 좀이 아니라.. 많이 해야하는 것 같다..
nokrma님 : 정확히 쿼리 하나 날리고, 리스트 뿌려주는 페이지라 큰 차이는 없을 것 같습니다.. 쿼리도 거의 비슷한 실행속도와 거의 차이가 없는 쿼리문 실행이라 개발자의 스킬 때문일 가능성은 거의 없다고 생각합니다..
아파치, 톰켓은 리눅스에서 돌려야 제대로 성능이 나옵니다. 자바 어플리케이션을 윈도우에서 돌리면 절대 성능 안나오죠.... 부탁하건데 리눅스에서 테스트 해보세요....
아파치 웹 서버도 윈도우에서는 사용하지 말라는 이야기도 많더군요..
만약, 사실이라면 좀 안타깝습니다.. 자바로 개발한 이유가 사실은 양쪽에서 모두 돌리고 싶어서였는데요.. ㅎㅎㅎ
도움이 필요하게되면 연락 한번 드리겠습니다..
많이 많이 참고하셔요.. ^^
WAS 대부분의 렉은 DB에서 걸립니다.
DB 풀이나, JDBC 커넥터, DB 입출력 소스에서 close 안한 부분은 없는지 등 점검해 보시기 바랍니다.