「Noah Veltman的午餐会」关于性能和网络

分享给朋友:

在BBC工作期间,Noah Veltman 为编辑人员和设计师们组织了一系列午餐小会。这些小型讲座的内容不是关于如何写代码或者完成某个具体项目,而是让这些非工程人员了解在新闻实践中经常会遇到的技术话题,让技术问题不再那么高深莫测。当非工程人员对基础的技术有所了解后,“这个项目要花多长时间?”、“我们如何做出这样的东西?”、“我们要如何妥协才能在技术上实现它?”如此这般的问题就会被有效率的双向对话所替代。

出于这样的目标,这个系列中将不太涉及真正的写代码的教学。但对那些想好好钻研开发的人来说,这个系列将提供非常值得尝试的努力方向。这些都是真实发生在午餐会上的讨论,所以也许变成文字后少了一些临场感,但无论是对于程序员、记者还是设计师来说,这些都仍然是很有帮助的、值得学习的材料。

Noah Veltman现任纽约WNYC电台数据新闻团队的开发人员,擅长交互图表、地图和基于数据的新闻应用开发。此前他曾获得Knight-Mozilla开放新闻奖学金并在伦敦BBC NEWS工作。数据新闻网将陆续推出Noah Veltman午餐会的其他资源。

【Noah Veltman的午餐会】系列由数据新闻网独家授权编译,更多该系列文章:
【Noah Veltman的午餐会】Excel vs. Database
【Noah Veltman的午餐会】制作在线地图
【Noah Veltman的午餐会】网页抓取
【Noah Veltman的午餐会】避免数据清理时的失误
【Noah Veltman的午餐会】XML与JSON:特征大比拼
【Noah Veltman的午餐会】关于API——非程序员们看过来

什么是我们所讲的“性能”?

当人们谈论网络的性能时,他们通常会谈论这些东西:

  • 加载时间:当用户尝试加载一个页面,或者页面中的特定文件,需要花费多长时间?当用户向服务器发送一个请求,需要多久才有响应?这个问题的根本答案就在于文件的大小—如果你让用户下载更多数据,就将需要更长的时间。当然还有很多其他的因素,等下我们会谈到。
  • 效率:速度和效率有着密切的关系。在网络性能的运行下,效率是指代码运行完成某一特定的任务最少的工作量。代码编写的过程有许多种,不同运行过程代码的效率范围从非常有效到无法想象的低,虽然它们都具有相同的运行结果,但需要不同的时间和计算能力(一个小的性能差异都会产生很大影响)。效率会为用户转化为更快的速度,但它也意味着服务器可以在同一时间里处理更多的用户。
  • 浏览器性能:当我们要求浏览器做的工作越多,浏览器存在延误或崩溃的潜在风险就越大。你也许认为用户点击一个按钮,很多任务就可以立马完成。然而事实是,如果有大量的Java程序脚本的介入,或是带有复杂矢量图形,甚至用老式浏览器运行,任务就不可能如想的那样一瞬间完成。最坏的情况就是用户盯着加载的旋转轮子20秒钟,然后得到一个提示关闭脚本的命令,因为它耗费的时间太长。 

影响网络性能的因素

静态与动态:准备做个好厨师

服务器给用户发送东西时,有时只是发送一个静态文件(静态文件又称为“平面”文件;它只是个普通的文件,通常是文本)。当用户发出请求图像命令后,服务器会将静态文件发回。这个文件可能也许会很大,但从服务器运行角度看处理这个请求的速度是非常快的。服务器只需要把文件拿下架子并开始传输。在这种情况下,服务器是像一台自动售货机。你只需要输入代码,就可以得到一个预先包装好的零食。这在内容不需要更改的情况下是十分方便的。

其他时候,服务器不只是在准备静态文件。相反,服务器还具有数据库和其他设施。当请求命令传入时,它进入“厨房”,在发送回传信息前,从头组装所需的文件。这就是我们所讨论的动态指令:没有文件,只有一些指导人们如何创建文件的说明。动态指令通常会需要耗费较长的时间。在这种情况下,服务器就好像一个高档的定制餐厅。它可以做很多定制和动态更改的东西,但每个订单都需要耗费一定时间来运作,一旦有大量的订单排队等待就会成为问题。

当服务器被要求对每个指令做越多的工作,它就越会因很多用户的同时使用,迅速变得不堪重负。想象一下,用餐高峰期的餐厅厨房,或是露西在巧克力工厂,传货时无法跟上传送带。当服务器为每个用户处理更多指令时,就意味着增加了长时间的延迟和在高峰时期崩溃的风险,这就需要更多的服务器来处理相同数量的用户,或将两者都进行兼顾。

