IIS HTTP Err Log 중 Connection_Dropped 오류

HTTP 에러 로그 중 Connection_Dropped는 자칫 IIS서버 문제로 인식하여 서버에 중점을 두고 튜닝을 하는 경우가 많다.

이 경우는 클라이언트 문제다.

 

Connection_Dropped

The connection between the client and the server was closed before the server could send its final response packet. The most common cause of this behavior is that the client prematurely closes its connection to the server.

서버가 최종 응답 패킷을 전송하기 전에 클라이언트와 서버 간 연결이 닫혔습니다. 이 동작의 가장 일반적인 원인은 클라이언트가 서버와의 연결을 미리 닫는 것입니다.

클라이언트가 서버와의 연결을 미리 닫는 문제.

 

대형 서비스를 운영하며

최근들어 피크타임에 Connection_Dropped 에러가 다량 늘어나는걸 발견했고,

주로 안드로이드폰 모바일 웹에서 페이지로딩 실패가 아주 빈번해졌다. (신기하게 아이폰에선 별로.브라우저의 차이인가)

250만 회원의 VOC는 불보듯 뻔했고 끌려갈 이러다 갑에게 끌려갈만한 일만 남았다는 참혹한 현실이 머리를 괴롭혔다.

 

그래서 먼저,

소스상에서 리소스 반환이 되지 않을 부분을 찾아 일일히 모니터링 --> 문제 없음.

https 방식 처리가 과다한것 같아 http로 처리 --> 뱐화 없음.

 

구글링을 해도 Connection_Dropped의 정확한 응답을 들을 수 없어,

지속적 소스 수정과 튜닝을 하던끝에...

 

원인을 발견했다.

바로

Set objXmlHttp  = Server.CreateObject("Msxml2.ServerXMLHTTP.3.0")
objXmlHttp.setTimeouts 1000000, 1000000, 1000000, 1000000

이런 코딩을... 비동기 처리 부분에 타임아웃을 백만밀리세컨드로...

저렇게 처리를 하니

평소에는 문제가 없다가 피크타임에 렉이 걸릴 때 도화선으로 작용을 한 것. 누구냐!! 소스 코딩 Copy And Paste가 만들어낸 참사.

전체 소스를 찾아 모두

xmlhttp.setTimeouts 5000, 60000, 10000, 10000

형태로 수정처리 후 모니터링. 아직은 문제가 없다. 점심시간이라 피크타임인데 오류로그가 없다.

피크타임에 tcp 커넥션 중 w3p가 250가량 되었는데 현재는 60정도.

새해에 끌려나갈일이 없어진것 같은데 아직 모니터링이 필요하다.

 

목요일경 L4에서 제외시켜놓은 서버도 한대 더 붙으니 숨통이 트일듯하다.