包转发线速的衡量标准

2008.09.07 1:25 下午 »Author: bixuan »

这里首先感谢莫大分享的文档

包转发线速的衡量标准是以单位时间内发送64byte的数据包(最小包)的个数作为计算基准的。对于千兆以太网来说,计算方法如 下:1,000,000,000bps/8bit/(64 + 8 + 12)byte=1,488,095pps 说明:当以太网帧为64byte时,需考虑8byte的帧头和12byte的帧间隙的固定开销。故一个线速的千兆以太网端口在转发64byte包时的包转 发率为1.488Mpps。快速以太网的线速端口包转发率正好为千兆以太网的十分之一,为148.8kpps。
*对于万兆以太网,一个线速端口的包转发率为14.88Mpps。
*对于千兆以太网,一个线速端口的包转发率为1.488Mpps。
*对于快速以太网,一个线速端口的包转发率为0.1488Mpps。

最初PCI总线是32bit,33Mhz,这样带宽为133Mbps。
接着因为在服务器领域传输要求Intel把总线位数提高到64,这样又出现了2种PCI总线,分别为64bit/33Mhz和64bit/66Mhz,当 然带宽分别翻倍了,为266Mbps和533Mbps,这个比较通常的名称应该是pci-64,但这好像是intel自己做的,没有行业标准。
稍后一段时间,在民用领域,单独开发出了AGP,32bit,66Mhz,这样带宽为266Mbps,再加上后来AGP2.0的2X和4X标准,最高4X的带宽高达1Gbps,但是这个只是为显卡设计的。
同时服务器领域也没闲着,几家厂商联合制定了PCI-X,这个就是真正PCI下一代的工业标准了,其实也没什么新意,就是64bit,133Mhz版本的 PCI,那这样带宽就为1Gbps,后来PCI-X 2.0,3.0又分别提升频率,经历过266Mhz,533Mhz,甚至1GMhz,各位自己算带宽吧,我乘法学的不好,这个带宽可以说是非常足够的了, 不过这个时候PCI也面临一些问题:一方面是频率提高造成的并行信号串扰,另一方面是共享式总线造成的资源争用,总之也就是说虽然规格上去了,但实际效果 可能跑不了这些指标。
然后就是我们目前的明星pci-E了,这个标准应该是和pci-X同时出现的,但是由于当时用不到这么高带宽,并且不像pci-X一样兼容老pci板卡, 所以一直没什么发展,直到最近民用领域显卡带宽又不够了,服务器领域对pci-X也觉得不爽了,pci-E才真正显出优势来,目前这个标准应该会替代 agp和pci-X,成为民用和服务器两大领域的统一标准。
PCI-E标准的最大特点就是串行总线,和普通pci的区别类似于ide和sata的区别,具体说起来就比较麻烦了,简单来看指标的话,频率为 2.5Ghz(这个恐怖,串行的好处,同样因为串行,位宽就没意义了,但是据说是什么8bit/10bit的传输),带宽 pci-E 1X单向传输250MBps,双向也就500了,同时pci-e的倍速最高可达16X,多少就自己乘吧,要注意的是pci-e不存在共享问题,也就是说挂 在总线上的任何一个设备都会达到这个速度而不是所有设备带宽的总合。下面引用一篇文章的一段,感兴趣的自己看一下:

在工作原理上,PCI Express与并行体系的PCI没有任何相似之处,它采用串行方式传输数据,而依靠高频率来获得高性能,因此PCI Express也一度被人称为“串行PCI”。由于串行传输不存在信号干扰,总线频率提升不受阻碍,PCI Express很顺利就达到2.5GHz的超高工作频率。其次,PCI Express采用全双工运作模式,最基本的PCI Express拥有4根传输线路,其中2线用于数据发送,2线用于数据接收,也就是发送数据和接收数据可以同时进行。相比之下,PCI总线和PCI-X总 线在一个时钟周期内只能作单向数据传输,效率只有PCI Express的一半;加之PCI Express使用8b/10b编码的内嵌时钟技术,时钟信息被直接写入数据流中,这比PCI总线能更有效节省传输通道,提高传输效率。第三,PCI Express没有沿用传统的共享式结构,它采用点对点工作模式(Peer to Peer,也被简称为P2P),每个PCI Express设备都有自己的专用连接,这样就无需向整条总线申请带宽,避免多个设备争抢带宽的糟糕情形发生,而此种情况在共享架构的PCI系统中司空见 惯。

