Tag Archive for 'yo2'

使博客访问速度更快的技巧

多网友会发现,大家同样是使用 Yo2博客服务,怎么自己的博客打开速度比人家慢?嗯,虽然都是跑同样的服务器,同样的线路,但博客的设置各不相同,这样就会出现差距了。我作为 Yo2 的开发员,我给大家介绍一下如何设置自己的博客可以取得更快的访问速度 :)

  1. 不要频繁进入管理后台更改设置
    • 很多网友喜欢经常到管理后台更改一下设置,看到文章有点瑕疵就重新编辑发布等等,这些操作都会触发 Yo2 CDN 系统更新博客缓存,如果一个博客的缓存被更新,那么就需要重新生成这些博客页面了,打开一个缓存页面的速度比重新生成一个页面快很多。所以大家要改改这些习惯
  2. 打开博客的缓存加速功能
    • 在管理后台-设置-输出,可以打开博客的缓存加速功能,大家可以根据所使用的模板进行选择,那些页面组成部分可以让系统缓存(比如我的博客只有页首因为有当前页面标识的功能,而侧栏和页尾的内容都可以是固定不变的,那么我就打开了侧栏和页尾的缓存加速)。开启了页面组成部分的缓存加速,可以让在重新生成页面时,可以直接使用已缓存的页面组成部分,减少了部分的数据操作,相对生产页面所消耗的时间就得到减少了
  3. 尽量减少第三方网站提供的 JavaScript 、图片调用
    • 有些网友喜欢在自己的侧栏加入很多第三方网站提供的服务,比如播放器、Rss、图片、访问统计等等,甚至有人会加入多个统计代码。博客确实很多东西了,但随之而来的速度被拖慢了,如果调用了一些国外的服务,对博客的访问速度影响更大。我之前有加入过 google 的访问统计,但这个有比较长时间的页面显示延迟,为了获取更快的速度,我把它删了。之前我还是用了 FeedSky 的 JavaScript 方式显示订阅按钮,后来直接写成 Html 格式,都可以加快页面的显示速度。我建议大家尽可能把第三方的调用控制在2个以内
  4. 减少首页(列表页面)的文章数量
    • 文章中可能包含了一些图片,在单个文章显示时的速度还挺快,但首页(文章列表)中包含的文章数量多的话,也就代表该页要显示的图片是列表上的文章所包含总和。还有部分网友是使用其他相册提供的图片服务,如果这些相册的访问速度慢,同样对自己的博客有影响。我建议把首页(文章列表)一页显示的文章数量控制在 5 个左右,确实需要一下显示多个文章的话,可以选择摘要输出(不显示图片)
  5. 使用 CNAME 绑定域名(收费用户)
    • Yo2 在各个网络都部署有独立服务器节点,只有使用 CNAME 方式进行域名解析,才能使用 Yo2 的 CDN 服务进行访问加速。对于使用了 A记录方式直接解析到我们其中一台服务器,那么所有网友访问你的博客也只限于在一台服务器上,并且这台服务器的线路不一定是最快的。如果你要使用 domain.com 这的域名进行绑定,而域名服务器又无法给 domain.com 提供 CNAME 方式的解析,我建议你更换绑定的域名为 www.domain.com 或 blog.domain.com ,又或者更换域名的解析服务器,改为使用 DnsPod 这样的域名解析服务

完成 ! 希望这些技巧能让你更好的使用 Yo2 博客服务 :)

国内 CDN 服务介绍

C
DN是一个经策略性部署的整体系统,能够帮助用户解决分布式存储、负载均衡、网络请求的重定向和内容管理等问题。  其目的是通过在现有的Internet中增加一层新的网络架构,将网站的内容发布到最接近用户的网络“边缘”,使用户可以就近取得所需的内容, 解决 Internet 网络拥塞状况,提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均而产生的用户访问网站 响应速度慢的根本原因。

引用:http://www.chinacache.com/viewtechnique.asp?id=15

目前国内主要的 CDN服务商有北京蓝汛网宿科技北京快网浙江联存CDN联盟等数家,服务商之间的技术实力还有一定差距,产品线比较长的有北京蓝汛和网宿等几家,全国分布节点数量多,可提供多种加速服务,但相对价格也比较昂贵。一般小型 CDN 服务商较有价格优势,但产品线比较短,不能提供一些比较高端的应用,基本是做静态文件加速服务。

普通的静态文件加速服务技术门槛低,只需要配备智能DNS解析服务,使用 squid (内容缓存系统) 在各地区部署一定数量的服务器节点,即可投入服务。所以现在有越来越多的 IDC 服务商开始建立自己的 CDN 网络,但因为还在起步阶段,带宽总容量低,所部署的节点数量比较少,主要分布在各大城市,并且节点的网络质量参次不齐。

