标签归档:trafficserver

CDN缓存服务器现状,squid、nginx、trafficserver、ATS性能测试

今天谈一个问题,目前cache软件在业界的使用现状。cache系统其实最大的使用场景,还是主要集中在CDN厂商里。

大概在2010年之前,各大CDN厂商基本清一色的使用squid。那时候的squid是绝对的主力。

squid的作为cache领域的鼻祖,正是由于历史的久远,很多近10年左右流行起来的很多系统特性,它本身并不支持。比如sendfile,splice和多核等方面的支持,由于这些特性属于核心架构方面的功能,后期如果想引进的话,需要对squid的核心做大量的修改。对于CDN厂商来说,稳定性是大于性能上的考量的。所以在面临业务增长的性能压力之下,几乎各个厂商内部的cache团队都要去忍痛,咬着牙去做这些大伤元气的改造。

就拿多核的支持来说,因为squid本身是单进程架构,基本上大家的处理方式就是起多实例,所谓的多实例,就是启动多个squid,通过这样的方式让它可以起到多进程的效果。(心好累

当然除了squid之外,还有一个比较新的cache,就是varnish。varnish的作者曾经在自己的博客上批评过squid中很多过时的思想。宣称自己的性能和架构要比squid强大很多。但是作为一个只支持内存的缓存系统(有可以持久化的外围手段),使用的场景是有限的。目前使用varnish的,都是一些小站,或者说热点很集中,缓存总量不大的业务场景。在前几年,我了解到新浪微博有在用它。

随着nginx的崛起,cache领域里也有了它的身影。nginx的proxy_cache功能就是为cache而设计的。关于nginx的cache功能上的一些设计,前面的系列文章里花了不少的篇幅去讲。但是要想作为一个专业的cache,nginx还有很长的路要走。新浪在2010年左右,曾经针对nginx的cache中的不足,专门开发了cache模块来来作为补充,并且开源了,名字就ncache,不过这个项目估计早就死掉了。

2009年,apache trafficserver开源。这个事件,我认为应该是cache领域的重大转折。关于trafficserver,这里有个插曲值得一提。(后面我们简称为ATS)

ATS故事就是一个悲剧。当年03年,雅虎收购了inktomi,当时公司已经彻底把ATS相关产品、代码、资料、人员全部K掉了,资产接手工程师发现在某个角落有个机器,好多土,就问问这机器干嘛的,然后某个还在公司的老员工介绍了一下,雅虎的人还挺实在,就开机看看,发现机器是一个开发测试机器,机器里的系统还能跑,里面有一些不太齐全的代码,然后测试了一下程序,看性能比squid应该好,就把代码入库到雅虎的cvs,cvs tag名字:ts-gold。代码checkin时间,2003年6月20号左右,这就是当年的yts-1.4= i ts-1.4,是ATS的祖宗。后来,ATS发展到09年,1.17版本,砍掉50%代码后,开源出来的yts1.17就是ATS2.0版本。完全是垃圾堆捡回来的,只有一个临时的像是开发测试export出来的代码,没cvs历史,没文档。据猜测,这个机器是因为放角落,不显眼所以没被烧掉,其他能烧的都烧了。

其实有心的话,你去翻开ATS开发团队,其实跟squid是有交集的。很多在squid中不完善的功能,在trafficserver中得到了完善和强化,比如squid中的COSS文件系统,就是个公认的半成品。而在ATS中COSS的思想被发扬光大,其设计和架构让人叹为观止。

正是由于ATS的出现,很多在技术上有远见的公司和CDN厂商开始对ATS的研究和使用。就目前而言,CDN厂商里网宿和帝联已经将ATS用于了生产环境。而很多新兴的小CDN服务商或者云服务提供商也纷纷使用了ATS。蓝汛则在调研后放弃了ATS,还是抱着他们的squid不放。不过近两年,他们开始拿出一部分精力研究nginx。这个属于他们团队更替的结果,这里不做评论。

关于ATS有哪些特性,性能为什么那么强这里就不细说了。以后有机会在讨论。有一点可以提一下,对于HTTP协议的兼容性,ATS是仅次于squid。squid是目前世面上HTTP类服务器里对协议支持最全面的。nginx大概只有50%。

QQ截图20150618114600.jpg

跳出CDN厂商的圈子,我们看看在互联网公司内,cache软件的状况。大概在2010年之前,淘宝内部的cache也是主要以squid为主,后来新团队在调研过ATS之后,开始将其在cache业务上推广,大概花了3年的时间,ATS慢慢变成了主力,并且在2013年的双11期间挑起了大梁。不过这两年,他们自己开发的swift缓存系统逐渐成形(这里的swift不是openstack的组件,不要混了),并且开始逐步替代ATS。

那么在阿里放弃ATS之后,其他的大公司的使用者,据我了解就是京东,新浪微博这些了。对了,小米也在用ATS。

国外的情况来看,ATS的使用目前也不是太多,比较大的有akamai,yahoo,linkedin这些了。据说google也在用哦。ATS之所以没有普及开来,跟它本身的复杂性是有直接关系的。某人曾说过,如果nginx是初中生的话,ATS就可以是博士生。(逃

不过这几年,服务器领域风头最劲的,还要属nginx。特别是国内范围内nginx的火爆场面,真是让人羡慕。这跟阿里的不遗余力的推广有很大关系。在2010年左右,网上能找到的关于nginx分析得比较好的博客,作者基本都是阿里的,或者后来去了阿里。这里面必须要提到的就是章亦春(agentzh)。他几乎是靠一己之力,将nginx推上了一个新高度。nginx lua模块的诞生可以说是革命性的。

现在使用nginx的公司,几乎都在使用nginx lua。在WAF领域,nginx lua的出现,在技术实现上来说,完全变成了傻瓜式。

由于lua天生跟c,c++的密切性,使得连ATS都支持了lua模块。所以很多公司的后端服务的架构也随之发生了改变。他们开始讲纯粹的业务逻辑剥离出来,用nginx lua来实现,放在前端。这样原来必须在cache里面用c或者c++写业务逻辑的苦逼状况得以极大的改善。

所以nginx+ats,nginx+squid的架构开始出现,并得到了广泛过的应用。而阿里现在的架构也是这样的:

QQ截图20150618114730.jpg

在上图中我们可以看到前面的nginx(也即是tengine)充当业务处理和调度,后面的cache(swfit)做缓存。这样的架构,让业务开发变得很容易,而且很高效。nginx+lua可以轻松搞定。

那么问题来了,这样的架构相比较直接用c/c++在cache写业务处理,性能上肯定会降低,那么就需要评估下性能降低的情况,如果太多,那么即使是nginx+lua换来了开发和维护的低成本,可能也是难以接受的。我专门针对这两种架构,进行了性能测试,cache使用的是ATS。

单纯使用ATS:

QQ截图20150618114813.jpg

Nginx+ATS: 

QQ截图20150618114844.jpg

  • con: 并发连接数。并发连接数,单进程单cpu处理能力取决于CPU与测试场景,请酌情设置,推荐小于9999

  • new: 每秒新建连接数。这个参数取决于并发连接数量与长连接效率。

  • ops: 每秒请求数。也作qps,是比较体现服务器性能的关键指标。

  • 1byte:首字节平均响应时间。这个是体现整体转发效率的关键指标。

  • lat: 完成请求整体响应时间(收到最后一个字节)。cache系统性能关键指标。

  • bytes/per:每秒字节流量/每秒每连接流量

  • total:服务器端总请求的字节数

  • time:测试时间(秒)

通过数据对比我们可以看到,nginx+ats的性能较纯ats,要降低大概5%,这个是完全可以接受的。注意这里的nginx跟ats是放在一台服务上的,如果分开不同的机器,那就得不偿失了,不仅latency增加,机器的数量也随之增加。

trafficserver完胜nginx、squid的高性能CDN服务器

一 trafficserver介绍-一个高性能的、模块化的 HTTP 代理和缓存服务器

Apache Traffic Server(ATS或TS)是一个高性能的、模块化的 HTTP 代理和缓存服务器。Traffic Server 最初是 Inktomi 公司的商业产品,该公司在 2003 年被 Yahoo 收购,之后Traffic Server 一直在 Yahoo 内部使用长达 4 年,直到 2009 年 8 月 Yahoo 向 Apache 软件基金会(ASF)贡献了源代码,并于 2010 年 4 月成为了 ASF 的顶级项目(Top-Level Project)。Apache Traffic Server 现在是一个开源项目,开发语言为C++。

Traffic Server 的开发团队曾经由 Chuck Neerdaels 领导,他也是 Harvest 项目的早期创始人之一,Harvest 项目后来发展为十分流行的 Squid 项目;Leif Hedstrom 直接管理着现在的 Traffic Server 开发团队。目前 Chuck Neerdaels 和 Leif Hedstrom都已加盟知名 CDN 服务提供商Akamai。
 
HTTP 代理服务器是 HTTP 服务器的一种实现,处于客户端(一般为浏览器)与另一个 HTTP服务器之间(通常指源服务器,Origin Server)。HTTP 代理通常分为正向代理、反向代理和透明代理,我们主要关注的是反向代理(Reverse Proxy,见下图)反向代理服务器根据明确配置的映射规则来处理用户请求。反向代理服务器通常会设置一个较大的缓存区,服务器处理请求的同时将请求的内容缓存在服务器本地,当下次用户请求同一个对象时,服务器可直接从缓存区里取出对象,而不用去源服务器去取,起到了加速的效果。另外,配置反向代理的映射规则也能实现负载均衡的功能。除了 Traffic Server,常见的开源代理服务器还有 Squid,Varnish,Nginx,HAProxy。 
Apache <wbr>Traffic <wbr>Server <wbr>简介

        Traffic Server 在 Yahoo 内部使用了超过 4 年,主要用于 CDN 服务,CDN 用于分发特定的HTTP 内容,通常是静态的内容如图片、JavaScript、CSS。下面是Traffic Server 在 Yahoo CDN应用的一些情况:
超过 4 年的使用中,缓存中没有出现已知的数据损坏(data corruption);
作为反向代理,服务器方便部署和管理,并且大部分配置的更改可直接在线上服务器完成,而不用重启服务;
在高并发情况下扩展良好,支持 HTTP/1.1 协议特性,如 SSL、Keep-Alive;
在世界范围内部署了超过 100 台服务器;
在实际CDN中,每秒处理超过 350,000 次请求,达到 30 Gbps,最大容量至少十倍于普通使用,以应对高峰时的大量请求;
在实际 CDN 中,每台服务器有 20,000 到 30,000 的 keep-alive 并发连接,其中有 1,000 到 2,000 的连接是一直很活跃的;
实验环境中,单台服务器每秒处理 105,000 次请求,请求的对象是被缓存住的小文件;
实验环境中,请求大文件时,单台服务器达到 3.6 Gbps(4x GigE NIC bonded)。
二 组件、机制

Traffic Server(TS) 的组成
1.Traffic Server缓存
TS 缓存包含一个高速的对象数据库,数据库根据 URL 和相关头部来索引对象,对于同一对象可以缓存不同版本(如不同的编码、语言)。
当缓存空间满后,TS 会移除过期的数据。
当磁盘出错时,TS 将不再使用该块磁盘,转而使用剩下的磁盘。所有磁盘都出错时,TS 将切换至 proxy-only 模式,即只代理,不缓存。
可分区,即可以给指定的协议和源服务器划分一定数量的磁盘空间
2.RAM 缓存
        内存缓存区储存比较热门的对象,在流量的高峰期时能加快处理速度和降低磁盘负载。
 
3.主机数据库
储存 DNS 信息,方便主机名到 IP 地址的快速转换
储存每个主机的 HTTP 版本,方便高级协议特性的使用
储存主机的可靠性和可用性信息
4.DNS 解析器
                TS 原生实现了 DNS 解析器,不依赖较慢的传统解析库。同时也降低了 DNS 的流量。
 
5.Traffic Server 进程
traffic_server 进程负责接受连接,处理协议请求,然后从缓存或源服务器获取对象并返回
traffic_manager 进程是 TS 的命令和控制设施,负责启动、监控和配置 traffic_server 进程,它也负责代理的端口配置、统计信息的接口、集群管理和虚拟 IP 的故障转移。
如果 traffic_manager 检测到 traffic_server 进程失效,它立即重启 traffic_server 进程并且维护一个连接队列,保存此时到来的请求,完全重启后这个队列里的连接将按顺序被处理。
traffic_cop 进程监视 traffic_server 和 traffic_manager 进程,此进程周期性的查询 traffic_server 和 traffic_manager 进程的健康状况,如果查询在一定间隔时间内未返回或者返回信息不正确,traffic_cop 将重启 traffic_manager 和 traffic_server 进程。
Apache <wbr>Traffic <wbr>Server <wbr>简介
6.管理工具
Traffic Line 是命令行程序,可以用来快速监视 Traffic Server 的性能和网络流量,也能配置 TS。
Traffic Shell 也是命令行工具,进入该 shell 后有自己一套语法,可代替 Traffic Line 完成监控、配置任务。
通过 Traffic Line 和 Traffic Shell  对配置作出的修改将会自动写入配置文件中。
 
Traffic Server 的底层机制

Apache Traffic Server 不同于大部分开源代理服务器,它结合了两种技术来处理高并发:
异步事件处理(Asynchronous event processing)
多线程(Multi-threading)
Traffic Server 在多 CPU、多核的硬件上扩展良好,能充分利用所有可用的 CPU 和其他资源。
 
HTTP 代理缓存相关机制
 
1. Traffic Server 处理请求的过程
  1)用户请求一个 web 对象,TS 收到请求
  2)TS 通过对象的地址,在对象数据库(缓存)中去定位该对象
      a.如果对象在缓存中,TS 会检查对象是否新鲜(fresh)
           如果新鲜,TS 从缓存里返回该对象给用户,此时称为缓存命中(cache hit)
           如果不新鲜(stale),TS 会连接源服务器去验证对象是否仍然新鲜,即重新验证(revalidation),如果仍然新鲜,TS 立即将缓存中的副本返回给用户
      b.如果对象不在缓存中(缓存未命中,cache miss),或者缓存的副本不再有效,TS 会去源服务器获取对象,然后同时做下面两件事
           将对象返回给用户
           将对象放到本地缓存中