由于工作频率高达2.5GHz,最基本的PCI Express总线可提供的单向带宽便达到250MBps(2.5Gbps×1 B/8bit×8b/10b=250MBps),再考虑全双工运作,该总线的总带宽达到500MBps—这仅仅是最基本的PCI Express ×1模式。如果使用两个通道捆绑的×2模式,PCI Express便可提供1GBps的有效数据带宽。依此类推,PCI Express ×4、×8和×16模式的有效数据传输速率分别达到2GBps、4GBps和8GBps。这与PCI总线可怜的共享式133MBps速率形成极其鲜明的对 比,更何况这些都还是每个PCI Express可独自占用的带宽。

总之写这么多废话,目的就是说明就系统总线来说,承受高带宽,高pps是没问题的。
再上面有人说即使总线没限制,cpu也会成为瓶颈,这话有一定道理,其实关键在于高pps带来的恐怖中断flood,其实对于这么高的中断,i386的 apic(高级中断控制)是完全处理的来,瓶颈是在操作系统的中断处理程序上了,这方面问题就由操作系统来解决了,所以不是什么不可能完成的任务,实际上 目前也都有很成熟的方案了,比如BSD系统的网卡Polling,Linux也有,具体叫什么我忘记了。
还是那句话,别对i386没信心,也别对目前的PC架构计算机的能力有任何怀疑,事实证明,这样的搭配至少能满足90%的应用需要。

一. 线速
线速转发是对一个网络中转设备的理想要求。但平时大多数人都关注着设备的bps(bits per second,每秒数据的位数),很少人会想到fps(frame per second,每秒数据的帧数)实际上更考验设备的转发能力。
简单的说,bps是指每秒钟有多少字节的数据经过,fps是每秒钟有多少个数据包经过。
以10Mb的网络来说,线速时bps为10M,fps最大值为14880。
那么这个14880是怎么计算出来的呢?
首先我们要知道几个规定:
1. 以太网内最小的数据包的大小为64字节,它包括4字节的CRC,2字节的以太网类型(或长度),6字节的源Mac地址,6字节的目的Mac地址以及46字节的负荷。
2. 以太网帧与帧之间至少要有96位(12字节)的帧间隙(IFP,inter frame gap)以确保区分两个数据包。
3. 每个数据帧开始之间必须要有8字节的Mac地址前导位(MAC preamble)以确保发送方接收方同步数据位。
因此,以太网内最小的数据包实际上是64+12+8=84字节=672位。
于是,10M网络环境下fps的最大值就是
10M位每秒 / 672 位每帧 = 14480 帧每秒。
同理,我们可以算出10M网络环境下fps的最大值为
10M位每秒 / ( ( 1518+12+8 ) * 8 ) 位每帧 = 812 帧每秒
而100M网络环境下这两个值分别为148809和8127。
二. 处理能力
我们已经知道了线速情况下最大的fps值,现在我们看看要达到线速所需要的处理能力。
假设市面上某防火墙的是X86架构的CII 900Mhz 的CPU,即每秒钟可以分成900M个时钟周期。
于是,在100M的网络环境下,处理一个数据帧所允许的最大时钟周期为:
900M 时钟周期每秒 / 148809 帧每秒 = 6048 时钟周期每帧
也就是说,要达到线速转发,900Mhz的CPU平均要在6048个时钟周期内完成对一个数据包的处理。
这只是理想情况,基于x86架构的系统里CPU还要负责各类中断(如系统时钟)的处理,每次中断时都要保存当前的运行状态,切换到中断处理程序,等中断处 理完后,再恢复当前状态,切换回原来的处理流程。光是这个切换过程至少都要费上500个时钟周期,还不包括中断处理程序所用的时钟周期。好在这类中断还” 不算“频繁,扣除系统这部分开销后,真正分摊到每个数据包的处理时间平均大约还有5500个时钟周期。
虽然Intel P3以上级的CPU如CII在设计指令集时已经将大量常用的指令(如两个寄存器相加/减)优化到可以在一个时钟周期内完成,但做为防火墙,更常用的是读 /写内存数据(比如要比较源地址,计算IP的校验和等)这类多时钟周期的指令,所以5500个时钟周期内大约只能执行2000条指令。
对一个数据包的处理,从为这个数据包分配内存起,依次要检查以太网络协议(如果是RFC1042格式的数据包还要跳过LLC头找真正的以太网络协议),检 查IP头、校验和(如果是TCP/UDP协议还要计算对应的校验和),DoS防御,状态检测,NAT规则,安全/统计规则,更新ARP/路由表,选择转发 网卡,直到最终把这个数据包添加到发送队列中才算完成。