更多的服务商加入到 CDN 行列,已经把带宽资费拉到普通多线带宽的水平。现在越来越多的网站开始使用 CDN 服务,给网站的静态内容(如:图片)进行加速,而动态内容依然使用自有多线服务器提供访问服务。而有部分大型网站则开始建立自己的 CDN 网络 (如:6.cn) 自主 CDN 网络的可控性高,可以根据自己的各项服务需求进行细节调整,但维护成本则相对购买第三方的 CDN 服务要高得多。

我们需要根据自身网站的实际需求、技术能力和资金,综合分析应该怎样使用 CDN 服务进行访问加速。因为 CDN 服务商只能提供一定域名数量的加速服务,如果你的网站需要给大量的域名访问进行加速,则需要自行建立 CDN 网络了。(如果您需要进一步了解 CDN 服务,我是能够提供一些建议的 :)

---------------------------------------------------------

Yo2 是博客服务商,需要给大量的博客进行访问加速,所以选择自行建立 CDN 网络。并且在服务器节点的页面缓存技术方面,相对普通的 CDN 服务商有一定的优势,我们的缓存系统已支持动态页面的加速服务,除了少量要求即时动态处理的数据以外,其他的博客文章页面、模板、图片等内容均已使用缓存加速。

虽然我们的 CDN 网络还是起步阶段,所部署的服务器节点有限,但我们选择的机房带宽要求都是很高的,同省区的访问速度 < 20Ms,跨省区访问的速度在30~50Ms之间。在 Yo2 的成长过程中,我们将进一步完善自己的 CDN 网络,以提供更快的博客访问速度 :)

httperf 一个高性能的压力测试工具

ttperf is a tool for measuring web server performance. It provides a flexible facility for generating various HTTP workloads and for measuring server performance. The focus of httperf is not on implementing one particular benchmark but on providing a robust, high-performance tool that facilitates the construction of both micro- and macro-level benchmarks. The three distinguishing characteristics of httperf are its robustness, which includes the ability to generate and sustain server overload, support for the HTTP/1.1 and SSL protocols, and its extensibility to new workload generators and performance measurements.

Httperf 是一个高效的 http 压力测试工具,使用它可以模拟出超过1千的并发访问,能充分测试出 web server 的性能。而之前使用的 siege 测试工具则未能突破 500 个并发测试(如果您知道如何可以实现,请告诉我)

使用 httperf 应该能了解到自己编写 yo2cache 软件性能极限如何了 :)

以下是 gzip 格式访问的测试数据(因缓存文件以 gzip 格式保存,所以性能是最高的)

oneoo@oneoo-pc:~/Desktop$ httperf --server oneoo.com --num-conns 2000 --add-header "accept-encoding: gzip"
httperf --client=0/1 --server=oneoo.com --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --add-header='accept-encoding: gzip' --num-conns=2000 --num-calls=1
Maximum connect burst length: 1

Total: connections 2000 requests 2000 replies 2000 test-duration 1.304 s

