track服务优化之二HTTP

首先我们要了解track服务的特征。

一般互联网广告公司的代码都是嵌入在客户网站中的部分页面,而这些代码的体积也不会很大,因此针对这个特征我们就需要进行对应的http server的优化。

keepalive: 在很多教程中都是推荐开启keepalive,这样可以复用连接,但是在track的http server中还是建议关闭吧,毕竟很多用户连接你的服务器很长时间内只会一次的,你开启了keepalive就会造成很多的无效连接。

TCP_NODELAY: 由于track代码一般都比较小,经常只有几百个字节,而默认tcp会开启nagle算法,这个算法是鼓励发送全尺寸的的数据段,而我们的track代码可能无法填充满一个分组,于是导致等待的延时。有时候会有100ms到200ms的延时。 如果你的track代码大于1500个字节的话,那也可以开启这个算法。

Connection header: 在http的头部中有个connection的部分, 由于一般track代码只运行一次,运行完成我们就需要尽快关闭连接,所以在connection头部返回的时候我们直接变成 Connection: close以此来尽快关闭连接。

增加缓存时间: 由于很多track code不会经常经常进行更改,所以为了避免每次都下载,可以增加相应的过期时间。

开启sendfile: 这个就现在http server基本都是默认开启的。原因就是省去在内核空间和用户空间进行切换了。

这篇文章写的有点干巴巴,没啥营养,基本上都是一些nginx http server的设置吧。 下一篇关于tcp部分的要好好写了。也算是看完tcp/ip详解卷一的一个总结吧。

track服务优化

track服务优化之一 : DNS和域名

在互联网广告公司里,有一些服务是用作跟踪用户的,而这些代码嵌入的不多,qps也不高,然后文件大小也比较小,对于这样的应用我们如何进行优化呢。

我们http请求第一步开始说起。

大部分的http请求都是通过dns来进行的,这样dns解析的速度也关系到整个访问的速度。 下图中我们可以很明显的看到,这个请求最大的2个部分就是dns和内容下载。

14142519581_cde92247c1_z.jpg

我们知道DNS的缓存时间都由DNS设置TTL时间来决定的(除了部分local dns做强制缓存),而当一个域名在local dns中没有缓存时,local dns就会以迭代的方式去查询这个域名的解析。比如我们通过trace来模拟一个本地没有缓存的迭代过程。

下面是我们解析www.sohu.com的一个例子。 我们可以看到这里,首先是找到根域名的服务器,然后找到所有.com域名的根服务器,然后找到sohu.com域名的根服务器,然后解析了www.sohu.com, 而由于www.sohu.com做了一次cname,所以要进行解析,最终得到对应的IP地址。

而这个过程中,我们发现实际去dns.sohu.com的时间才52ms,而他去到根域名服务器和.com根域的解析时间加起来要452ms,而这个时间都是算在整个请求的时间内的。

14142949292_3223302e28_z.jpg

从上可以看到加快DNS解析速度的重要性,而在local dns中缓存是重重之重。而这个第一步就是统一域名,发现国内某些广告商居然用好多域名来进行跟踪。而google却只用了一个单独域名来进行。

下图是我直接访问这家广告公司的跟踪域名,可以看到光dns解析的时间就903ms,这个还是他们使用了dnspod的服务器的情况下。
14142949232_ddcb4b2a20_c.jpg

而他们的很多广告都使用了不同的域名,不过经过查询是应该用了泛域名解析。但是实际dns请求的时候还是会有延迟啊,local dns可不管是不是泛域名呢。 而这家广告商的这些域名指向最终都是同一个IP,那为什么不用单个域名呢?
14165904063_24dcd230ba_z.jpg

而我们看google ga,所有的ga使用的域名都是同一个。这样从dns层面减少了响应的时间。
14142519561_8ec892a088_c.jpg

从上面我们得到,使用单一域名在dns层面的好处是比较大的。

加快DNS解析速度的另外一个因素就是TTL时间。这个从解析速度来看自然是越大越好,比如很多根域名服务器都是缓存1周的,但是我们看到大量的还是缓存1个小时的。毕竟时间放太长,一旦网络出了问题都没办法切换。所以有些请求量很大的域名的ttl时间都是120秒左右的,就是怕万一有问题来不及切换。

这个就没有绝对的要求,全看各自的dns服务器的分布和性能了。