总线是一组进行互连和传输信息(指令、数据和地址)的信号线。主要参数有总线位宽、总线时钟频率和总线传输速率。
※总线位宽决定输入/输出设备之间一次数据传输的信息量,用位(bit)表示,如总线宽度为8位、16位、32位和64位。
※总线时钟频率是总线的工作频率,以 MHz 表示。
※总线传输速率是总线上每秒钟所能传输的最大字节数。通过总线宽度和总线时钟频率来计算总线传输速率。
一. 并行总线。
并行总线带宽(MB/s) = 并行总线时钟频率(MHz) * 并行总线位宽(bit/8 = B) * 每时钟传输几组数据(cycle)
●PCI 总线位宽是 32位,总线频率 33 MHz,每时钟传输 1 组数据,它的带宽为 127.2 MB/s,即 1017.6 Mbps。
●PCI 2.1 总线位宽是 64位,总线频率 66 MHz,每时钟传输 1 组数据,它的带宽为 508.6 MB/s,即 4068.8 Mbps。
●AGP 总线位宽是 32位,总线频率 66 MHz,每时钟传输 1 组数据,它的带宽为 254.3 MB/s,即 2034.4 Mbps。
●AGP Pro 总线位宽是 32位,总线频率 66 MHz,每时钟传输 1 组数据,它的带宽为 254.3 MB/s,即 2034.4 Mbps。
AGP Pro 是 AGP 的改进型,它使工作站级主板也能利用 AGP 的加速性能,降低了 AGP 所需的电压供应,并没有什么太大的改变。
●AGP 2X 总线位宽是 32位,总线频率 66 MHz,每时钟传输 2 组数据,它的带宽为 508.6 MB/s,即 4068.8 Mbps。
●AGP 4X 总线位宽是 32位,总线频率 66 MHz,每时钟传输 4 组数据,它的带宽为 1017.3 MB/s,即 8138.4 Mbps。
●AGP 8X 总线位宽是 32位,总线频率 66 MHz,每时钟传输 8 组数据,它的带宽为 2034.6 MB/s,即 16276.8 Mbps。
顺带说说:
○ISA 总线位宽是 16位,总线频率 8.3 MHz,每时钟传输 1 组数据,它的带宽为 15.9 MB/s,即 127.2 Mbps。
○EISA 总线位宽是 32位,总线频率 8.3 MHz,每时钟传输 1 组数据,它的带宽为 31.8 MB/s,即 254.4 Mbps。

二. 串行总线。
好,该说最新的 PCI Express 了,和上面这些并行总线不同的是,PCI Express 属于串行总线,总线带宽和总线时钟频率的概念与并行总线完全相同,只是它改变了传统意义上的总线位宽的概念。串行总线采用多条管线(或通道)的做法实现更 高的速度,管线之间各自独立,多条管线组成一条总线系统。如 PCI Express x1,PCI Express x2,PCI Express x16 等。
PCI Express 总线频率 2500 MHz,这是在 100 MHz 的基准频率通过锁相环振荡器(Phase Lock Loop,PLL)达到的。
串行总线带宽(MB/s) = 串行总线时钟频率(MHz) * 串行总线位宽(bit/8 = B) * 串行总线管线 * 编码方式 * 每时钟传输几组数据(cycle)
◆PCI Express x1 总线位宽是 1位,总线频率 2500 MHz,串行总线管线是 1 条,每时钟传输 2 组数据,编码方式为 8b/10b,它的带宽为 476.84 MB/s,即 3814.7 Mbps。(带宽是 PCI 的 3.75 倍。)
公式是 2500000000(Hz) * 1/8(bit) * 1(条管线) * 8/10(bit) * 2(每时钟传输2组数据) = 500000000 B/s = 476.8371582 MB/s,即 3814.6972656 Mbps。
下面给出其它类型组合的带宽。
◆PCI Express x2 的带宽为 953.68 MB/s,即 7629.4 Mbps。(此模式仅用于主板内部接口而非插槽模式)
◆PCI Express x4 的带宽为 1907.36 MB/s,即 15258.9 Mbps。
◆PCI Express x8 的带宽为 3814.72 MB/s,即 30517.8 Mbps。
◆PCI Express x16 的带宽为 7629.44 MB/s,即 61035.5 Mbps。(带宽是 AGP 8X 的 3.75 倍。)
◆PCI Express x32 的带宽为 15258.88 MB/s,即 122071 Mbps。

