|
可地域识别的流量负载平衡及缓存
|
|
2010-02-10
|
|
|
|
CNBC和许多大型的网站一样，依赖于CDN来传输内容。最近，我们开始研究看是否可以改善这种模式。我们的标准是：
- 提高响应速度
- 更好的控制流量 (实时报告, 变更管理及报警)
- 更好的利用内部数据中心及其基础设施
- 从源基础设施防止用户受到问题干扰
- 减少成本
经过市场调研，我们确定两家：Dyn（动态网络服务）和aiCache。我们与aiCache之间已有1年时间的合作经验，（搜索“CNBC”看看我以前的帖子），但Dyn对我们来说是一个新的供应商。我们于2009年夏季的Velocity会议上开始建立合作关系。
Dyn最近开始提供可识别地理位置的DNS负载平衡解决方案，通过选播（Anycast）方式和基于他们DNS分散的性质，启动了我们之前试图实现的关键部分：引导用户到地理上最接近的节点。流量平衡规则可以非常灵活。例如：
- 发送美国东岸70%的流量到源点A，30%到CDN
- 发送美国西岸50%的流量到源点B，25%到源点C，其余的到CDN
- 所有欧洲的流量到源点D
- 所有亚洲的流量到CDN
Dyn还提供一系列增值服务，诸如通过使用灵活方便的网络门户进行自动监测，故障转移服务，报警和流量报告。
我现在提供一个对于选播（Anycast）如何工作的非科学解释。原则上，想要将用户请求指向地理上最接近节点，必须知道该用户的位置。非常传统的方法需要某种形式的数据库，将IP地址匹配地理位置。这样的数据库很普遍，很多产品都有用到，包括根据地理位置确定内容的广告等。
一种完全不同的方法（尽管不那么精细）来达到同样的目的，即：使用互联网的路由（BGP协议）从在线多点地址推广到同一IP地址的路径。例如，假设有4个域名组，每组含4个节点，IP分别为1.1.1.1，.2，.3及.4。
每组定位在一个主要节点（peering point）：美国东海岸，西海岸，一个欧州，一个亚洲。从每个位置，通过BGP用我们的DNS服务器推广相同的子网。任务完成！通过路由的功能，亚洲的用户可以将其DNS请求连到亚洲的DNS服务器，欧洲的用户请求则连到欧洲的DNS服务器，依此类推。我们很容易看到这种隐含的请求者地理位置现在是如何用来指示其流量到特定的具体位置。我们设置较低DNS TTL值，这样我们可以确保任何DNS变化在合理短的一段时间发生。
换种说法：当用户想访问www.cnbc.com，他/她的浏览器请求www.cnbc.com的DNS解析。该DNS请求会自动流向最近的Dyn DNS集群。集群中的DNS服务器已经知道他们的位置。在此基础上，DNS服务器推断出这一请求也来自同一地理区域的使用者，并在此基础上，根据我们的规则配置，它将发出请求的用户指向到www.cnbc.com适当的节点点。
为了获得一手的数据，我们选取我们自己放在美国东、西海岸的两个数据中心进行测试，每个数据中心都具有千兆的带宽容量。
准确发送流量的方法很简单——我们选用之前一直用的aiCache缓存引擎，这与年内其他项目测试的方案差不多。每个数据中心分配2台刀片服务器，两个中心只需4台服务器就可以发送所有的流量到我们美国的用户群。对V6版aiCache产品的最近一次测试表明：一台普通的惠普DL360服务器响应请求数居然达到每秒25万个。此款aiCache产品可以运行于任何一个版本的Linux操作系统上，包括我们的常用版本RedHat 5.x.。就我方网站www.cnbc.com的具体情况来说，请求数峰值最高才超过3000个/秒，也就是说，我们剩有足够大的超额能力来应对任何可能出现的大流量请求。
以下是我们的测试结果：
—我们可以节约大约1秒钟的（大约30%！）页面存入时间，就如要点注释中说的那样。
—存入我们CMS基础架构中的时间可以缩短80%以上，这无疑对改善CMS环境的稳定性带来了很多积极的影响。
—现在我们对网站流量有了一个完整、实时的观察——包括RPS，响应速度，链接数，缓存响应数等等。
—现在我们可以报告、记录（Zabbix）和提醒任何一种流量参数，而且数据都是实时的！
—我们的CDN流量也减少了大概80%，意味着CDN费用支出减少了80%。
—现在我们能够更好地利用自己的数据中心处理能力了。
—现在我们也有能力即时变更缓存规则或者进行负载分配。
—依靠aiCache，我们可以接受到手机用户的请求进而重定向，避免对CMS服务器不必要的点击。
小结：Dyn动态与地理识别 DNS负载平衡解决方案，加上被证实可靠的aiCache缓存软件足可以使一个顶级财经新闻网站减少30%的响应时间，省钱、实时监控、实时预警、效果好。
|
|
查看留言>>
|
|
|
什么是SSI和SHTML以及aicache进行配置和加速
|
|
2010-01-27
|
|
|
|
什么是SSI和SHTML?
SSI工作的原理.
IIS和Apache如何配置才能解释 SHTML?
IIS配置
apache配置
一个SHTML的小例子
aicache测试结果
SSI（Server Side Include)，通常称为 服务器端嵌入，是一种类似于ASP的基于服务器的网页制作技术。 大多数（尤其是基于Unix平台）的WEB服务器如Netscape Enterprise Server等均支持SSI命令。另外，在计算机硬件领域 SSI是同步串行接口(Synchronous Serial Interface)的英文缩写 。
将内容发送到浏览器之前，可以使用“服 务器端包含 (SSI)”指令将文本、图形或应用程序信息包含到网 页中。例如，可以使用 SSI 包含时间/日期戳、版权声明或供客 户填写并返回的表单。对于在多个文件中重复出现的文本或图形 ，使用包含文件是一种简便的方法。将内容存入一个包含文件中 即可，而不必将内容输入所有文件。通过一个非常简单的语句即 可调用包含文件，此语句指示 Web 服务器将内容插入适当网页。 而且，使用包含文件时，对内容的所有更改只需在一个地方就能 完成。 因为包含 SSI 指令的文件要求特殊处理，所以必须 为所有 SSI 文件赋予 SSI 文件扩展名。默认扩展名是 .stm、.shtm 和 .shtml
一个扩 展名为.shtml的网页点击查看,其代码 如下：
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' ' http://www.w3.org/TR/xhtml1/DTD/xhtml1 -transitional.dtd'>
<html xmlns=' http://www.w3.org/199 9/xhtml' >
<head>
<title>shtml测试</title>
</head>
<body>
<h3>shtml测试</h3>
<hr/>
当前时间： <!--#config timefmt='%A, %B %d, %Y'-- >
<br/>
服务名称：<!--#echo var='SERVER_SOFTWARE' -- >
<br/>
<!--#echo var='SERVER_NAME' -->
<br/>
服务协议：<!--#echo var='SERVER_PROTOCOL' -->
<br/>
<!--#echo var='SERVER_PORT' -->
<br/>
主机名称：<!--#echo var='REMOTE_HOST' -->
</body>
</html>
测试结果： 
Concurrency Level: 800
Time taken for tests: 0.417 seconds
Complete requests: 800
Failed requests: 0
Write errors: 0
Total transferred: 524566 bytes
HTML transferred: 380584 bytes
Requests per second: 1917.33 [#/sec] (mean)
Time per request: 417.246 [ms] (mean)
Time per request: 0.522 [ms] (mean, across all concurrent requests)
Transfer rate: 1227.74 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 18 62 16.7 67 83
Processing: 41 99 89.6 75 341
Waiting: 41 99 89.6 75 340
Total: 94 161 90.5 137 407
Percentage of the requests served within a certain time (ms)
50% 137
66% 146
75% 150
80% 153
90% 388
95% 397
98% 399
99% 404
100% 407 (longest request)
Concurrency Level: 800
Time taken for tests: 0.398 seconds
Complete requests: 800
Failed requests: 0
Write errors: 0
Total transferred: 664361 bytes
HTML transferred: 406348 bytes
Requests per second: 2011.92 [#/sec] (mean)
Time per request: 397.631 [ms] (mean)
Time per request: 0.497 [ms] (mean, across all concurrent requests)
Transfer rate: 1631.64 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 22 55 16.5 61 75
Processing: 35 154 118.9 72 353
Waiting: 35 151 116.9 71 340
Total: 86 209 117.9 137 392
Percentage of the requests served within a certain time (ms)
50% 137
66% 324
75% 346
80% 348
90% 360
95% 374
98% 384
99% 389
100% 392 (longest request)
|
|
查看留言>>
|
|
|
aiCache发行业界首个基于软件的SSL网页加速
|
|
2010-01-12
|
|
|
|
aiCache软件每秒提交上万个SSL会话，允许用户在他们自己的服务器上运行软件，从而替代昂贵的硬件。aiCache完全支持SSL终端到云计算的虚拟化。
最新发布
PRLog（新闻稿）——2010年1月11日——aiCache发行旗舰产品第六版，aiCache网络应用加速器，使市场中的网络加速进入了新水平。构架支持并且线性扩展到无数的CPU核心，可以真正使HTTP和HTTPS流量无限扩展。
aiCache解决了业界存在的SSL速度慢和昂贵的专用硬件需求的问题，它可以把高速SSL终端带到普通硬件的云和数据中心上。
对于云计算和虚拟化技术的用户来说，这无疑是很有帮助的。虚拟化解决方案，如亚马逊网络服务不需要专用硬件。云计算用户无需操作大规模的SSL安装启用。aiCache消除了在虚拟化实例运行的SSL障碍，提供了专用的硬件级别性能。
第六版支持每秒处理超过25万非加密的内容，支持每秒超过30,000 RSA1024 SSL会话，并且只在一台服务器上运行。
aiCache管理HTTPS和HTTP流量，减轻网络服务器的加密工作量，同时提供卓越的客户体验，并提供全套业界领先的aiCache Web应用程序加速功能。
新版本完全支持以前配置文件的语法，使得现有客户可以简单地插入替换的二进制文件。
有亚马逊网站服务和Rightscale的云计算客户，将可享用第六版的功能，并且不会额外收费。
“实行一个缓存层几乎是扩展网站的新标准了。在数据库层应用memcached缓存系统，在Web服务器层应用aiCache，将为您提供能最大程度扩展的架构。为SSL站点得到这些益处对大家都是双赢”aiCache总裁Max Robbins说道。
|
|
查看留言>>
|
|