2. Traffic Server 判断 HTTP 对象是否新鲜(fresh)的过程
如果有 Expires 或者 max-age 头部直接定义缓存的过期时间,TS将对比当前时间和过期时间去判断对象是否新鲜
如果没有上述头部,TS 将检查 Last-Modified 和 Date 头部(其中Date是源服务器返回对象的时间,如果没有 Last-Modified 头部,TS 会用对象写入缓存的时间以作代替),然后用以下公式算出新鲜的时间范围(freshness_limit,可理解为保质期):
                     freshness_limit = ( Date – Last-Modified ) x 0.1
0.1 这个参数可以作调整,并且能限制 freshness_limit 的上下限,默认最小是 1 小时,最大是 1 天
如果没有 Expires 头部或者没有 Last-Modified、Date 头部,TS 将使用默认的 fressness limit
另外,TS 还会检查 cache.config 配置文件中的 revalidate 规则,该规则可以对特定的 HTTP 对象设置特定的验证时间(特定的域名、IP、一定规则的 URL、特定的客户端等等)
3. 缓存过期(stale),Traffic Server 去源服务器重新验证对象可能的情况
仍然 fresh,TS 重置 freshness_limit,并返回对象
对象新副本可用,TS 缓存新对象,并同时返回给用户
源服务器上的对象不再存在,TS 也不再返回该副本给用户
源服务器没有响应,TS 返回过期的对象并发出警告。
更详细的说明请查看 Traffic Server 管理文档中的 HTTP Proxy Caching 部分

