私が働いている会社は通常インターネット接続が非常に高速ですが、Webページにアクセスするたびに時間がかかります。私はこれをブラウザで分析し、それが私にボトルネックがあることを知らせましたWaiting (TTFB)。これはdnsmasq私がドメインから適切なIPアドレスにルーティングするために使用したという事実に関連しているかもしれませんが、hostname.devそうではありません。接続プロセスのこの部分をどこで分析するのか、問題を解決するのかわかりません。どうすればいいですか？
ちなみに私はUbuntu 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の場合、時間は数ミリ秒以下であると仮定します。
結果が良く見える場合は、実際のネットワークをテストします。まず、ドメイン接続に時間がかかりすぎるかどうかを確認してください。ドメインにpingを送信し、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の出力は、接続を分析し、コンピュータからサーバーへのパスのどの部分が最も待ち時間を引き起こすかを判断するのに役立ちます。
pingの出力が良く見える場合は、サーバーが応答を再送信するのに時間がかかりすぎていることを確認してください。努力する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]
出力は特定のポイントで長時間一時停止されますか？その場合、このステップが遅延の原因であるに違いありません。