可能有朋友感觉在这看到的带宽数据比别处看到的值要小,因为我采录的是实际数据,而非文稿数据。就如同说硬盘 160 GB,而实际能用的只有 153 GB 左右。
感兴趣的朋友请接着往下看!
PCI 的带宽常被引述为 132 MB/秒,这是文稿数据,它的实际带宽是 127.2 MB/秒。
造成如此差异是因为:
1. 对工作频率具体数值引用的不同。
2. 容量单位上存在二进制计量与十进制计量,132 MB/秒来源于十进制计量,127.2 MB/秒来源于二进制计量。
并行总线带宽(MB/s) = 并行总线时钟频率(MHz) * 并行总线位宽(bit/8 = B) * 每时钟传输几组数据(cycle)
B/s = Hz * bytes * cycle
MB/s = MHz * bytes * cycle
132 MB/秒:
PCI 的工作频率是 33 MHz, 即 33 MHz * 1000000 = 33000000 Hz。
PCI 的位宽是 32 bits, 即 4 bytes。
PCI 每时钟传输 1 组数据。
33000000 Hz * 4 bytes * 1 cycle = 132000000 byte/s 除以 10的6次方(容量以十进制计量) = 132 megabyte/s = 132 MB/s
而 127.2 MB/秒:
PCI 的工作频率是以 30ns 来表示,X ns 的倒数 * 1000 = Y MHz,即 30 ns 的倒数 * 1000 = 33.333333 MHz,33.333333 MHz * 1000000 = 33333333 Hz。
PCI 的位宽是 32 bits, 即 4 bytes。
PCI 每时钟传输 1 组数据。
33333333 Hz * 4 bytes * 1 cycle = 133333332 byte/s 除以 2的20次方(容量以二进制计量) = 127.1566 mebibyte/s = 127.2 MB/s = 1017.6 Mb/

PCI是由Intel公司1991年推出的一种局部总线。从结构上看,PCI是在CPU和原来的系统总线 之间插入的一级总线,具体由一个桥接电路实现对这一层的管理,并实现上下之间的接口以协调数据的传送。管理器提供了信号缓冲,使之能支持10种外设,并能 在高时钟频率下保持高性能,它为显卡,声卡,网卡,MODEM等设备提供了连接接口,它的工作频率为33MHz/66MHz。
最早提出的PCI 总线工作在33MHz 频率之下,传输带宽达到了133MB/s(33MHz X 32bit/8),基本上满足了当时处理器的发展需要。随着对更高性能的要求,1993年又提出了64bit 的PCI 总线,后来又提出把PCI 总线的频率提升到66MHz 。
PCI的标准从V1.0到目前的V2.2 V2.3,但好像有被PCI-E取代的趋势.

Share/Save/Bookmark

Web站点体系结构组成元素

2008.09.07 10:16 上午 »Author: bixuan »

一般来说,组成Web站点体系结构有如下几个基本元素。

浏览器

因为Web浏览器标准、简单且普遍使用,所以它可以称得上是一个接近理想状态的图形用户接口(Graphical User Interface,GUI)。
目前比较流行的浏览器有:IE,firefox,opera,safari等,所以必须要了解其的相关特性,这也利于更好的利用这些特性来做相关架构的设计。

负载均衡