三 安装、使用
    Apache Traffic Server 开源后添加了 64 位支持,也移植到了常见的 Linux 发行版、FreeBSD、OpenSolaris 和 Mac OS X,开源之前 Yahoo Traffic Server 一直运行在 32-bit Linux 上。
 
(以 Apache Traffic Server 2.1.1 unstable 为例在 32-bit Linux 环境下进行安装测试)
 
安装
 
1. 下载、解压
 
wget http://www.apache.org/dist/trafficserver/trafficserver-2.1.1-unstable.tar.bz2
wget http://www.apache.org/dist/trafficserver/trafficserver-2.1.1-unstable.tar.bz2.md5
md5sum -c trafficserver-2.1.1-unstable.tar.bz2.md5
tar jxvf trafficserver-2.1.1-unstable.tar.bz2
cd trafficserver-2.1.1-unstable
 
2. 编译、安装
 
    查看 README 说明文档,安装编译依赖的库(centos 可参照 fedora 依赖的软件包,pcre包替换为 pcre-devel 即可)
 
./configure –help   查看编译的一些选项
./configure  (默认安装在 /usr/local,如需修改,使用 –prefix=PREFIX;参数中还有用户和用户组选项,这是 TS 进程运行的身份,默认均为 nobody,centos 可以不作修改,其他发行版可能需要修改,如 ./configure –with-group=nogroup)
make
make install  以管理员身份执行

