我正在尝试为我的应用程序分析一些API请求，以便隔离任何潜在的瓶颈 . 但是，我看到我的日志记录的一部分略有差异，所以我试图确保我没有遗漏任何东西 .
The Basic Setup
-
AWS Classic ELB（已启用交叉区域）
-
余额为2个AWS t2.micro实例（临时服务器）
-
ec2框正在运行PHP 7.1和Nginx .
-
有一个SSL证书，但它终止于ELB . 所以ELB通过端口80上的http连接到后端实例
-
实例位于私有子网中，并通过NAT网关连接到Internet
Gathering Data
-
我有请求时间被记录在应用程序本身，这些请求被发送到Loggly（因此一旦请求到达应用程序代码，我们得到一个开始时间，一旦响应已经发送到应用程序，我们得到一个结束时间）
-
AWS ELB访问日志
-
CURL请求启用
total_time的给定 endpoints
The Results (for a given endpoint)
-
申请请求时间
-
我看到应用程序请求时间为 0.05-0.08 秒 . 这是发送给Loggly的数据
-
AWS ELB访问日志
-
这些日志提供3个数字：
-
请求处理时间： 0.00004 seconds
-
后端处理时间： 0.05 - 0.09 seconds
-
响应处理时间： 0.00004 seconds
-
CURL
-
现在，运行一个看起来大致如下的CURL命令：
curl -s -w "%{time_total}\n" -o /dev/null www.google.com
我收到了 total_time 的结果： ~ 0.17 - .5 seconds
因此，似乎应用程序日志和ELB访问日志显示类似的结果 . 但是，似乎通过CURL的整体请求时间，可以 ~ 3x - 6x slower
如果是这样的话，可能会导致什么？我的第一个想法是，它需要时间来连接到ELB，或者我们可能会对DNS解析感到不满 .
然后，我尝试使用Apache Benchmark进行一些基本测试，这似乎证实了某种连接问题 . 连接结果为** ~0.07 - 0.5秒**
但是，由于那些时间没有出现在AWS ELB访问日志中，我被引导相信这与DNS解析有关吗？如果是这样，我该如何进一步调查？
目前，我的域名在LiquidWeb上注册，并且具有指向AWS提供的ELB DNS名称的CNAME记录