最简单的莫属DNS轮询(Round Robin DNS)方式了,但是不建议使用,因为下面的三个原因迫使你特别小心:
1. Round Robin DNS无法实现真正的负载均衡,但是在一些简单情况下还是能够均衡负载。真正的负载均衡是监测服务器的使用情况,以及根据该使用情况来分配连接,以便能始终将连接分配给那些有足够的容量来处理这些连接的服务器。
当Round Robin集中的一台服务器比其他服务器慢很多时,就会产生一种称为”护航(convoying)“的特殊情况,这时用户会列队等待速度较慢的服务器,而较快的服务器则未被使用。真正的负载均衡不会出现这样的问题。
2. RRDNS不会视图解决服务器的失效问题。用户仍然会被引导到失效的服务器上。真正的负载均衡可以提高站点的可用性,因为如果一台服务器出现故障,那么其他的服务器会自动接过该服务器的负载。
3. RRDNS很难保持用户的状态,特别是使用session的业务,比如某个用户在发表文章或者回复的时候,应用程序会对该用户的session保存在当前的服务器上,但是当用户写好文章或者回复开始提交后,因为RRDNS,结果发现用户提交到了另外的服务器上,因为新的服务器上没有用户的session,提示用户未登陆等警告信息,所以会导致提交失败。
很多情况,情况当要从dns里删除失效的IP时,会发现DNS的更新非常慢,因为很多LOCAL DNS并不遵循相关规范,这样有许多用户的LOCAL DNS服务器的缓存里仍会保留这个失效的IP,而且保留的时候甚至会很久,在国内特别是小的ISP常会这么做。

IP级别的负载均衡
这里常见的软件的实现方式有LVS,值得骄傲的是LVS是由国人章文嵩开发的,其简单高效,当然也需要配合其他的HA软件来实现”三H“。通过IP级别的负载均衡可以避免上述的RRDNS弊端。

当然也可以使用硬件均衡设备。

Web服务器

目前常用开源的Web服务器有:Apache、Nginx、Lighttpd等。
Web服务器的内容和日志应当分开保存到各自专用的磁盘上,这样可以避免他们相互干扰。

中间件

任何与一端的Web服务器和另一端的数据库交互的软件都可以被成为中间件。中间件的好处可以使结构清晰简单,可以提高整体性能。

数据库

数据库表可以通过某种方式被定义、镜像、分割、部署,以使之发挥最大的性能。数据库的优化是们深奥的学问,一个好的数据库管理员(Database Administrator,DBA)身价也是不菲的。
目前常见的DB有:mysql、oracle等。

虽然Web站点体系基本上是上述几个方面,但是影响Web性能确有更多的因素,只要把握上述几个方面,逐步排除和优化,我想结果一定不会差。

Share/Save/Bookmark

graphicsmagick和ImageMagick

2008.09.07 7:19 上午 »Author: bixuan »

graphicsmagickImageMagick一样,都是图像处理软件,目前我们就在用ImageMagick,今天看到两者的比较,让我心动准备实测一下graphicsmagick,官方有份是两者的Benchmark报告,点这里查看。

Share/Save/Bookmark

2008年度最佳开源软件大奖

2008.09.03 3:48 下午 »Author: bixuan »

为开源社区贡献绵薄之力

 InfoWorld历年的开源软件大奖都相当有分量,不过国内知道或者关注这个奖项的用户并不是特别多。InfoWorld 2008年的“开源软件大奖”最新出炉,CHIP软件社区乘此机会将InfoWorld 2008年的“开源软件大奖”中文化并进行整理,希望能够为中国用户带来便利,也希望能够为开源社区共享绵薄之力。
由于InfoWorld的评选软件范围广、类别多,很多时候在同一个类别中,桌面版软件和服务器版软件常常混杂在一起,限于时间和水平,这个专题的组织和本地化肯定有不妥甚至是错漏之处,欢迎用户和网友批评指正。

  查看全文 »

Share/Save/Bookmark

修复jpeg-6b的一个bug

2008.08.14 10:03 上午 »Author: bixuan »

记得一年前发现很多手机上传的照片经过打水印后会损坏图片,后来经过多方搜索,终于找到了解决方案,当时解决后就没做一下记录,时隔一年,终于又要用到,可一时找不到解决方法,突然想起当年打包(rpm)时还留下源码,于是去jpeg-6b下的源代码进行md5比对,终于找到jdmarker.c该文件做过一些修改,赶紧记录:

