|
一个慢腾腾的网站，可能会让许多关键的访客和用户失去耐心，造成交易量降低、品牌形象变差，以及更高的“跳出率”。目前看来，无论网站是否提供在线交易的功能和服务，性能优化都已经不再是可选项，而是必选项。
那么，应该如何更加科学地评价Web性能优化技术及其背后的CDN厂商呢？
性能评价方法：“模拟测试” 和 “RUM”
在讨论“性能评价”这个话题的时候，我们都会非常频繁地说到这样一个词：模拟测试（Synthetic Measurements）。
尽管现在业界都在使用真实客户监测（RUM：Real User Monitor）的数据，来衡量真实的用户体验，但RUM并不是一个放之四海而皆准的一个标准。因为：
在某些场景下，我们无法得到真实用户的数据，因此，“模拟测试”就成为了我们的另外一个选择。
”模拟测试“怎么做？本文列举一些方法，希望能够帮助大家更好地分析、评价。
考虑到CDN已然是Web网站的标配，因此在如下案例方法中，都假设已使用CDN，而且都处于“上线前（Pre-Production）”的环境之下。
性能评测及优化的5个步骤
步骤1：搭建环境
当对某一Web站点可能使用的多个CDN厂商进行评估时，每一个厂商都应该提供一个不需要客户进行任何改动的模拟环境。
并且，CDN厂商应该提供“测试”域名，来尽可能真实地模拟生产环境的网站。
举个例子：假设待评测网站域名是 ，CDN厂商服务域名是 xxxx.com，那么厂商应提供的临时测试域名通常为：
步骤2：环境确认
临时测试域名应该是“完全”与生产用站点对应匹配的。我们建议的检查清单如下，大家可按此进行检查：
对象数量一致，在测试域名下的对象数量，应该和真实网站所包含的对象数量一致；
文件总大小一致，测试网站的字节数应该和真实网站一致。当然，由于每一个厂商采用的压缩方式不同，其字节数可以比真实网站“略小”；
缓存规则一致，所有CDN厂商使用的缓存规则应该要一致，因为有一些厂商可以缓存动态请求（比如缓存html页面的整体框架）。
如果某个厂商可以做到这一点但是其他厂商不行，那么这个测试的公允性就值得质疑，因为那些采取更加激进的缓存策略的厂商就会获得优势。所以在正式开始之前，我们必须对配置进行一次全面的核查。
步骤3：性能测试方案的设定
在测试环境妥善搭建之后，下一步就是要对真实的性能测试方案进行设定。建议在设置“正确”的测试方案之前，应思考如下问题：
1.测试的类型是什么？
就像我们提及的，在对没有处于真实生产阶段的网站配置进行评估的时候，是没有“真实用户”的，没有真实用户，就没有真实用户数据。这时候，我们就需要采取综合测试的方式来进行衡量。
综合测试可以提供一个“清洁屋”式的测试环境，来方便我们对性能进行衡量。但是，即便是综合测试，也是分许多种类的，如：骨干网络性能测试、最后一公里测试、蜂窝网络测试（也称移动网络测试）等等。
相对于骨干网络性能测试，最后一公里测试可能更加能够反映真实的用户体验情况；而如果网站或者公司拥有大量的移动端接入客户，那么就一定要在移动网络下进行性能测试。这也会引发关于不同供应商对移动端进行加速的能力和技术的讨论。
2.采用什么样的性能测试平台？
总体来说，推荐使用在你所处行业内有一定业务经验和业绩的第三方测试平台。做一些简单的调查，看看有哪些公司在你所处的行业内发布过与性能有关的信息、指数或者文章。
不要使用某个厂商内部的特定测试工具，否则测试的结果会带有非常明显的倾向性。一个好的模拟测试平台应该拥有一批稳定的分布于全国/全球的测试节点，这些测试节点最好能和您业务重点区域相一致。
注意：这些测试节点应该在浏览器上模拟真实用户的种种行为。有些测试平台使用仿真浏览器，而不是真实浏览器。仿真浏览器只能捕捉网络时间，而真实的浏览器则可以获取前端（或“渲染”）时间、浏览器缓存和并行链接等数据。
因此，如果有条件，还是要使用“真实浏览器”进行测试。
3.测试应该在哪里进行？
测试地点应该包括“跨域分发”（也就是说跨越洲际和国家）以及“域内分发”两种情况。在这里，需要再次强调的是，由于业务不同和所面对的用户类型不同，这两种测试都需要进行考虑。
如果是面向全球的业务，源站服务器位于北美，而需要向全球用户进行分发，那么就应该对美国和美国以外的远距离地点进行性能测试，而不是只关注美国国内的用户体验。
如果是仅仅面向国内的业务，则也需要考虑不同运营商的问题，至少目前为止，电信、联通之间的”墙“，还很牢固。
4.测试对象应该包括什么？
典型的网站交互行为会包含对多个页面的访问和使用，这是用户在网站上完成一个任务或行为的通常模式，这也是我们需要进行测试的对象，这样做是出于两个目的：
首先，这能够模拟一个最终用户可能在真实情景下所体会到的性能；
其次，这能够帮助您了解一个优化解决方案可以给网站带来怎样的收益。
可能有个优化方案A可以给某一种特定类型的页面带来好处，而另一种优化方案B可能会给其他类型页面带来改善，这取决于站点的结构、数据或者对象的特性。
如果仅局限于对单个对象进行测试、并以此判断缓存的收益，或者仅仅关注“基础”的html页面、而不对其他种种特性复杂的对象、微小的API交互行为进行测试，这样很可能导致以偏概全，也无法观测到解决方案的真实效果，以及是否真的适用。
5.测试应该跑多久？
测试时间应该包括高峰时段和非高峰时段。一般来说，3到5天的数据总和是比较具有参考价值的。如果测试的时间过短，比如说只有几个小时，那么由于网络状况的不稳定和用户数量的变化没有得到真实反映，测试得到的数据也很难是真实的。
6.测试的频率应该是怎样？
高频率的测试能够反映流量高峰时的场景，在这种情况下，缓存中的内容总是新的，且可以命中；而低频率的测试则反映出非流量高峰时的情况，此时，内容可能是从你的源站一次一次抓取回来的。
一般情况下，我们建议每30分钟发起一次测试，这样可以反映出一个比较真实的流量模拟。
最后还要注意，测试期间源站带宽的用量可能有所上升，请提前做好准备。 （编辑：核心网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