任何一个策划过大型宴会或在饭店工作过的人,都知道这种情况下还有一种解决方法。为了能够同时满足数百个客人的需求,你需要提前做尽可能多的准备工作,,切菜、搅拌和提前烹饪什么都可以,然后把准备好的菜品放进冰箱,在最后一刻进行收尾工作即可。同样地,网络运行服务也是如此。你可通过提前准备的烹饪拥有两全其美的结果。因此当你明确了订单需要什么时,你就可以提前准备一个静态文件。当服务器收到请求命令时,它只需要在短时间内做一点工作,就好像在烤肉上留下点烤过的痕迹这么简单。

还有很多不同策略和注意事项的静态文件缓存的动态内容,都超出了本文讨论的范围。只要记住最重要的是仔细思考哪些内容是真正的动态,需求总是要从头烹调,还有什么内容可以提前烹调就足够了。

例如,假设你开发了一个新闻应用程序需要收集美国劳动统计局(Bureau of Labor Statistics)发布的季度失业数据。你可以建立一个数据库,当每个季度发布数据时进行存储,并设置一个程序,每当用户打开页面都会从数据库获得数据。不过这将是很愚蠢的行为,因为数据在三个月的周期内是相同的(网络服务器夸张的定义:查询同一数据库上百万次,你都会得到相同的结果)。最好的办法是你在每次新的数据进来时都生成新的纯文本文件,然后应用到程序中。

缩减下载量

要求用户下载越多的数据就意味着越多的加载时间。下面几个方法可以用来缩减下载量的大小:

剔除你不需要的东西。当你使用一个不是你创建的数据文件,它里面通常充满了你不需要的数据。你可能下载了一个带有22列普查的CSV并发版本系统(Concurrent Versions System),但你的应用程序只引用了其中2行。或者你可能下载了一份包含指定纬经度的十二组数据的地理数据文件,可是你只需要三个组。剔除无关的数据!这可能看起来是一个微不足道的差别,毕竟,这只是文本。但若将这种差异乘以100000行,再乘以100000的用户,它就会看起来很大。同样地,在你使用应用程序时,哪怕是有1 MB的外部资源,你都应该认真考虑是否需要该资源或是否有另一种方法。

别让用户下载一切。比方说你有一些包含不同信息的丰富的web应用程序。也许总的下载量很大,但你可以将程序优化,这样用户就不需要等待下载所有东西。比如你可以写一些介绍性文字、图表和一幅大的互动式地图。如果你通过Ajax的后台页面加载地图,你的用户至少可以开始阅读的介绍文字和图表,而不是盯着一个正在加载的空白页。在适当的时候按需求下载东西——如果你的应用有数以百计可点击的程序,每个都占有很大的图片,那就不要让每位用户下载所有的项目,因为他们可能只会点击其中的一两个项目。

关于缓存的东西。不要让用户一次又一次下载相同的文件。在评估性能时,要记得什么可以先下载后缓存,哪些不能缓存。要知道让别人下载100种不同的图像和要求别人把同一图像加载100次是有区别的。

服务于更快的源头。自己的服务器可能不是传送文件到用户的最快的方式,因为用户自己的缓存文件肯定会更快。但如果拥有一个CDN(Content Delivery Network即内容分发网络)速度也许就会快得多。在很多情况下,使用一个外部供应商会使速度更快(除非你的服务器真的很棒,YouTube的视频加载速度可能都没你快)。虽然这些方法都有缺点,但他们可以有效的缓解你自己的服务器的负载,而且将获取的内容更快的传送到用户手中。

浏览器重任:JavaScript,SVGs等

除了下载时间,另一个性能被认为是在用户的浏览器内运行的内容(即所谓的“客户端”)。这时浏览器需要负载大量尖端的JavaScript,SVG图形,WebGL,和其他花哨的软件。当你有了最初的想法,一定要确保他们在老式浏览器运作正常。比如运用Chrome浏览器我们可以很容易获取想要的东西,然而有人在IE8浏览器运行这些美好的想法,就会导致浏览器产生混乱和延迟、不停的转换,甚至彻底崩溃。古老与现代的浏览器之间的性能差距每天都在增长。请注意,我指的不是浏览器的兼容性,这只是另一个小麻烦;我只想说明在一些理论下特定适用的浏览器,可能在其他浏览器中的体验很糟糕。你需要担心的是对低性能浏览器满意的用户会是多少,当然这将很大程度上取决于您的特定受众,这使我想到下面一点…