修改如下:

/*
* WARNMS2(cinfo, JWRN_EXTRANEOUS_DATA, cinfo->marker->discarded_bytes, c);
*/

其实就是注释掉这段代码而已。

Share/Save/Bookmark

预先在存储节点上建立2级目录

2008.08.12 10:19 上午 »Author: bixuan »

预先在存储节点上建立2级目录是个好方法,可以提高程序的执行效率,少了目录是否存在的判断。

同时也减少磁盘io的压力,毕竟一次性建好目录,以后是不会去调整的。

Share/Save/Bookmark

Q4M

2008.08.07 10:13 上午 »Author: bixuan »

What is Q4M?

Q4M (Queue for MySQL) is a message queue licensed under GPL that works as a pluggable storage engine of MySQL 5.1, designed to be robust, fast, flexible. The development started in late December of 2007, and although it is very primitive, operates quite swiftly.
To start using Q4M, download either a binary or source distribution from the install page, and follow the installation instructions. A small tutorial is also avialable. You may use SQL to access Q4M queues, or there is a wrapper module available for perl (Queue::Q4M).
For more information, please read the developer’s weblog (Kazuho@Cybozu Labs) or subscribe to the mailing list
看上去非常不错,自己没实际用过,希望有用过的朋友分享一下经验。

Share/Save/Bookmark

获取教育网IP段

2008.08.06 2:14 下午 »Author: bixuan »

做DNS要更新各SP的网段,下面简单的总结一下早上获取教育网的经过。

其实很简单,首先去教育网官方去获取最新的IP段:

只要下载:http://www.nic.edu.cn/RS/ipstat/ 这个url里的数据,然后进行分析(可惜这个url必须在教育网内才可以正常访问)。

内容如下:

查看全文 »

Share/Save/Bookmark

web 2.0海量小文件cache集群探讨[转载]

2008.07.28 5:58 下午 »Author: bixuan »

web 2.0海量小文件cache集群探讨(原创)

msn:gusingchen@hotmail.com

在互联网快速发展的背景下,特别是we2.0,网络上的数据内容呈几何级的增长,而其中增长最快并且最容易给技术架构带来挑战的就是数目庞大的小文件,如 何来解决这种高并发,大流量,小文件,热点不集中的问题,经过我们大量研究,实践之后,总结出这种海量小文件,高并发所存在的关键问题和解决方案。

我们先对比一下在web1.0的解决方案和web2.0的我们碰到的困难。

Web1.0
1、源数据量小,单台squid即可达到很高的命中率。
2、请求量大,用lvs+squid或者dns轮询即可解决问题。
3、squid服务器磁盘IO压力大,用超大内存做cache。

web 2.0
目前的瓶颈:
1、源数据数量很大,导致squid hash table 索引效率不高,Cache 命中率低。
为了提高对文件的访问效率,往往会在前端配置一个稍大容量的缓存。但由于小文件的数量极其庞大,应用对这些文件访问的随机性非常高,使得Cache 命中率极低,缓存失去了应有的作用,导致应用需要直接到后端存储系统上读取数据,给存储系统带来了极大的压力。刚开始就是我们也采用了昂贵的高端存储系统 NetApp,但是在用户高并发访问的情况下,存储系统经常出现长时间无响应的严重故障。

2、源数据容量巨大,海量文件检索效率低,从而也导致单台squid命中率很低。
有些频道数据容量会超过200T,单台squid只是杯水车薪,频繁的cache置换更是加剧了cache效率低下,再加上现有的存储系统无法有效管理海 量小文件,并且在单个目录下存放文件的数量有一定的限制,一旦文件数到达了一定规模之后,文件的检索速度就急剧下降。我们只能通过多级目录来组织存放大量 的小文件,随着目录深度的增加,文件的检索开销进一步增大,检索效率随之下降。

3、大量的cache导致的磁盘IO问题
由于目前单台cache容量已经达到上百G,文件系统瓶颈、磁盘IO问题也很快凸显。

4、压力过大导致的hit ratio抖动
cache 删除,写操作达到一定的比例,同时如果压力较高,会导致hit ratio呈线性下降。即使cache没down,但也因为命中率的下降而失去应有的作用。