目录结构
 
 
默认目录
内容
/usr/local/var/log/trafficserver
运行时创建的日志文件
/usr/local/var/trafficserver
运行时的一系列文件
/usr/local/etc/trafficserver
配置文件
/usr/local/bin
可执行文件
/usr/local/libexec/trafficserver
插件
 
 
初步配置
 
records.config 是 key-value 格式的配置文件,负责大部分全局的选项设置,即主配置文件。
storage.config 用于指定磁盘存储。
remap.config   定义映射规则,用于请求的重写(rewrite),反向代理即在此配置。
records.config 中关键的配置
CONFIG proxy.config.exec_thread.autoconfig INT 1
CONFIG proxy.config.exec_thread.autoconfig.scale FLOAT 2.0
CONFIG proxy.config.exec_thread.limit INT 2   # 经观察是每个核创建的线程数,官方文档中未提及
 
CONFIG proxy.config.cluster.ethernet_interface STRING eth0 # 设置以太网接口
CONFIG proxy.config.http.server_port INT 8080  # 监听端口,反向代理通常为80
LOCAL proxy.local.incoming_ip_to_bind STRING 0.0.0.0 # 绑定的 IP,可省略,默认即为 0.0.0.0
 
CONFIG proxy.config.http.cache.http INT 1 # 打开缓存功能
CONFIG proxy.config.cache.ram_cache.size INT 512M  # RAM 缓存大小
 