Connection rate: 1533.7 conn/s (0.7 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 0.6 avg 0.7 max 6.3 median 0.5 stddev 0.2
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 1533.7 req/s (0.7 ms/req)
Request size [B]: 81.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.6 transfer 0.0
Reply size [B]: header 302.0 content 10482.0 footer 0.0 (total 10784.0)
Reply status: 1xx=0 2xx=2000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.29 system 1.01 (user 22.4% system 77.6% total 100.0%)
Net I/O: 16273.4 KB/s (133.3*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

以下是 deflate (2级压缩率)格式访问的统计数据(需要从 gzip 解压,再压缩为 deflate 的数据处理)

oneoo@oneoo-pc:~/Desktop$ httperf --server oneoo.com --num-conns 2000 --add-header "accept-encoding: deflate"
httperf --client=0/1 --server=oneoo.com --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --add-header='accept-encoding: deflate' --num-conns=2000 --num-calls=1
Maximum connect burst length: 1

Total: connections 2000 requests 2000 replies 2000 test-duration 4.113 s

Connection rate: 486.2 conn/s (2.1 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 2.0 avg 2.1 max 11.8 median 2.5 stddev 0.3
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 486.2 req/s (2.1 ms/req)
Request size [B]: 84.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.6 transfer 1.5
Reply size [B]: header 305.0 content 11014.0 footer 0.0 (total 11319.0)
Reply status: 1xx=0 2xx=2000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.91 system 3.20 (user 22.2% system 77.8% total 100.0%)
Net I/O: 5414.3 KB/s (44.4*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

以下是 deflate (4级压缩率)格式访问的统计数据

oneoo@oneoo-pc:~/Desktop$ httperf --server oneoo.com --num-conns 2000 --add-header "accept-encoding: deflate"
httperf --client=0/1 --server=oneoo.com --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --add-header='accept-encoding: deflate' --num-conns=2000 --num-calls=1
Maximum connect burst length: 1

Total: connections 2000 requests 2000 replies 2000 test-duration 5.329 s

Connection rate: 375.3 conn/s (2.7 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 2.6 avg 2.7 max 32.8 median 2.5 stddev 0.7
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 375.3 req/s (2.7 ms/req)
Request size [B]: 84.0

Reply rate [replies/s]: min 374.8 avg 374.8 max 374.8 stddev 0.0 (1 samples)
Reply time [ms]: response 0.6 transfer 2.0
Reply size [B]: header 305.0 content 10457.0 footer 0.0 (total 10762.0)
Reply status: 1xx=0 2xx=2000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 1.29 system 4.01 (user 24.2% system 75.2% total 99.4%)
Net I/O: 3975.4 KB/s (32.6*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

以下是文本格式访问的统计数据

oneoo@oneoo-pc:~/Desktop$ httperf --server oneoo.com --num-conns 2000 --add-header "accept-encoding: normal"
httperf --client=0/1 --server=oneoo.com --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --add-header='accept-encoding: normal' --num-conns=2000 --num-calls=1
Maximum connect burst length: 1

Total: connections 2000 requests 2000 replies 2000 test-duration 2.349 s

Connection rate: 851.3 conn/s (1.2 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 1.1 avg 1.2 max 5.8 median 1.5 stddev 0.2
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 851.3 req/s (1.2 ms/req)
Request size [B]: 83.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.6 transfer 0.6
Reply size [B]: header 278.0 content 42562.0 footer 0.0 (total 42840.0)
Reply status: 1xx=0 2xx=2000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.62 system 1.73 (user 26.2% system 73.7% total 99.9%)
Net I/O: 35683.0 KB/s (292.3*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

从以上数据可以看到 yo2cache 性能挺好的,最高能达到每秒 1500 个并发处理。性能瓶颈是出现在缓存数据的解压与压缩处理上,如果缓存空间足够大的话,可以考虑保存多种格式的缓存数据,就能解决这个瓶颈问题。

而在 deflate 数据压缩方面,因为2级压缩率与4级压缩率所产生的数据量差距不大,但并发性能有一定差距,可以考虑使用 2 级压缩率。

无条件为你

手:梁静茹

歌词:

爱你等于拥有 一片天空任何风吹草动

都有你存在其中 自然而然的轻松

一路到 夏天的尾声无所谓 到过于激动

我们有笑容 我们曾心动不再是 无动于衷

无条件为你 不顾明天的安稳为你变坚强 相信你的眼神

不敢想 不敢问 有一天坏的可能

无条件为你 放弃单独的旅程为你坚强 就不怕牺牲

我的灵魂 如此沸腾 为我爱的人

喜欢复杂还是 习惯单纯我愿尽力完成

你在我心中几分 难以形容的责任

爱一个人 付出才会完整无条件

越爱就越深 永远不分 啊

这首歌不是我送给老婆听的,而是送给所有的 Yo2 用户,希望大家喜欢。

Yo2服务的是一个群体,我们需要为这个群体负起责任!

关于 Yo2 关键字处理

们开始启用关键字过滤程序,是我们实在不希望做的。Yo2 代表着国内BSP的创新,我们的服务一直都比较有个性的,也因此碰过不少壁。无奈在现在的国oo情之下,如果要能够继续提供稳定快速的博客服务,也只好采取一定的屏蔽策略。

也许你会发现我们Yo2实行的并不是传统的简单关键字替换操作,我们是为了尽量减少对博客文章的影响,才专门为此开发的功能,只对小部分重点,且日常少用到关键字才做 ** 的替换操作,而其他只是加入干扰码处理。干扰码处理,基本不影响正常的文章阅读。

汉字的自由组合程度很高,这个我们是知道的。也是因此我们才采取了分级处理的方案,并且对于部分关键字不会列入到审核统计数据中,目的就是为了尽量减少正常文章被程序误判的可能性。我们每天都在根据文章审核列表中出现的关键字,对系统的词汇表进行优化,尽量减少对博客正常浏览的影响。

这些过滤程序对 Feed 无效,其他 Feed 服务商读取到的数据都是原汁原味的,当然可能其他的 Feed 服务也会有关键字替换的可能。

WJC 通常是程序自动从互联网上截取页面内容,并寻找其中包含的关键字,如果包含有一定的数量就会触发,递交到WJ手上,WJ并通知机oo房要求删oo除此文章。如果一个IP频密出现这些文章,WJ就很可能要求机oo房停oo止该服务了。

我们为此就更换过三次机房和IP,1月的事情还历历在目。尤其这段时间,WJ的处理更加严格。而我们也只好做出这样的对策,希望用户们可以体谅,谢谢!

(注: 文中 oo 部分为我自己个人的屏蔽操作,与Yo2系统无关)