서버 속도 고찰 - Githubissues

게임 화면이 하도 지연이 나서 확인할 수 있는 수단을 정리함.

로그캣 안드로이드 스튜디오만으로 확인 가능한 가장 간편한 방법. 로그캣으로 glide라고 필터링만 해도 Finished loading GifDrawable from LOCAL for 2131099760 with size [1440x2308] in 3153.82337 ms 같은 형태의 문구가 출력됨. 아무래도 해상도가 큰 탓인지 지연이 크다. 이미지 조절이 시급함. 이 외에도 remotejava로 필터링하면 실제 웹 요청에 얼마가 걸렸는지 확인할 수 있다.
웹 프록시 Fiddler라는 프로그램이 있는데, 안드로이드 와이파이 설정에서 프록시로 피들러 서비스 포트로 설정하면 웹 트래픽을 전부 감시 가능. 다만 설정이 꽤 복잡하니 여기엔 적지 않음. 아래처럼 보임.

GET http://landmarks-coms.herokuapp.com/picture/22 HTTP/1.1
ACTUAL PERFORMANCE
--------------
ClientConnected:    23:36:43.346
ClientBeginRequest: 23:37:16.157
GotRequestHeaders:  23:37:16.157
ClientDoneRequest:  23:37:16.157
Determine Gateway:  0ms
DNS Lookup:         0ms
TCP/IP Connect: 0ms
HTTPS Handshake:    0ms
ServerConnected:    23:36:43.854
FiddlerBeginRequest:    23:37:16.157
ServerGotRequest:   23:37:16.157
ServerBeginResponse:    23:37:16.512
GotResponseHeaders: 23:37:16.512
ServerDoneResponse: 23:37:25.782
ClientBeginResponse:    23:37:25.784
ClientDoneResponse: 23:37:25.786

    Overall Elapsed:    0:00:09.628

서버 로그 역시 나만 볼 수 있음.

2018-10-13T14:37:15.340610+00:00 heroku[router]: at=info method=GET path="/picture/22" host=landmarks-coms.herokuapp.com request_id=31fcd512-b88d-4146-939f-e1dff075a532 fwd="61.102.227.254" dyno=web.1 connect=1ms service=75ms status=200 bytes=404152 protocol=http
2018-10-13T14:37:15.295697+00:00 app[web.1]: 14:37:15.295 [nettyCallPool-4-4] DEBUG Exposed - SELECT pictures.id, pictures.filename, pictures.file, pictures.width, pictures.height, pictures.thumbnail1, pictures.thumbnail2, pictures.thumbnail3, pictures.thumbnail4, pictures."owner", pictures.address, pictures.latit, pictures.longi, pictures.created, pictures.public FROM pictures WHERE ((pictures.public = true) OR (pictures."owner" = 2)) and pictures.id = 22
2018-10-13T14:37:15.298508+00:00 app[web.1]: 14:37:15.298 [nettyCallPool-4-4] INFO Exposed - transaction taken 0.029s
2018-10-13T14:37:15.326781+00:00 app[web.1]: 14:37:15.326 [nettyCallPool-4-4] INFO ktor.application - 0.057s: /picture/22

몹시 혼란함. 실제로 9초가 걸렸는데 서버에선 1초도 안 걸렸다고 하는 중.

대충 예상되는 건 서버 수치는 헤더 전송만 체크하고 바디 전송은 무시한다는 점. 즉 헤더를 보낼 때까지만 두고 볼 때는 2초를 거의 넘기지 않음. 결국 사진 용량이 문제가 되고 섬네일 적용이 시급할 듯.

지연을 정리하자면 서버 처리 + 전송 + 클라 처리 + Glide 처리 네 가지로 볼 수 있음. 글라이드 처리도 무시 못하니 주의할 것.

테스트하면서 예상하는 바는 시연을 여러번 하다보면 캐시가 쌓여서 JSON 수신 시 느리고 사진을 빨리 가져올 듯 함. 로딩화면이 중요해질 듯.

jeiea / landmarks-client

서버 속도 고찰 #11