性能可扩展性分析具有Web Workers的JavaScript应用程序外文翻译资料

性能可扩展性分析具有Web Workers的JavaScript应用程序

关键词：HTML5，网络Web Workers，JavaScript，网络应用程序，并行语言，多线程

抽象Web应用程序利用新的基于标准的技术越来越接近本机应用程序的性能。最近的HTML5标准除其他外还包括Web Works API，它允许在多个线程或worker上执行JavaScript应用程序。但是，浏览器的JavaScript虚拟机的内部构件不会暴露浏览器中工作线程和运行线程之间的直接关系以及处理器中逻辑内核的利用率。因此，开发人员不知道性能在不同环境中的实际规模和并行JavaScript代码上的最佳Web Workers数是多少。本文介绍了并行Web应用的性能可扩展性分析。我们重点关注两个代表不同Web Workers执行模式的案例研究。我们的分析显示了在不同的并行处理器微体系结构和市场上三种主要的Web浏览器上的性能扩展。此外，我们还研究了协同运行应用程序对Web应用程序性能的影响。这些结果为将来自动找出最佳Web Workers数量的方法提供了见解，这些Web Workers在性能和资源使用之间提供最佳权衡，以保持系统响应能力和用户体验，尤其是在系统工作负载发生意外变化的环境中。

1. 简介

Web Workers遵循万维网联盟开发的新HTML5标准，以满足当前和未来平台、Web内容和云服务的需求。HTML5提供了新的HTML元素、库扩展和API来进一步利用底层硬件，并减少了安装第三方插件的需要。因此，当前Web Workers显示出与本机应用程序类似的性能。

一些编程语言通过使用特定的多线程API（例如CUDA、OpenMP）来利用并行性，这些API的性能扩展与底层硬件资源密切相关。其他需要虚拟机(例如Erlang、Java) 的并行编程语言增加了性能可扩展性的偏差，因为它不仅与硬件资源有关，而且还与虚拟机的内部构件有关 [1、2] 。本文研究的重点是JavaScript，一种解释语言，主要用于开发在Web浏览器中执行的Web应用程序。HTML5特别关注JavaScript的支持，并带来了一种新的机制和称为WebWorlds[6] 的API。即使JavaScript遵循单线程执行模型，WebWorks API也允许多个JavaScript代码同时在后台线程中运行，从现在开始，通过消息传递与主线程进行通信。随着JavaScript Web应用程序在Web浏览器的虚拟机之上运行，它增加了虚拟机上运行的语言性能扩展的不可预测性。

通过使用Web Worker API，开发人员负责提取并正确地将其表达在Web中应用程序，与自动从顺序代码中提取并行度的JavaScript引擎的线程级推测技术不同。程序员目前使用处理器资源可用性作为启发式，以找出应产生多少Web Workers来获得最高性能。虽然HTML5支持利用硬件加速和更好地使用重新源，但JavaScript无法检索底层硬件规范，例如包含在CPU中的逻辑内核（即硬件线程）的数量。主要浏览器供应商以不同的方式解决此限制 [12] 。GoogleChrome、Safari和Opera在浏览器的导航器对象（称为导航器hardwareConcurrency）上实现了一个新属性，以获得硬件线程的数量，而不考虑系统工作负载。其他Web浏览器（如InternetExplorer和FireFox）还不支持它，用户必须开发一个基准来估计可用逻辑核心的数量。但是，这种估计对两种系统工作负载变化都很敏感，因为其他共同运行的应用程序可能会偏离基准的性能，并且优化JavaScript引擎，因为某些浏览器可以对特定基准进行高度优化，但其他浏览器对其解释不当。因此，这两种方法都向开发人员提供有偏向的信息，以确定任何特定Web应用的Web Workers的最佳数量。

本文介绍了由多个Web Workers组成的JavaScript Web应用程序的第一次性能可扩展性分析。本文介绍了一种根据Web Workers执行模型对Web应用进行分类的方法。我们比较了并行微体系结构、单线程和多线程多核以及Chrome和其他两种主要Web浏览器之间的性能可扩展性。此外，还分析了协同运行应用程序对高度并行的JavaScript Web应用程序性能的影响。这些结果为未来的方法提供了见解，以找出利用并行度的最佳Web Workers数量。

1. 相关工作

一些研究使用单线程基准来描述JavaScript程序。其他作者提出了JavaScript代码的细粒度并行化。弗图纳等人 [3] 分析并行任务和事件的潜在加速极限。马丁森等人实现并分析浏览器的JavaScript引擎的线程-级别-推测以利用并行处理器。最后，Watanabe等人描述了一种使用WebWorker并行化交互式动画JavaScript的技术，但作者没有研究其可扩展性。

这些工作都没有集中于分析基于Web Workers的Web应用程序的性能可扩展性或主要Web浏览器之间的相关差异。

1. Web Workers执行模型分类

并行JavaScript Web应用程序由负责用户界面的主线程和后台线程组成，由于访问限制，Web Workers无法执行该操作，网络Web Workers的后台线程旨在计算密集型任务以保持响应能力并增强用户体验。虽然可以在Web Worker之间创建通信通道，但在本文中，我们关注的是Web Worker与父线程之间的默认消息传递。此外，Web Workers被分为两类：专职Web Workers，又称标准Web Workers，只能由产生它的脚本访问；和共享工作线程，可从同一域中运行的任何脚本访问。其他新兴类型的Web Workers仍在试验中 [6] 。

