공지사항을 보면 실무자들은 문제가 무엇인지 정확히 파악하지 않은 상태로 생각하구요.
그런데, 문제를 정확히 파악하지 못했으면서 두 번의 점검 내지는 업그레이드를 한 것 같군요.
프로그래머가 가장 피해야할 상황이 “짐작에 의한 디버그”입니다.
디버그 한다고 뭔가 했는데 그게 상황을 더 악화시키기도 하고, 그로 인해서 디버그를 더 힘들게 만들거든요.
문제 인자가 하나뿐이었을 수 있는데, 두세개로 쉽게 늘어나죠.
로그 찍을때 한 명당 작업 시퀀스 별로 경과 시간 찍어보세요.
단, 로그를 절대 하드디스크에 직접 기록하면 안됩니다.
IO작업은 많으면 많을 수록 서버가 뻗어버릴 정도로 부하가 걸리기 때문에,
다른 컴퓨터에 작업 시퀀스별로 분리해서 UDP로 쏘세요.
크게 문제가 될 부분을 분리해보자면,
1) 웹서버 URI 접근
2) DB서버 SQL 접근
3) 메모리 또는 IO의 각종 자원 할당 해제
4) 예외 처리
정도일텐데 어쨌든 각각 다른 컴퓨터로 분리해서 UDP로 보내야,
많은 접속자를 처리하고 있는 동안에 부하가 걸리지 않습니다.
물론 받는 컴퓨터에서는 UDP를 받아서 각각 로그를 기록해야죠.
단위 접속당 시간이 많이 걸리는 과정이, 저기서 최소 한 곳은 있을 거고,
지금 상황에서 보면 두 곳 이상일 가능성도 있습니다.
그 다음에 문제가 된 부분을 다시 3~4부분으로 쪼개서 경과 시간을 찍어보면,
대충 어디가 문제인지 나올겁니다.
그리고 아무리 급하고 답답해도,
문제를 해결하려고 뭔지도 모르고 짐작해서 뭘 작업한다거나,
문제를 인식했다고 하더라도 해당 루틴의 버그만 수정하지 않고,
루틴을 재작성 하려는 삽질은 안했으면 합니다.
경력자라고 으시대는 사람들도 정작 문제 해결할 생각은 안하고,
저 짓거리 해서 서버 망치는 사람 많이 봤습니다.
도움이 되었으면 하네요.
찬성: 
반대: 
Rainin
윈드윙
Comment ' 7