We发出了很多HTTP请求.最近,我们开始考虑在操作系统级别进行优化,以便从单个机器发出更多请求.
为了检查我们的操作系统的性能,我创建了一个小基准来比较不同机器上的东西.
基准测试使用curl -w：
- #!/bin/bash
- for (( ; ; ))
- do
- curl $URL -o /dev/null -s -w "SIZE: %{size_download} SPEED: %{speed_download} LOOKUP: %{time_namelookup} CONNECT: %{time_connect} START: %{time_starttransfer} TOTAL: %{time_total}\n"
- done
现在我为1个单一的URL运行它.结果如下：
从我的本地开发机器(与光纤连接)：
- SPEED (b/sec) LOOKUP CONNECT START TOTAL
- 13,331.2481 0.0022 0.0228 0.2163 0.2175
在我们的一个生产服务器上(使用XEN虚拟化),结果略有不同：
- SPEED (b/sec) LOOKUP CONNECT START TOTAL
- 22,764.7700 0.0093 0.0455 0.1318 0.1334
在另一个不相关的服务器上,没有XEN虚拟化(不同的数据中心,不同的大陆,远离资源)
- SPEED (b/sec) LOOKUP CONNECT START TOTAL
- 32,821.3569 0.0004 0.0080 0.1608 0.1672
正如您所看到的,我们的生产服务器上的性能远远不能令人满意.数据传输速率比我的本地笔记本电脑更快,但是延迟正在扼杀我们.由于我们获取大小相当小的HTTP资源,因此我们需要优化此延迟.
知道从哪里开始？
更新：这不是关于扩展Web服务器.这是关于扩展Web请求.
解决方法
这是一个研究得很好的问题(“高性能网络爬行”),有大量可用的研究：
http://scholar.google.com/scholar?q=web+crawling+performance …是的,我在作弊,但老实说,你应该首先阅读文献.
根据我自己过去构建此类系统的经验：你无法击败光速,所以不管怎样,你都会遇到它.您可以做的是优化计划资源提取的方式和时间.例如,您可以使用优化的子系统来处理问题的某些部分 – 例如DNS解析.您可以预先解析名称并直接连接到IP地址(只需添加正确的主机标头).之后,您将不得不承担TCP连接成本,无法绕过它.也就是说,如果您对同一主机有多个请求,那么您可以利用它来通过现有连接序列化多个请求：这有助于分摊TCP / TLS握手成本并为您提供更好的端到端性能.从那里开始,你必须向上移动协议阶梯：有时你可以跟踪重定向链并记住最后一个位置,以便在将来跳过额外的重定向(只需要一个后备).实际上,同样适用于DNS.您可以实施乐观策略并直接连接到IP,然后在失败时使用回退.对于TLS,您可以存储会话票证和其他元数据以获得更快的重新连接(即,假设您经常重新连接).
tl;博士：我没有在这里添加任何新内容,所有上述提示(以及更多内容)都包含在现有研究中.拿一杯咖啡,花一些时间阅读现有的论文！