我们介绍了一种基于Web Workers执行模型的并行Web应用分类，无论Web Workers来源如何。实际上，这项工作的重点是Web应用程序代码行为以及如何利用并行性：

• 单一Web Workers：所有计算密集型任务均由单一Web Workers完成。例如，视频游戏可以卸载像AI和物理这样的CPU密集型任务，以维持响应能力和帧速率。包括适合在多个线程中运行的多个计算密集型任务的Web应用程序被传送到其他类别之一。
• 多个异步工作负载：大型/连续工作负载分布在可用工作负载之间，以便并行处理，如拼写检查。这些应用程序在Web Workers之间没有同步点。一旦给定的工作线程通知父线程任务已完成，就会将新的工作负载传递给工作线程进行处理。
• 多个同步工作程序：固有的并行代码，如图像/视频处理，用于在工作程序之间具有同步点，如新帧的呈现。每个新工作负载（一个框架）都可以拆分成多个作业（切片），由不同的Web Workers处理。但是，在所有Web Workers完成工作之前，Web Workers不能直接开始处理新框架。因此，这些应用程序可以呈现空闲Web Workers的时间段，甚至具有挂起的帧。

1. 框架

我们使用的个人计算机具有IntelR CoreTM i7-3960 i7处理器（3.3GHz）（3.3GHz）和六个超线程内核（共十二个逻辑内核），以及16 GBDDRAM-III和一个运行MicrosoftR WindowsTM Server2008 R2的NvidiaR GTX560视频卡。我们使用Windows，因为它是在桌面计算机中运行Web应用程序的最终用户最广泛使用的操作系统 [9] 。已禁用所有非关键服务和应用程序，以尽可能防止测量中的任何偏差。

我们使用进程资源管理器v15。

Web应用在三个主要Web浏览器的更新版本中运行：GoogleChrome v42.0.2311.90m（我们实验中的默认浏览器）、MozillaFirefox v37.0.2和微软InternetExplorer v11.0.9600.16476，新版本的IE。

没有由Web Workers组成的标准JavaScript基准。几个著名的Web应用和Web浏览器门户提供了并行的JavaScript演示。其中大部分都是由出色的Web Workers实施的。实际上，我们的分析与Web Workers是专职还是共享无关，但它集中在具有多个Web Workers的Web应用程序的执行模型上，参见第三部分。我们已经运行了几个没有人工交互要求的Web应用程序。

本文深入分析了两个案例，由于空间的限制，我们分别使用了一个代表性的基准。尽管其他Web应用程序的特定性能数量可能不同，但本白皮书中显示的趋势相同：

• 多个异步工作程序：hashBruteforcer[13]，HashApp，是一个具有计算MD5哈希的专用工作程序的Web应用程序。我们使用默认配置和数据集。从给定的128位MD5编码输入，应用程序使用暴力攻击来解码字符串。因此，Web Workers执行连续的CPU密集工作负载。
• 多个同步工作程序：raytracerweb应用程序，RayApp，执行高度密集的中央处理器数学计算，模拟场景的组成部分，如环境光和阴影，以渲染每一帧。我们使用默认配置，但将默认画布大小扩大到300x300像素。场景分割成多个切片，这些切片取决于画布的大小。因此，在我们的实验中，每个帧渲染由15个切片组成，这些切片沿着可配置的池大小的专用工作线程分布。我们对其他尺寸的画布进行了实验，显示了不同的性能数字，但有相似的趋势。

这两个基准都被稍作修改，进行了从1到20个Web Worker的实验。我们修正了这个限制，因为它是Firefox支持的最大数量的Web Workers。我们通过在每次实验后关闭和重新启动Web浏览器来防止由于先前的实验（主要是由于内部优化和垃圾收集器问题）导致的测量偏差。最后，我们从每个实验运行30秒的10次运行中获得平均结果，时间足以达到稳定的性能。

1. 实验结果

A.微结构影响

图1（a）和图1（b）分别描述了HashApp和RayApp在两种不同微结构中运行的性能。也就是说，多线程 (n核MT) 和单线程 (n核ST) 多核处理器，是CPU中可用的n个核。Y轴表示性能测量，单位为每秒字符串数（对于HashApp）和每秒帧数（对于RayApp）。X轴表示Web Workers的数量。

与使用多线程多核体系结构（开放圆线）相比，在多个单线程核心（实心圆线）上运行HashApp的性能更高，因为共享硬件资源上的争用更少。与多线程多核体系结构相比，在具有单线程核心的处理器上的执行表现出大约两倍的性能。在这两种情况下，性能线性扩展，直到每个核心都运行一个Web Workers。使用更多的Web Workers显示出边际或非绩效改进。硬件资源的争用是持续的，因为线程之间没有同步障碍，因此Web Workers不断要求共享硬件资源。然而，在两个微体系结构中运行比逻辑内核更多的Web Workers不会降低性能。

相比之下，RayApp在两个微体系结构上呈现相似的性能可扩展性，如图1b所示。性能增量受制于同步工作程序执行模型的每个渲染帧的固有障碍，如第三节所述。也就是说，由于Web W

剩余内容已隐藏，支付完成后下载完整资料

英语原文共 4 页，剩余内容已隐藏，支付完成后下载完整资料

资料编号：[596002]，资料为PDF文档或Word文档，PDF文档可免费转换为Word