CONFIG proxy.config.reverse_proxy.enabled INT 1   # 打开
CONFIG proxy.config.url_remap.remap_required INT 1 # 1为只反向代理,0为正向+反向代理
CONFIG proxy.config.url_remap.pristine_host_hdr INT 0
 
CONFIG proxy.config.ssl.enabled INT 0 # 关闭SSL
CONFIG proxy.config.ssl.server.cert.filename STRING server.pem
 
CONFIG proxy.config.http.server_max_connections INT 2000  # 同源服务器的最大连接数
CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 60 # 当一个事务结束后同原服务器保持连接的时间
 
remap.config  配置
 
         map http://cdn.example.com/js           http://js.example.com  # 通过 DNS 轮询可实现负载均衡
         reverse_map http://js.example.com     http://cdn.example.com/js   # reverse_map 能在源服务器 有 HTTP重定向跳转时,修改重定向请求,即重写 Location 头部内容
 
        map http://cdn.example.com/css        http://css.example.com
        reverse_map http://css.example.com  http://cdn.exampe.com/css
 
        map http://cdn.example.com/img        http://img.example.com
        reverse_map http://img.example.com  http://cdn.example.com/img
 
 storage.config 配置
    /data1 67108864   # 指定一个或多个目录,注明缓存大小,也可直接指定 raw 分区,详见storage.config 中的注释说明
 
