제가 일하는 회사는 보통 인터넷 연결이 매우 빠른데, 웹페이지를 방문할 때마다 시간이 오래 걸립니다. 나는 이것을 브라우저에서 분석해 보았고 그것이 나에게 병목 현상이 있다는 것을 알려주었습니다 Waiting (TTFB). 이것은 dnsmasq내가 도메인에서 적절한 IP 주소로 나를 라우팅하는 데 사용했다는 사실과 관련이 있을 수 있지만 hostname.dev그렇지 않습니다. 연결 프로세스의 이 부분을 어디에서 분석하거나 문제를 해결해야 할지 모릅니다. 어떻게 해야 하나요?
참고로 저는 우분투 15.04를 사용하고 있습니다.
답변1
느린 페이지 로드 시간으로 인한 일반적인 병목 현상은 일반적으로 DNS 확인입니다. DNS를 확인하는 데 걸리는 시간을 테스트하려면 를 사용해 보세요 dig(1).
$ dig example.com
그러면 아래와 같은 출력이 제공됩니다.
; <<>> DiG 9.10.2-P1 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13362
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 1 IN A 93.184.216.34
;; Query time: 3 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Thu Jun 18 23:19:24 IST 2015
;; MSG SIZE rcvd: 45
마지막 부분을 보셨나요? DNS를 해결하는 데 소요된 시간을 보여줍니다. dnsmasq의 경우 시간은 몇 밀리초 이하라고 가정합니다.
결과가 좋아 보인다면 이제 실제 네트워크를 테스트할 차례입니다. 먼저 도메인 연결에 시간이 너무 오래 걸리는지 확인하세요. 도메인에 핑을 보내고 RTT 시간을 살펴보세요. rtt가 너무 크면 연결 대기 시간이 원인일 수 있습니다.
$ ping -c 5 example.com
PING example.com (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34: icmp_seq=1 ttl=51 time=204 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=51 time=205 ms
64 bytes from 93.184.216.34: icmp_seq=3 ttl=51 time=206 ms
64 bytes from 93.184.216.34: icmp_seq=4 ttl=51 time=205 ms
64 bytes from 93.184.216.34: icmp_seq=5 ttl=51 time=205 ms
--- example.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 204.315/205.415/206.755/0.785 ms
이것이 1초 이상이라면 확실히 연결 병목 현상이 있는 것입니다.
출력에 문제가 있는 경우 ping(1)더 나은 구문 분석 연결을 사용해 볼 수 있습니다 traceroute(1).
Traceroute의 출력은 연결을 분석하고 컴퓨터에서 서버까지의 경로 중 어느 부분이 가장 많은 대기 시간을 유발하는지 확인하는 데 도움이 됩니다.
핑 출력이 양호해 보이면 서버가 응답을 다시 보내는 데 너무 많은 시간이 걸리는지 확인하세요. 노력하다wget(1)
$ wget -d example.com
DEBUG output created by Wget 1.16.3.60-fd3a-dirty on linux-gnu.
URI encoding = ‘UTF-8’
--2015-06-18 23:27:55-- http://example.com/
Resolving example.com (example.com)... 93.184.216.34, 2606:2800:220:1:248:1893:25c8:1946
Caching example.com => 93.184.216.34 2606:2800:220:1:248:1893:25c8:1946
Connecting to example.com (example.com)|93.184.216.34|:80... connected.
Created socket 4.
Releasing 0x0000000001afc8d0 (new refcount 1).
---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.16.3.60-fd3a-dirty (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: example.com
Connection: Keep-Alive
---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=604800
Content-Type: text/html
Date: Thu, 18 Jun 2015 17:57:56 GMT
Etag: "359670651"
Expires: Thu, 25 Jun 2015 17:57:56 GMT
Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT
Server: ECS (ewr/15BD)
X-Cache: HIT
x-ec-custom-error: 1
Content-Length: 1270
---response end---
200 OK
Registered socket 4 for persistent reuse.
Length: 1270 (1.2K) [text/html]
Saving to: ‘index.html’
index.html 100%[==========================================================================>] 1.24K --.-KB/s in 0s
2015-06-18 23:27:56 (197 MB/s) - ‘index.html’ saved [1270/1270]
출력이 특정 지점에서 오랫동안 일시 중지됩니까? 그렇다면 이 단계가 지연의 원인임에 틀림없습니다.