5、特殊集群下的单台失效问题
在类url hash的集群下,单台cache失效会导致hash rehash,那么整个集群的squid命中率都会被冲击。

如何来解决这些问题,思路如下:

1、优化squid hash table 索引算法,
需要修改源squid代码

2、cache集群,用类url hash的方法,以增加cache容量
1)、wccp: cisco的路由器均有此功能
2)、carp: ISA,squid自身的7层调度协议
3)、url hash: nginx haproxy等7层代理

3、选择合适的文件系统
XFS使用更多的内存来作为自己的高速缓存,以尽可能的延迟零散的写操作,尽可能的执行批量写操作。

4、选择更合理的磁盘搭配策略,比如Raid策略或者单盘策略等
Raid 5,10 带来了不错的安全性,但是会导致磁盘IO效率低下,不做Raid的单盘性能最高,更适合单台服务器多squid进程模式。

5、集群下的单台cache失效的接管,以免单点故障,提高可用性。

针对以上分析,我们大量尝试了开源的一些产品,像LVS,Nginx,Squid,XFS等。
具体的软件组合和架构如下:

(1)、web服务器的选择,目前,大多数web服务器的处理能力有限,互联网广泛上使用的web服务器如Apache,其并发能力往往在2000以下, 这是由web服务器自身的设计模式(如多进程,无IO缓存等)决定的。因此,在较大规模的访问情况下,通常会表现出用户访问网站慢,web 服务器负载高。为什么选择Nginx? use linux epoll, sendfile and aio to improve the performanc,我们主要利用的是Nginx的第三方模块ngx_http_upstream_hash_module做反向代理。

部分代码如下:
upstream img{
server squid1:81;
server squid2:81;
hash $request_uri;
hash_again 0; # default 0
hash_method crc32; # default “simple”
}

server {
listen 80;
server_name images.gx.com;
location / {
proxy_pass http://img;

(3)负载均衡软件,我们选择了LVS+HA,用DR模式。目前我们运行环境中的LVS(2.6的内核),普通很稳定。我们主要用Heartbeat+ldirectord。

(4) 适合处理小文件的文件系统XFS。XFS 最佳表现之一在于:象 ReiserFS 一样,它不产生不必要的磁盘活动。XFS 设法在内存中缓存尽可能多的数据,并且,通常仅当内存不足时,才会命令将数据写到磁盘时。当它将数据清仓(flushing)到磁盘时,其它 IO 操作在很大程度上似乎不受影响。

(5)其它优化
在客户端和服务器做大量有效的缓存策略;用更小的并且可缓存的图片(单张图片尽量不要超过200K);尽量减少http请求;开起 keepalive减少tcp连接开销;优化tcp参数;起用多域名分域名策略;减少cookie影响等。

(6)关于优化题外:大配置和架构没有问题的前提下,有money的话应该首选硬件优化方案而不是软件细节优化。

整个架构如下图

后端存储垂直分割的规则如下(按00-ff散列):

location ~ ^/[0-1][0-f]/ {
proxy_pass http://192.168.3.12;
}
location ~ ^/[2-3][0-f]/ {
proxy_pass http://192.168.3.11;
}

……..

以上这个架构的优化在于:
实现了高可用性,最大程度上防止单点,又保证架构的伸缩性。
在后端服务器中模拟url hash的算法来找到内容所在的squid,提高了命中率。
充分发挥机器的性能,架构可扩展性,层次分明。

最后,很重要的二点,1)要通过性能分析和监控,来找到系统瓶颈的临界点和薄弱点。监控分析是一切优化的重点,要以数据事实来调整策略。2)架构的负荷如果已经超过设计负荷的5~10倍,就要考虑重新设计系统的架构,我们这里仅仅讨论某一阶段的架构设计。

部份资料来源http://bbs.be10.com,http://www.dbanotes.net,http://ourlinux.net,特别感谢http://jsqyy.51.com,他在squid方面深有研究。

Share/Save/Bookmark

周末早餐

2008.07.27 10:07 上午 »Author: bixuan »

今天早餐:
|今天早饭
昨日早餐:
|昨日饭

Share/Save/Bookmark