更详细的配置可参考官方管理指南 http://trafficserver.apache.org/docs/v2/admin/

服务控制
运行 /usr/local/bin/trafficserver start
结束 /usr/local/bin/trafficserver stop
重启 /usr/local/bin/trafficserver restart 
命令行工具、监控
 /usr/local/bin/traffic_line 需用管理员身份执行
查看帮助 traffic_line -h
查看变量的值 traffic_line -r 变量名 (变量名见官方管理指南附录C,含 TS 运行时统计数据)
给变量赋值 traffic_line -s 变量名 -v 值  (变量名见records.config)
不重启TS 使配置生效 traffic_line -x
 /usr/local/bin/traffic_shell 需用管理员身份执行,进入后提示符为“%”
查看帮助 man traffic_shell (由于开发者疏忽,暂不能用)
show 命令,如 %show:cache-stats 查看缓存统计,如命中情况,缓存大小;如%show:proxy-stats 查看命中率
config 命令,如 %config:logging event disable 关闭日志;如 %config:cache clear,清除缓存,config命令作出的修改都会立即生效
 /usr/local/bin/traffic_logcat 日志查看工具
traffic_logcat -h 获得帮助
查看二进制日志 traffic_logcat 日志文件名
Traffic Server 系统自身的运行日志可在 /var/log/message 中查看(centos),用于排错
traffic_logstats 提供了基于日志的统计功能
四 结论
    Apache Traffic Server 开源后功能在不断被开发,性能得到很大提升,社区也在逐渐发展,但除了 Yahoo 之外还很少有其他实践,很多功能(如集群)的文档有待完善。Traffic Server 丰富的插件开发是其一大亮点,模块化的特点使其拥有很好的扩展性和灵活性,再加上它的高性能,相信 Apache Traffic Server 未来将在很多场景中替代传统的代理和缓存服务器而成为大家的首选。


squid与Apache TrafficServer压力测试对比

SQUIDATS (Apache Traffic Server) 压力测试

一.测试环境

1CPU:双核  Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz

2.内存:2G

3.系统版本:CentOS release 6.2 (2.6.32-220.el6.x86_64)

4.磁盘读写速度:disk reads:  308 MB in  3.01 seconds = 102.28 MB/sec

 

二.软件版本

1SQUID squid-3.0.STABLE18

2ATS   trafficserver-3.3.0-dev.tar.bz2

3Ab :     Version 2.3

 

注:

1.由于压力测试命令SQUID ATS服务在一台机器上,测试得出的数值偏小,测试总连接数都为20000,并发数逐步增加。

2.echo 10 > /proc/sys/net/ipv4/tcp_fin_timeout 减少大量的TIMEOUT回收时间,否则影响测试结果

3.ulimit -SHn 655350 增加文件描述符限制

4.SQUID缓存目录建立在了/dev/shm/cache mount –bind /cache /dev/shm/cache

 

三.测试结果

1.测试分为两种情况:

1)1.6K 在小的图片文件

2)771K aac音频文件

2.       ATS 采用了EPOLL,KQUEUE 的异步IO框架,比较早的select模式在大并发量的情况下优势显著,图中可以看出各项指标均比SQUID 优秀很多。

3.       SQUID在处理小文件时,命中率不是很稳定,而在处理大文件里命中率接近100%

4.       在测试中,ATSSQUID连接处理所需的时间少很多,同时每秒处理请求数翻倍。

5.       在本机与其它机器使用 –header=” Host: www.xxx.com” ,–H “Host: www.xxx.com”,命令测试时,ATSSQUID穿透没有问题,查看日志TCP_HIT,MEM_HIT,均有带www.xxx.com的头信息连接命中。

 1.6K 在小的图片文件



 771K aac音频文件,由于压力测试命令 SQUID ATS服务在一台机器上,测试得出的数值偏小,(测试机同时建立并处理压力测试连接)SQUID并在并发为 2500的时候,没有了处理能力,机器反应缓慢,停止了测试。