你无法控制的事情

如何快速顺利的让你的用户获取内容这也取决于许多你控制不了的事,特别是他们使用的浏览器和设备。这是你需要了解你的用户的原因之一。

他们是谁如何获得数据,如何访问你的站点,这些都决定不同因素对性能的影响。没有一个放之四海而皆准的答案,只能依据情况而定。如果你有很多IE8的用户,你需要更关注JavaScript的复杂性而不是新浏览器的用户。如果你有很多的移动用户,你则需要更关注文件的大小,特别是如果你住在移动数据下载速度缓慢而且费用昂贵的国家。如果你的每个用户都有全新的MacBook电脑,最新版本的Chrome,100 mbps的光纤连接,和一个30英寸的显示器 ,那也许你就不需要过于担心,只需要开个披萨派对庆祝一下。

为什么会产生性能问题?

性能低效=糟糕的用户体验。用户不喜欢等待东西。在这样的世界上,移动用户的份额与日俱增,因为大量的下载或复杂浏览器交互的需求放大,限制了移动数据和浏览器。当你坐在温暖的办公室用着不错的电脑享受极速的宽带连接时,就很容易忽略这一点。设身处地想想,谁愿意在火车上用手机加载文章,或链接糟糕的公共WiFi网络。

服务器的成本。保持文件大小和服务器负载量不仅有利于用户,也有利于你的预算。事实上,一个一般的Web服务器是不贵的,但是如果你拥有一个大型新闻机构耗费大量流量,你就可以使用更大马力的服务器,当然成本也会随之迅速增加。

服务器的限制性。不管是最大、最坏或是最巧妙地的Web服务器的配置阵列都将应对足够的压力。如果你让你的服务器做许多额外的工作来满足页面的请求,同时还发送大量不必要的文件,这样会增加每个用户的压力和风险,服务器将进行最大输出(可以询问你的系统是什么让它晚上还在运作)。

高性能的权衡

有大量有利于提升Web应用程序建设的性能。但在、这个过程中也有收益递减。你可以总是优化性能,总有数据字节剃掉,或算法改写。这并总是都是值得的;性能优化需要从其他的地方获取时间和资源,比如你的实际内容。在明确了你的用户,你的需要以及你的可用资源后再决定关注性能的哪些不同方面,以及什么程度就可以算作“足够好”。

应用程序在追求更好性能的同时也影响着自己的未来发展。有时候,更好的性能意味着更少的程序、更简洁的代码、更简单的架构以及更少的故障:程序变得更容易维护、改善和重复使用。但有时提高性能意味着黑客和复杂性,这会让应用程序变得难以维护、提高和重用。对于用户来说高性能需要在幕后运作很长的过程,这些过程需要时间和人力的支持。当在考虑提高潜在的复杂体系的性能时,请先了解你的团队,明确事物相对价值。

精神食粮

了解你的用户。能够决定性能程度的唯一因素就是了解你的用户。了解他们所使用的浏览器和设备,以及它们同内容之间是如何长期相互作用的,这都会暗示你哪些因素是应该优先改进的,哪些是不需要改进的。

认识自己。这里的词语是“权衡”。当然,有很多程序有着更好的性能。但多数时候程序的性能和其他因素之间是平衡的。你有什么资源?你的最后期限是什么?用六个月或者一年发展状况建立某种方式对你来说意味着什么?

早点开始思考性能。避免性能出现问题的最佳时间是在项目初始。如果你选择不去担心它,直到结束,那你的设计和开发的决策很可能会使你陷入困境。这是需要一点点的预防和其他。当项目还是雏形时,不用担心未来你不知道什么是关键性能问题,你只需要尝试预测他们可能是什么,提出谨慎的应对方案以及替代计划,。

请教开发者。影响网络性能的原因有时并不是那么显而易见的,设计与性能的相关问题往往交织在一起,密不可分。如果有疑问,可以请教身边友好的web开发人员。让他们早期一起参与创建详细的参数,在你和开发者理智验证你的技术假设之前花费数周研究项目将是一场灾难。

 

本文译者:朱缘

作者简介

数据新闻网

数据新闻网以引介全球范围内最顶尖的数据新闻实践为初衷,以推动数据开放及媒体革新为宗旨,面向中国的新闻从业者、媒体管理者、新传教育者以及对传媒感兴趣的设计师、程序员,提供线上信息平台与线下交流机会。