tableau server 9.0 可扩展性： 为大规模自助服务分析提供强劲动力
TRANSCRIPT
Neelesh Kamkolkar，产品经理
Tableau Server 9.0 可扩展性： 为大规模自助服务分析提供强劲动力
2
目录动机 .......................................................................................................................4
背景 .......................................................................................................................4
概要 .......................................................................................................................5
Tableau Server 是 Tableau Public 的强力后盾 ....................................................6
在云级别进行内部测试 ........................................................................................7
新引入的体系结构更新 ........................................................................................8
新的最低硬件要求 ................................................................................................9
性能改进 ...............................................................................................................9
并行查询 ..........................................................................................................9
查询融合 ........................................................................................................10
缓存服务器 – 外部查询缓存 .........................................................................10
数据引擎的横向扩展规模 ..................................................................................12
其他改进 .............................................................................................................12
可扩展性测试目标 ..............................................................................................12
测试方法和方法体系 ..........................................................................................13
虚拟机 .................................................................................................................14
物理机 .................................................................................................................14
系统饱和和等待时间 ..........................................................................................15
Little 法则 .......................................................................................................17
等待时间 ........................................................................................................17
工作负载组合的变化 ..........................................................................................18
新方法体系 ....................................................................................................19
测试工作簿示例 .............................................................................................20
3
数据提取特征 .................................................................................................... 21
标准化的隔离环境 ............................................................................................. 22
部署拓扑 ............................................................................................................ 22
测量与报告 ........................................................................................................ 23
事务 .................................................................................................................... 24
吞吐量 ................................................................................................................ 24
饱和吞吐量 ........................................................................................................ 24
响应时间 ............................................................................................................ 24
并发用户数 ........................................................................................................ 24
结果 .................................................................................................................... 25
比较 Tableau Server 9.0 版与 8.3 版的可扩展性 ............................................. 25
以线性方式扩展的吞吐量 ................................................................................. 26
总体硬件观察结果 ............................................................................................. 26
内存 ............................................................................................................... 27
磁盘吞吐量 ................................................................................................... 28
网络使用情况 ............................................................................................... 28
在单台 8 核计算机上进行的比较 ................................................................ 29
更高的内存要求 ............................................................................................ 31
高可用性所产生的影响 ..................................................................................... 32
运用结果 ............................................................................................................ 33
后台程序方面的注意事项 ................................................................................. 33
最佳做法 – 自行进行规模测试 ......................................................................... 34
TabJolt - 可扩展性测试工具 ......................................................................... 34
有关在实际环境中进行优化的最佳做法 .......................................................... 35
总结 .................................................................................................................... 36
4
动机
我们的很多客户如今都做出了一个战略性的选择，即实现大规模自助服务分析。 这
种情况下，自然我们的客户（其 IT 部门、业务部门等）就希望了解 Tableau Server
如何通过扩展来支持他们在全球范围内的所有用户。 此外，客户还希望提前规划容
量和硬件预算分配，以满足在更大范围内采用 Tableau 的需要。
在我们的 Tableau 9.0 发布流程中，我们设定了一个目标，即了解与 Tableau Server
8.3 相比，Tableau Server 9.0 在可扩展性特征方面表现如何。 我们还希望了解
Tableau Server 9.0 是否会线性扩展，以及负载的增加对其可用性有何影响。
背景
如果您习惯于传统商业智能或者刚开始接触 Tableau，则了解 Tableau 在工作原理方
面与传统商业智能之间的一些核心差异，这或许会对您有所助益。
与为满足一组有限的需求而设计和开发的传统商业智能报告不同，Tableau 可视化
为提升交互性而打造。 用户可以在 Tableau 中就自己的数据提出任意数量的问题，
而不必经历传统的软件开发生命周期来创建新的可视化。
为了实现大规模自助服务分析，并帮助确保用户始终参与分析流程，我们在现有的
创新型技术基础上开发出了 Tableau Server 9.0。
Tableau 的问世彻底改变了由来已久的“先查询，再可视化”理念。 其享有专利的
技术（包括 VizQL™）可将查询和可视化无缝整合成一个流程。
得益于此，用户可以专注于自己的业务问题和查询关于自己数据的问题。 他们不必
再采用老一套方法：选择数据，然后从预先制作好的各类图表中进行挑选。 现在，
用户可以反复不断地拖放维度、混合数据集并基于各种度量生成计算结果。 在此过
程中，Tableau 会生成清晰的可视化结果，同时顺畅运行所需的查询。 您在尝试了
解 Tableau Server 的可扩展性时，应考虑到这种与以往不同的模式。
如果您以前从事的是传统商业智能领域，您可能习惯于旨在满足特定服务级别协议
(SLA) 的负载测试静态报告。 静态报告基于固定范围内的一组固定查询，往往由开
发人员花数周时间逐一优化。
5
而 Tableau 可视化技术则可以根据用户执行的试探性操作，重新生成或提交新的查
询。 得益于它的很多优化，快速检索数据成为可能，由此帮助确保用户自始至终都
能参与分析流程，而不用苦等查询结果。 对于 Tableau 9.0，我们在性能方面投入巨
大，此外还在很多其他方面也进行了大举投入，从而确保用户始终参与分析流程。
本白皮书阐释了 Tableau Server 9.0 在采用各种配置时，随着用户负载的增加，其运
行和扩展情况会如何，以及其在可扩展性方面与 Tableau Server 8.3 相比表现如何。
概要
Tableau 9.0 是我们公司历史上最宏大的一个版本。 从 2014 年 11 月开始，也就是
9.0 发布周期之初，我们就开始对仍在开发之中的新功能进行性能和可扩展性测试。
我们以迭代方式，将针对新功能的设计反馈纳入到 Tableau Server 9.0 的性能和负载
测试中。
影响性能和可扩展性的因素有很多，包括工作簿设计、服务器配置、基础架构调优
和网络。
按照我们的目标和测试方法，我们证实了以下结果：
1. Tableau Server 9.0 在所测试的所有情形中都能以近乎线性的方式扩展。
2. 与 8.3 版相比，Tableau Server 9.0 的吞吐量提升了 200% 以上，其响应时间也大
幅缩短。
3. 与 8.3 版相比，Tableau Server 9.0 的内存和网络利用率有所提升。
由于 Tableau Server 9.0 中新引入了很多体系结构方面的更新，因此我们根据对新式
服务器设计和常见客户使用情形的迭代测试结果，选择了一些群集拓扑。 在下表
（图 1）中，每一行代表着一种 Tableau Server 9.0 群集配置，具体有：1 个节点 - 16
个核心、2 个节点 - 32 个核心以及 3 个节点 - 48 个核心。
我们观察到，在各种配置下，Tableau Server 9.0 在系统饱和时可以支持以下数目的
用户。 下文中的并发用户数目表表示按照 Little 法则，在服务器饱和时并发访问可
视化并与其交互的最终用户数目。
6
在我们的测试情形中，我们假定在一个组织或部门内，并发访问可视化并与其交互
的用户在最终用户总数中大约占 10%。
根据我们的测试和工作负载，我们观察到，在部署到包含 16 个核心的单台计算机上
时，Tableau Server 9.0 总共可以支持最多 927 名用户；在部署到包含 48 个核心、
3 个节点的群集环境中时，可以通过扩展最多支持总共 2809 名用户，如下表中所示。
图 1： Tableau Server 9.0 可扩展性摘要
此外，我们还证实了 Tableau Server 9.0 可以通过在群集中添加更多节点，以近乎线
性的方式加以扩展。
虽然在上表中我们假定用户并发率为 10%（也就是说，组织中同时查看可视化或与
其交互的用户数在总用户数中预计占 10%），但您的用户并发率水平可能与此不
同。 某些情况下，我们曾观察到并发率低至 1%。
在本白皮书中，我们首先将提供一些有关 Tableau Server 可扩展性的真实示例。 接
着将说明 Tableau Server 9.0 在体系结构方面的一些新变化，还会介绍我们的测试方
法，以帮助您更好地了解 Tableau Server 9.0 的可扩展性。 最后，我们将就如何在
您的环境中，应用我们在试验中总结的经验教训提供一些指导。
Tableau Server 是 Tableau Public 的强力后盾
目前，很多组织纷纷在云端以及整个企业范围内部署 Tableau Server。 这包括在
Tableau Software 进行的一些部署。
Tableau Public 是我们免费提供的一款优异云服务，任何用户都可以使用它向 Web
发布交互数据。 Tableau Public 可以支持众多数量的工作簿、撰稿人和实时视图。
最近，我们将数据提取规模从 100 万行增加到 1,000 万行，将每位 Tableau Public 用
户的总存储空间增加到 10GB。
7
凭借超过 100,000 名撰稿人、超过 4.5 亿个视图以及 500,000 项可视化，Tableau
Public 对我们成功做到“使用我们自己的产品”起到了关键作用。
在云级别进行内部测试
使用我们自己的产品来完成我们的日常工作，是 Tableau 文化中的一项核心价值观。
Tableau Public 为我们提供了一个云级测试环境，供我们用来测试 Tableau Server 的
新版本。 在产品发布流程中，我们将 Tableau Server 预发布软件部署到了 Tableau
Public。 这样，我们不仅可以在任务关键型生产环境中大规模部署我们的产品，还
可以了解、发现和修复与可扩展性相关的问题。
我们在 9.0 Beta 周期中将 Tableau Server 9.0 部署到了 Tableau Public。 得益于此，
我们有充足的机会来了解新体系结构在真实生产情形中的扩展情况，而且这还有助
于我们及时发现并修复问题，而不至于在面向企业客户发行的产品中还留有问题。
图 2： 有关 Tableau Public 使用情况的时间点视图
Tableau Public 自其面世以来已经为用户展示了 4.5 亿次数据，单是上个月就展示
了超过 2,700 万次。 它还支持超过 100,000 名撰稿人，他们已经制作并向 Tableau
Public 发布了超过 500,000 个可视化。
8
Tableau Public 配置与 Tableau Server 的企业级部署实例类似，但有几点不同。 所
有 Tableau Public 用户均受一个固定的数据提取规模限制，即不得超过 1,000 万行数
据。 由于 Tableau Public 是一个开放、免费的平台，因此使用它的用户在访问公共
数据时不会受到与 Tableau Server 同等级别的安全保护。 此外，Tableau Public 采用
一种称作撰稿人配置文件的自定义前端来管理工作簿，而不是采用应用程序服务器
(Vizportal) 进程。
不过，Tableau Public 每一天都运行数以万计的查询，因此，虽然数据规模相对较
小，但数据极为多样化。
Tableau Public 以 Tableau Server 9.0 为技术后盾，已成为我们在 Tableau Server 9.0
中所引入的体系结构更新的强健测试平台。
新引入的体系结构更新
在 Tableau Server 9.0 中，很多新功能都植根于一个强大的体系结构基础，这一基
础对 Tableau Server 已有的企业级体系结构进行了延伸和扩展。 我们向 Tableau
Server 添加了一些新的服务器进程，以支持这些新功能。
要理解如何管理 Tableau Server 9.0 的可扩展性，务必要熟悉这些组件并了解它们所
发挥的作用。 为简单起见，在图 3 中，我们将多个服务器进程汇总成了一个由多个
较高级别服务层组构成的逻辑体系结构。
图 3： 单个服务器节点的逻辑体系结构
9
多个服务器进程通过协同工作，在各个层提供服务。 网关是负责将流量定向到所有
服务器节点的组件。 您可以在服务器群集前面部署一个外部负载均衡器（图 3 中未
显示），并在每个节点上都配置一个网关，以进一步提高可用性。
用户层包括内容管理服务、可视化、数据提供程序服务和 API 服务。
存储层包含内容存储库以及一个新的文件存储进程。 结构化关系数据（例如元数
据）、权限信息以及 Tableau 工作簿都存储在该存储库中。 文件存储进程用于存储
用户的数据（Tableau 数据提取），并在整个群集范围内实现数据提取文件冗余。
管理层提供一组服务，供服务器管理员用来有效管理群集和确保高可用性。
有关各个服务器进程的详情，请参阅管理指南。
新的最低硬件要求
由于服务器上引入了用来支持新功能的新服务，因此 64 位服务器安装程序的最低要
求已经提高到 4 个核心和 8GB RAM。 虽然最低安装要求为 4 个核心，但我们并不建
议使用 4 核计算机对单节点服务器进行负载或规模测试。 单台 4 核服务器通常用于小
规模试用和原型设计。 对于大规模企业部署，应考虑对每个节点采用 16 核服务器。
性能改进
性能改进有助于缩短最终用户等待的响应时间，推动在整个公司范围内的使用。 整
个分析流程都进行了性能改进。 不过，有很多可变因素会影响性能，因此您所得到
的结果可能会有所不同，具体取决于您的实际情况。 在下文中，我们将介绍几项重
要改进，这些改进有助于指导您如何部署才能同时满足性能和规模需求。
并行查询
并行查询的设计宗旨是让 Tableau 能够更有效地使用后端数据库，从而加快用户与
可视化的交互。 在 Tableau Server 9.0 中，我们现在可以查看发往后端数据库的可
视化查询，在适当的情况下，还可以消除这些查询中的重复数据，并且可以同时发
出多个查询。
10
这意味着，Tableau Server 可以与您的后端数据库建立多个连接，并且在条件允许
时可以利用更多数据库资源。 得益于此，兼容的数据库可以并行地处理查询，而不
用按顺序逐个处理，从而大大加快查询结果的生成速度。 至于这项功能对您是否有
益，具体取决于您的后端数据库如何处理交给它们的并行工作。
查询融合
顾名思义，这是指我们将仪表板中的多个查询尽可能融合到一起，以减少发送到后
端数据库的查询数量。 这对于实时连接特别有益。 不过，如果您的仪表板未生成任
何可合并的查询，那这种优化对您将没有助益。
图 4： Tableau Server 9.0 中的查询融合
缓存服务器 – 外部查询缓存
如果您刚刚加载了一个工作簿并首次运行全部查询，那在很多情况下，当您关闭并
重新打开工作簿时，后端的数据可能不会更改。
11
如果您的数据新鲜度和使用情形恰好具备这种特征，则最终用户第二次加载这些工
作簿时速度将大大加快。 借助外部查询缓存，我们可以将以前的查询所生成的结果
保存下来，以便此后用户可以快速访问它们。
缓存服务器进程以 Redis 为技术后盾，Redis 是一种高度可扩展的键值缓存，很多互
联网规模的大型提供商都采用这种缓存。
图 5： 缓存工作原理简图
此图简要显示了各进程间，通过缓存服务器进行的交互情况。 为简单起见，未显示
不与缓存服务器进程交互的其他进程。
每个进程都有一个称作查询缓存的内存缓存。 服务器进程首先会尝试在查询缓存中
查找其所需内容。 如果在内存缓存中未找到其所需的内容，它会尝试在缓存服务器
中进行查找。 如果结果位于缓存服务器中，则会将其复制到内存缓存中并返回。 如
果不在这两个位置，则会对数据库运行查询，结果将缓存在缓存服务器中以及需要
该结果进程的内存缓存中。 整个群集中，所有服务器进程和节点都可以访问每个缓
存服务器中的缓存。
12
数据引擎的横向扩展规模
数据引擎是负责将数据提取加载到内存中和执行查询的组件，Tableau Server 9.0 版
数据引擎新增了一项特性，也就是它现在可以横向扩展到群集中的 N 个节点。 以
前，它最多只能扩展到 2 个节点。 得益于此，您还可以在使用 Tableau 数据提取时
构建高度可扩展的群集。
其他改进
此外，我们还在整个数据引擎中做了很多其他改进，具体有：增加了对并行查询
（如上所述）和矢量化的支持、改进了呈现功能、加快了数据提取的创建速度、
支持在数据服务器中使用临时表，等等。
整个 Tableau 9.0 产品线新增了很多功能和特性。 在上面的部分中，我们仅仅了解
了一些关键的新服务器组件以及它们发挥的作用。
可扩展性测试目标
早在 2014 年 11 月，我们就开始了解，随着负载增加，Tableau Server 9.0 在可扩展
性方面相比 Tableau Server 8.3 将呈现出哪些特点。 我们还希望了解 Tableau Server
9.0 是否以线性方式扩展，以及随着负载的增加，它是否很难或者完全无法使平均响
应时间保持在不超过三秒的水平。
我们的目标不是与本白皮书的上一更新版本在测试方法、工作负载和工作负载组合
上保持一致。 我们需要根据针对新版本规划的设计和体系结构变更，不断更新和说
明所有这些信息。 例如，我们专注于可运用 Tableau Server 9.0 新增功能的工作负
载，从客户角度而言，这种做法非常务实。
由于工作负载和测试方法都发生了改变（本文稍后将进行说明），因此不应将本白
皮书中公布的 Tableau Server 可扩展性结果与先前白皮书中公布的可扩展性结果相
提并论。 由于测试条件发生了巨大变化，无法进行直接比较。
在本文中，为便于同之前发布的可扩展性结果进行比较，我们明确在相同硬件的基
础上，对 Tableau Server 9.0 和 Tableau Server 8.3 执行了相同的测试。 两组测试都
遵循相同的方法体系。
13
测试方法和方法体系
我们为撰写本文而采用的许多方法体系都受到了常用最佳做法，还有 Tableau Server
9.0 设计变更的启发。 例如，除了使用面向客户的工作簿外，我们还精心选择了其
他一些工作簿并将其加入测试组合。 这是因为，我们需要相应的工作簿，用以展示
明确运用新增功能的用户操作。
总体而言，有多种不同的工作负载可在 Tableau Server 上运行，从最终用户加载可
视化，到自动订阅，再到数据提取刷新作业，不一而足。 在方法体系中，我们主要
专注于最终用户工作负载，因为我们的目标之一是了解系统在饱和状态下可支持多
少最终用户。
在制定整体容量规划时，除了要考虑并发用户负载外，还应考虑运行后台程序所需
的容量。 一般而言，需要在计算机上部署 N/2 到 N/4 个后台程序，其中“N”表示
计算机上的核心数量。 关于后台程序的详细指南和注意事项已在服务器管理指南中
说明。
在面向用户的层中，Tableau Server 上用于处理用户请求的主要进程是 VizQL Server
和改进的新版应用程序服务器。 此外，还有其他一些进程，例如 API 服务器，该
进程只处理 API 客户端请求。 在我们的测试方法体系中，我们已将这些进程排除在
外，以便专注于分析最终用户工作负载。
根据设计，VizQL Server 进程会绑定在 CPU 上，因此需要分配充足的资源才能确保
达到适当的性能和可扩展性。
14
虚拟机
许多客户将 Tableau Server 部署在虚拟机上，并成功运行了可扩展式部署。 本白皮
书不会详尽区分物理与虚拟基础架构环境，亦不会详细比较当前市面上的各种虚拟
化平台。 在虚拟化平台上，可获得的性能和可扩展性还取决于配置，以及针对特
定平台的虚拟化参数所做的调整。 例如，在 VMware ESX™ 上，不建议对 Tableau
Server 应用 CPU 过载，因为当工作负载加重时，其他应用程序可能会争用资源，
导致 Tableau Server 的资源需求无法得到满足。 正确做法是考虑在具有专用 CPU
亲缘性的虚拟机上运行 Tableau Server。 您应查阅特定于虚拟化平台供应商的白皮
书，了解适用于所选虚拟化平台的最佳做法。 下面列出了 VMware 的一些示例白皮
书供您参考。
Performance Best Practices for vSphere 5.5 guide（vSphere 5.5 性能最佳做法指南）
Deploying Extremely Latency-Sensitive Applications in vSphere 5.5（在 vSphere 5.5 中
部署对延迟极为敏感的应用程序）
无论在任何虚拟化平台上，Tableau Server 9.0 都作为服务器类应用程序运行。 它需
要充足的计算资源，应当在部署时注意这一点。 建议您向虚拟化平台供应商寻求指
导，了解如何对您的服务器部署执行调优。
物理机
每次物理机部署都会因多种因素而存在差异。 在这些实验中，我们希望尽量降低因
虚拟化平台及其特定调整所带来的可变性。 因此，我们将 Tableau Server 9.0 群集
部署在采用相同硬件配置的物理机上，并将物理机置于隔离网络的实验室中。
在每个测试中，我们依次按多种群集拓扑，对 16、32、48 个核心运行预定义的一组
工作负载和负载组合。 在每次迭代中，我们使用 JMX 记录关键绩效指标，此外还
记录多种系统指标和应用程序服务器指标。 对于每个测试，我们都寻找数据的相关
性，并分析系统在用户负载不断增加时的表现。 每次迭代结束时，根据体系结构的
变化，我们都会与体系结构团队共同审查测试结果，据以更新未来的测试和方法。
在敏捷开发过程中，我们还发现并修复了一系列可扩展性缺陷。
15
为确定用于最终测试的部署拓扑，我们开展了许多实验。 在这些实验中，我们研究
了各种服务器组件交互如何影响服务器的可扩展性。 本白皮书将公布这些结果。
总之，对于每种拓扑，我们都运行了 1,000 次测试迭代，完成每次迭代大约需要两
个小时。 在负载测试期间，我们测量并收集了一系列系统指标和应用程序指标，
用于了解在向群集中添加更多工作软件时，系统如何随负载的增加而扩展。
系统饱和与等待时间
通常，基础架构团队将需要测量和监视各个服务器进程和服务器的 CPU 利用率。
一般而言，基础架构团队需要留出足够的 CPU 容量空间来应对猝发的负载。
例如，从基础架构角度而言，如果 CPU 利用率为 80%，则充分表明系统已经饱和。
但是，Tableau Server 9.0 是一款重型工具，需要充足的计算容量才能正常运行。 有
时，我们会发现服务器群集中的某些进程占用了 CPU 周期的 100%，这种情况并不
鲜见。 这是设计使然，基础架构团队在制定监视策略时应注意这一点。
在负载测试中，我们按以下标准测定系统饱和点：不仅要达到峰值饱和吞吐量，
而且平均响应时间上限不超过三秒。 如果平均延迟超过三秒，我们将忽略进一步增
加的客户端吞吐量，因为我们希望让报告数据保守一些。
就我们的实验而言，这意味着 Tableau Server 允许在系统中增加更多用户负载，
但要以对进入系统的新用户增加延迟作为代价。 此外，对于我们选择测量的饱和点，
我们设立了错误率（套接字、HTTP 或其他方面）小于 1% 的目标。
16
以下摘要视图显示了为比较 Tableau 8.3 和 Tableau 9.0，我们在系统饱和点测得的数
据。 该视图显示了一系列 KPI，例如 TPS、平均响应时间、并发用户数（采用 Little
法则）和错误率。
图 6： 一种显示系统饱和点的测试方案
我们确定了饱和时的吞吐量和响应时间后，便根据 Little 法则推断系统上的并发用
户数目。
17
Little 法则
执行这些测试是为了确定系统达到最大容量的时刻，包括此时的用户总数。 Little 法
则可以帮助我们很好地展现这个时刻。
设想一家小咖啡馆中，一名咖啡师每次只能服务一名顾客。 顾客进来，买咖啡，
然后离开。 一杯普通的咖啡很快便能供上，饮品越复杂，需要等待的时间越长。
此外，如果这名咖啡师还需要额外花时间查看饮品调制说明，那服务用户所花的总
时间就是查看说明的时间加上制作饮品所需的时间。
服务自始至终所用的时间，这决定着他们能以多快的速度为顾客提供和完成服务。
但如果进来的顾客数超过离开的顾客数，咖啡店最终会人满为患，使得其他人没法
进来。 这时咖啡店便饱和了。 决定店内任一时刻最大顾客数目的可变因素有：顾客
在店内停留的时间、其饮品单的复杂程度以及为其提供服务的工作人员数。
为了将咖啡店与 Tableau Server 进行类比，我们可以设想每名咖啡师代表一个
VizQL Server 进程。 可视化加载任务或者与仪表板交互的最终用户就好比是咖啡。
这样的话，并发加载可视化以及与可视化交互的最终用户数目就是平均响应时间与
饱和吞吐量的乘积。
并发用户数 = 平均响应时间 x 饱和吞吐量
您可能在想，按照这种类比的话，可以代表 CPU 的会是什么呢？ 我们可以将 CPU
想象成咖啡师实际调制饮品时所用的硬件，即咖啡机、榨汁机、搅拌器、咖啡出售
机等。咖啡机一次能倒出一份浓缩咖啡，还是能倒出四份浓缩咖啡，对咖啡师能以
多高的效率服务客户有很大的影响。
等待时间
通常，在其响应时间或负载测试方案中，负载和性能测试团队会加入所谓的“等待时
间”。 虽然这是一个很切实际的概念，但在分析情景中，等待时间可能很难预测。
18
例如，观察可视化时，我可以快速找到所需的内容，这时等待时间就非常短。 不
过，这可能会引发漫长、迭代性的数据探索。 完全可以将这种额外的探索视作最终
用户等待时间。
传统方法以此来类比最终用户的“延迟”。 对于我们的方法，我们决定测试是否真
正实现了并发性，因而就没有在我们的测试中加入具体的等待时间延迟。 实际上，
我们的等待时间为零。
对于用户渐增方案，有很多模型可以采用。 我们采用的是每秒增加一名用户，在他
们的操作之间不设等待时间，直到我们达到上文中定义的饱和状态为止。
工作负载组合的变化
我们在发布周期中早早就开始执行性能和可扩展性测试。 在整个过程中，我们做出
的一些关键决定成为了我们方法的依据。 我们希望所采用的工作负载组合可以确保
我们在服务器中执行新的功能，并且能代表一种符合实际的使用情形，包括采用真
实的客户工作簿。
我们在就同一主题发布的上一篇白皮书中提到，事实证明，将工作负载界定或归类
为简单/复杂/复杂性适中是颇具挑战性的事情。 这常常会导致对这些词语的含义产
生主观性的解读。
例如，某工作簿外观上看似简单，但它所需的数据可能十分复杂。 这种情况下它就
是一种计算密集型工作簿，我们在 Tableau Server 9.0 中所进行的产品投资就会让它
大受裨益。
为了简化和执行新功能，我们采用 (a) 多种不同的实际工作簿（包括客户工作簿），
以及 (b) 查看工作簿和与工作簿交互的不同用户，设计了一种可靠的工作负载组合。
19
下图显示了这种负载组合的视觉表示形式，因此您可以从中看出我们如何为测试混
合工作负载。
图 7： 显示的是用于表示 Tableau Server 9.0 多种工作负载类型的负载组合
新方法体系
这种工作负载组合摒弃了我们在以往白皮书中采用的“简单、复杂性适中、复杂”
工作簿的概念。 我们不再是使用一种类型（简单、复杂、复杂性适中）的工作簿将
服务器运行至饱和状态，也不再采用由查看者和交互者组成的用户组合，而是要让
工作负载组合更符合实际。
我们引入了一个工作簿池，池中的工作簿复杂性不一。 此池包含执行 Tableau
Server 全新功能的工作簿，此外还包含客户工作簿。
工作簿可能会使用浏览器呈现或服务器呈现功能，具体取决于工作簿的设计。 浏览
器呈现是 Tableau Server 早期版本中存在的一项功能。 借助此功能，现代浏览器可
以执行一部分工作簿呈现工作，从而减轻了服务器的工作负载。
如果工作簿非常复杂，出于性能考虑，Tableau 客户端会将较繁重的呈现工作推送
到服务器上。 服务器会通过执行这种繁重呈现工作加以响应，并且仅发回构成可视
化的贴片。 这称作服务器呈现。
20
因此，Tableau 可视化可以在适当的情况下使用现代浏览器功能，也可将较繁重的工
作推送到服务器。 具体如何选择取决于工作簿的复杂性，但用户不会觉察到这些。
您之所以不应将以前针对 8.1 版发布的结果与本白皮书中针对 9.0 版发布的结果进
行比较，更新后的工作负载组合，以及从工作簿池中进行选择的新方法体系就是其
中的一些主要原因。
测试工作簿示例
虽然我们无法发布我们所用的示例工作簿（因为他们包含客户工作簿），但这里列
举了正在使用的一些仪表板类型示例。
用户交互工作负载包括：通过 Tableau Story Point 、包含各种层的已填充地图以及
越来越多的标记进行导航；通过索引选择分类筛选器；选项卡切换；筛选操作等。
下面列举了一个用于测试的 Story Point 工作簿示例。
图 8： 显示喜马拉雅山攀登和事故趋势的 Story Point 工作簿。
My Himalayan StoryWelcome to thefourteen
8000 overview. Everest and Cho Oyuare the most Climbedmountain
Yet they are the safestof the 8000ers
Everest is climbed inthe Spring
Cho Oyu is climbed inthe Fall
Expeditions are on therise in the last 30years
Cho Oyu and Everestreceive most of thevisits
What are the maincauses?
Poeple die on Everestbecause of 2 maincauses
A lot less death onCho Oyu comparedto Everest
Annapurna I
Annap..
An.. Cho Oyu Dhaulagiri I Everest Kangchenjunga
Ka..
Ka.. Lhotse
LhotseShar Makalu Manaslu
Yalung Kan
g
1969
1979
1985
1991
1997
2004
2009
2004
1958
1980
1986
1992
1998
2004
1955
1970
1978
1984
1990
1996
2002
2008
1933
1950
1960
1967
1973
1979
1985
1991
1997
2003
1925
1951
1980
1986
1992
1998
2004
1989
1989
1973
1979
1985
1991
1998
2004
2001
1965
1983
1989
2007
1961
1974
1981
1987
1993
1999
2005
1954
1973
1979
1985
1991
1997
2003
1974
1985
0
200
400
600
# M
EM
BE
RS
0
20
40
60
80
100
# E
XP
ED
ITIO
N
32 2.25 51.1371.17
156
13.0140
3.38
165
10.3521 1.86 91.17111.00
35 3.49 1.0011 1.1736 2.89
40 3.71 151.11
# of climbers and # of Expeditions growth over time
Kangchenjunga
Annapurna I
-> Click on a peak to findmore about it
8000ers map
0 500 1,000 1,500 2,000 2,500 3,000# MEMBERS ON SUMMIT
0
50
100
150
Num
ber O
f Mem
ber D
eath
s
Everest
Cho OyuDhaulagiri I
Lhotse
More Red means higher % ofDeath per 100 summitter
Darker Green means safer
Summit to Death ratio
1900
s
1910
s
1920
s
1930
s
1940
s
1950
s
1960
s
1970
s
1980
s
1990
s
2000
s
2010
s
0
20
40
Num
ber O
f Mem
ber D
eath
s
Death trends over time
Season NameAutumn Spring Summer Winter 0.0 3.8
Member to death ratio (X member for 1 death)
Peak NameAnnapurna I
Annapurna I - East..
Annapurna I - Mid..
Cho Oyu
Dhaulagiri I
Everest
Kangchenjunga
Kangchenjunga C..
Kangchenjunga So..
Lhotse
Lhotse Middle
Lhotse Shar
Makalu
Manaslu
Yalung KangMax. HEIGHT in Meters8,000 to 8,850
21
图 9： 包含示例交互的出租车乘载次数工作簿
上面显示的另一个测试工作簿外观上看似简单，但在以前的版本中需要很长时间才
能加载完毕。 这是因为对于 4 个视图中的每一个，都需要另外重新运行同样的查
询。 该工作簿基于一个出租车乘载数据集，我们所执行的具体交互如下： 通过索引
选择分类筛选器、选项卡切换、在日历中选择 11 月、选择 17 日、筛选到现金、
切换选项卡。
其他测试工作簿旨在测试繁重负载条件下的性能，它们采用 1,000,000 个标记来显
示各种趋势分析。
所有这些工作簿均使用数据提取制作。
数据提取特征
我们选择了使用基于数据提取的工作簿进行测试。 这样就消除了实时后端数据源可
能给测试带来的任何可变性。
符合实际的实时连接方案会因数据库使用方式，还有数据库本身上所运行的其他负
载而有显著差异。 我们采用的数据提取所包含的数据从 3,000 行到 9,300 万行
（数据提取规模大约为 3.5GB）不一。
22
除工作负载之外，还有很多其他可变因素可能会影响系统性能和可扩展性。 为了管理
这种可变性并提高各次测试运行间的一致性，我们对测试的几个方面进行了标准化。
标准化的隔离环境
首先，我们对硬件进行了标准化。 在我们性能实验室中具有以下规格的物理机上，
我们运行了这些可扩展性测试。
图 10： 基准环境的硬件规格
部署拓扑
我们在除主节点之外的各个群集节点（工作软件）上维护以下服务器进程配置：
图 11： 显示用于可扩展性测试的服务器部署拓扑。
23
我们使用可生成上述工作负载组合的负载生成器来扩展工作负载。 在测试执行期
间，我们使用 JMX 收集了系统指标、性能指标和应用程序指标。 我们将结果保存
在一个关系数据存储中， 然后使用 Tableau Desktop 对这些结果进行了分析。 下图
显示的是有关测试执行情况的逻辑视图，不过该视图经过了简化。 简化的方面仅限
于每个群集节点并未显示计算机上运行的所有服务器进程。
图 12： 经过简化的测试环境逻辑视图
每次测试迭代都会收集大量数据，但是在我们开始探讨结果之前，先要了解一些指
标和定义。
测量与报告
为了解系统性能与可扩展性，我们测量了一系列指标，其中包括 CPU、内存和磁盘
的相关系统指标，以及响应时间、吞吐量、运行持续时间等性能与可扩展性指标。
要理解本白皮书中讨论的数据，我们先来快速了解一些定义。
24
事务
事务是一种最终用户体验，指他们加载 Tableau 可视化和/或与视图交互。 举例来
说，如果您正在加载可视化，则加载可视化的整个请求集 (HTTP) 即代表一项事务。
事务的响应时间从客户端的角度（即从产生负载的位置）进行测量和报告。
吞吐量
吞吐量是指每秒执行的事务数 (TPS)。 例如，5 TPS = 在 24 小时的时间里执行了
432,000 个事务。 举例来说，Tableau Public 在一天时间里支持的页面浏览量峰值为
130 万次。
饱和吞吐量
饱和吞吐量是指系统处于饱和状态时，在访问系统的所有客户端中每秒执行的事务
数。 在本白皮书前面的章节里介绍过我们确定饱和点的方法。
响应时间
响应时间是服务器对最终用户请求作出响应所需的时间。
并发用户数
要理解 Tableau Server 环境下的并发性，我们首先来界定并发性不具备的特征。 我
们与性能团队进行了很多次的交流，他们将用户并发性定义为登录到 Tableau Server
的用户数。 虽然这是一种合理的指标，但它并不能代表本白皮书中的并发性。
登录的用户的数量只能衡量应用程序服务器进程的可扩展性。 一次用户登录只会占
用系统中一条很窄的路径，它不同于负责加载可视化并与之交互的关键路径，此路
径会执行大量计算密集型工作。
对于 Tableau Server 而言，我们将并发性定义为在指定的响应时间和吞吐量目标
下，主动加载可视化并与之交互的最终用户数。 我们可根据这一核心指标，了解所
测试的给定系统在处于饱和状态时可以支持的用户数。 我们根据试验和测试执行过
程中的平均响应时间和饱和吞吐量，运用 Little 法则推断并发用户的数量。
25
VizQL Server 进程如何处理并满足最终用户加载可视化并与之交互的请求，决定着
Tableau Server 的可扩展性，鉴于这一点，我们运行了一系列测量这种可扩展性的
测试。
至此我们已经了解了执行测试的方式、所使用的部署以及各项指标，现在就来了解
结果如何。
结果
Tableau Server 9.0 推出各种新功能和引入各种体系结构更新之后，我们运行了多次
试验，并基于实验结果设计出了以下方案。 我们采用相同的方法体系，基于相同的
拓扑和同一实验室内的硬件，在 Tableau Server 9.0 和 Tableau Server 8.3 上运行了
同样的工作负载，以便可以比较这两个版本的可扩展性。
比较 Tableau Server 9.0 版与 8.3 版的可扩展性
在配备 16 个或更多个核心的情况下，我们发现 Tableau Server 9.0 的性能和可扩展
性均优于 Tableau Server 8.3。 具体来说，我们观察到 Tableau Server 9.0 从使用一
台 16 核计算机总共支持 927 名用户，扩展至使用一个包含 3 个节点、48 个核心的
服务器群集总共支持 2809 名用户，且平均响应时间远低于 3 秒的目标响应时间，
同时错误率不足 1%。
在处理典型的工作负载时，我们的结果表明，Tableau Server 9.0 在单节点 16 核计算
机上的饱和吞吐量为 209 TPS，在 3 节点 48 核计算机上，则增至 475 TPS。 提醒一
下，TPS 对应于在一秒时间里加载并与之交互的可视化数量。我们看到了一个以近
乎线性方式扩展的系统，您可以通过向群集添加更多工作软件节点来实现横向扩展。
图 13： Tableau Server 9.0 可扩展性摘要
拓扑满负载时的
吞吐量 (TPS)响应时间（秒） 并发用户数 用户总数 错误率
1 个节点，16 个核心 209.7 0.44 92.75 927 0.78%
2 个节点，32 个核心 303.4 0.46 138.04 1380 0.58%
3 个节点，48 个核心 475.5 0.59 280.93 2809 0.16%
26
在相同的硬件上，我们采用相同的方法体系对 Tableau Server 8.3 重新运行了同样的
测试。 我们获得的结果如下表所示。
拓扑满负载时的
吞吐量 (TPS)响应时间（秒） 并发用户数 用户总数 错误率
1 个节点，16 个核心 61.0 1.47 89.88 899 0.46%
2 个节点，32 个核心 144.6 0.69 99.82 998 0.06%
3 个节点，48 个核心 152.6 1.36 206.76 2068 0.12%
图 14： Tableau Server 8.3 可扩展性摘要
我们观察到，Tableau Server 8.3 在单台 16 核计算机上一共可支持 899 个用户，
而 Tableau Server 9.0 在同样的配置下可支持 927 个用户。 除此之外，在 3 节点 48
核群集中，Tableau Server 8.3 总共支持 2068 个用户即达到饱和状态，而 Tableau
Server 9.0 总共支持 2809 个用户才达到饱和状态。 不过，Tableau 8.3 在 16 核
计算机上相对更快地进入饱和状态，即在达到 61 TPS 时进入饱和状态，相比之
下，Tableau Server 9.0 则在达到 209 TPS 时进入饱和状态。 在更大规模的测试中，
我们发现在 3 节点 48 核群集内，Tableau Server 8.3 在达到 152 TPS 时进入饱和状
态，相比之下，Tableau Server 9.0 则在达到 475 TPS 时进入。
以线性方式扩展的吞吐量
我们开展的所有测试都表明，Tableau Server 9.0 吞吐量能够以近乎线性的方式扩
展，且相较于 Tableau Server 8.3 而言，在处理同样的工作负载、采用相同方法体系
和基础架构的条件下，其性能更加稳定。
对于那些打算在单台 8 核计算机上运行 Tableau Server 的客户而言，我们另外运行
了一组特定的测试，以便为此方案提供信息依据。 请参阅本白皮书后面的“在单台
8 核计算机上进行的比较”一节。
总体硬件观察结果
除了上文所讲的具体可扩展性观察结果，以及在进行核心及横向扩展时服务器规模
会受到何种影响之外，我们还采集到了一些基础架构指标和观察结果。 在下面的章
节中，我们将了解对于 16、32 及 48 核计算机而言，上述核心拓扑对内存、磁盘以
及网络产生的影响。
27
内存
在与 Tableau Server 8.3 比较时，我们观察到 Tableau Server 9.0 在单台 16 核计算机
上所需的内存要多出 40%，在 3 节点 48 核群集上所需的 RAM 则要高出 70%。
图 15： 16、32、48 核群集的 RAM 利用率
RAM 使用量增加的原因有二：一是由于本白皮书前面章节中已经讲到的诸多变化而
引起；二是由 8.x 升级所致。因此，您应该考虑为 9.0 系统增添更多 RAM。
28
磁盘吞吐量
对于我们在试验中使用的磁盘而言，Tableau Server 9.0 在分布式群集中的磁盘吞吐量
有所降低。 在单机 16 核情形中，8.3 与 9.0 相比，占用的磁盘吞吐量增加了 14%。
但是对不同版本的服务器所进行的负载测试表明，3 节点 48 核群集的磁盘吞吐量实
际降低了 30%。 在 Tableau Server 9.0 中，我们将群集状态持久保留到磁盘，并将
Tableau Server 9.0 日志中的各个新组件持久保留到磁盘。
图 16： 磁盘利用率比较
网络使用情况
在 Tableau Server 9.0 中，增加了多个可以与新的分布式查询缓存协同发挥作用的组
件。 此外，我们还有可以在整个群集范围内维护状态的协调服务。 相较于 8.3，
它引发的网络讨论有很大的增加。 不过，我们并未发现网络讨论对可扩展性或性能
有显著影响。
29
图 17： 网络利用率比较
单就 Tableau Server 9.0 来看，尽管网络流量有所增加，但扩展性与性能都有出色
表现。 对于实际部署我们得到的心得是，可以考虑在 10GB 网络（若有）上部署
Tableau Server。
在单台 8 核计算机上进行的比较
对于在 8 核计算机上运行 Tableau Server 的客户而言，我们希望告知他们升级之后
Tableau Server 9.0 版相比 8.3 版表现如何。 我们采用相同的方法体系运行了一系列
测试，旨在对 9.0 版和 8.3 版的结果进行比较。
30
在采用单台 8 核计算机的情形中，我们观察到 Tableau Server 9.0 在饱和吞吐量和响
应时间方面明显优于 8.3 版（如下表所示）。
关键指标Tableau Server 8.3
1 个节点，8 个核心Tableau Server 9.0
1 个节点，8 个核心
满负载时的吞吐量 (TPS) 34.2 129.9
响应时间（秒） 1.80 0.46
并发用户数 61.56 59.45
错误率 1.71% 0.78%
图 18： 在 8 核计算机上比较 Server 8.3 与 Server 9.0
我们观察到，Tableau Server 9.0 的饱和吞吐量明显较高，达到了 130 TPS；平均响
应时间也更短，仅为 0.46 秒；同时错误率也更低，不足 1%。
相比之下，Tableau Server 8.3 的吞吐量则明显更低，仅为 34 TPS，平均响应时间达
到了 1.8 秒。 我们能够让 Tableau Server 9.0 的错误率保持在目标值 1% 以下，但是
在单台 8 核计算机上，Tableau Server 8.3 会出现更多错误，这些错误通常是响应时
间随着负载而变长，导致客户端超时所致。
31
更高的内存要求
通过比较单台 8 核计算机与 16 核计算机，我们发现，Tableau Server 9.0 在 16 核测
试中多用了 38% 的 RAM，在 8 核测试中则多用了 68% 的 RAM。
图 19： 单台计算机部署情形中 8.3 版与 9.0 版的 RAM 利用率比较
此外，在多机群集部署情形中，较之于 Tableau Server 8.3，Tableau Server 9.0 在高
峰期的内存使用量大约高出 60-80%。 我们已经将 Tableau Server 9.0 的最低硬件要
求提高到 8GB，以满足为 9.0 版新功能提供支持的其他服务器进程之需。
举例来说，每个缓存服务器进程在启动时都会使用 500MB RAM。 在它高效工作
时，计算机上的缓存服务器进程越多，腾出的 RAM 就会越多。 此外，文件存储等
新进程也会占用额外的 RAM。 这些进程在以前版本的 Tableau Server 中并不存在。
32
言下之意就是，根据本白皮书中的具体测试，如果您有一个单机 8 核 Tableau
Server 8.3 实例，就地升级到 9.0 版可能会给您的最终用户带来性能提升。 但是，
由于资源争用，可扩展性会略有减弱。 较之于 8.3 版，在单台计算机上运行时 9.0
版错误更少。 您所获得的具体性能提升幅度将因很多因素而异。 在您考虑从 8.x 版
升级到 9.0 版时，我们希望这有助于您更有依据地规划所需容量。
我们对 Tableau Server 9.0 中的高可用性 (HA) 功能做出了诸多改进。 除了引入文件存
储、群集控制器、协调服务等新的服务器进程之外，我们还在尝试一些新的举措，
旨在将数据提取转移到群集中拥有数据引擎的所有节点上。 我们希望测试出 HA 更
新会对可扩展性造成怎样的影响（若有）。 下一章节讲述了我们的观察结果。
高可用性所产生的影响
在思考 HA 和非 HA 时，需要注意一个重要因素，即为了支持新的体系结构以实现
高可用性，我们向服务器增添了几个新的组件。 为了测试 HA，我们需要确保在组
合中包含了新的应用程序服务器工作负载。 我们在与之前相同的硬件上运行了新的
工作负载。 在 Tableau Server 9.0 中，必须至少拥有三台计算机才可运行 HA 配置。
有关更多详情，请阅读服务器管理指南。
在一次测试中，我们向群集中的每个节点添加了一个用于执行故障转移的被动存储
库，一个文件存储进程和一个数据引擎进程，以启用 HA。
相比非 HA 部署情形，在启用了 HA 时，我们注意到对吞吐量和响应时间产生了非
常轻微的影响。 这种影响微不足道，也是可以预见的，因为我们会做更多工作来让
Postgres 存储库和数据提取保持同步。 但是，在运行 HA 配置时，所有工作软件的
内存使用量都提高了大约 10%。
内存使用量的提高并不会显著影响 TPS。 我们观察到，在启用了 HA 时，TPS 的降
幅不足 1%。 错误率（大多数是套接字读取超时）提高了 0.1% 到 0.3%，但仍然低
于 1% 的错误率阈值。
除此之外，在 HA 模式下运行时，向服务器提交的每项发布操作（在使用数据提取
时）都需要文件存储进程对群集内所有节点的新数据提取进行同步。 在之前的版本
中，最多只能在群集内的两个节点上运行数据引擎进程。 而在 Tableau Server 9.0
中，可以在任意数量的节点上运行数据引擎进程。
33
每台运行数据引擎进程的计算机也需要文件存储进程。 考虑到存在这种配置可能
性，您应注意的是，为数据提取冗余设置的节点越多，在节点间同步数据提取的成
本就越高。 这种成本主要体现在网络使用量方面，因此，在决定是否要通过慢速链
路部署服务器工作软件时应考虑到这一点。
运用结果
此时，您可能在想如何才能让这些结果为您所用，以及如何才能确定部署所需的容
量。 在本白皮书中，我们说明了 Tableau Server 能够以近乎线性的方式扩展，从而
实现用户并发性。 对您而言，可以采取的一种方法就是充分利用本白皮书中的指
导，确定您可能需要的容量并将它用作基准。 但实际结果可能有所差异，因为您使
用的系统可能与我们在本白皮书所述的测试中使用的系统不尽相同。
后台程序方面的注意事项
我们讨论的许多内容都是以面向用户的工作负载为语境。 其中最关键的是视图加载
和交互以及门户网站交互。 后台程序服务器进程会执行很多与数据提取刷新、订阅
以及其他计划的后台作业相关的工作。 如果您安排这些作业在非高峰时段运行，它
们就不会争用容量。 若不能如此，则应该规划并增加后台程序和并非面向用户工作
负载所需的容量，以便让它们与面向用户的进程并发运行。
后台程序设计为占用整个核心的容量，因为它们的宗旨是尽快完成工作。 当您运行
多个后台程序时，应该考虑到这样一种实际情况，即后台服务器进程可能会影响到
在同一台计算机上运行的其他服务。 在此我们介绍一种值得推荐的最佳做法，即
确保对于计算机上可供 Tableau Server 使用的 N 个核心，您可以在该计算机上运行
N/4 至 N/2 个后台程序。
您也可以视需要将后台服务器进程划分出来使用专用的硬件加以执行，以便隔离它
对最终用户工作负载的影响，不过这并非必需。
如果您希望执行自己的负载测试，以确定 Tableau Server 在自己的环境中如何随工
作负载进行扩展，不妨参考下文提供的一些最佳做法。
34
最佳做法 – 自行进行规模测试
很多时候，您可能希望开展自己的可扩展性和负载测试，以便确定 Tableau Server
在您的环境中以及在您的工作负载下如何扩展。
尝试自行进行这种测试时，必须牢记四个要点：
1. 不要把 Tableau Server 当成黑盒。 Tableau 可以纵向扩展和横向扩展。 但是，
把它当成黑盒可能会产生意想不到的结果，因为扩展 Tableau Server 会牵涉到
许多因素，例如工作负载、配置、系统环境以及测试负载下的整个系统。
2. 选择正确的测试工具。 Tableau Server 拥有强劲动力，承担各种复杂的资源密
集型工作。 有很多工具可以用来在 Tableau Server 上生成负载。 虽然 Tableau
不直接支持其中的任何工具，但还是应挑选出最易用且最贴近您生产环境的工
具。 另一考虑事项是，确保您掌握了工具和 Tableau Server 方面的合适专业知
识。
3. 甄选有代表性的工作簿。 很多时候，我们之所以会听到性能或扩展方面的投
诉，是因为我们使用的工作簿并非遵循最佳做法制作。 如果工作簿上的单一
用户测试结果表明响应时间极长，则应该优化工作簿，然后才能着手开展负载
测试项目。
4. 通过实时连接测试工作簿时，请注意一点，Tableau Server 9.0 中已引入并行
化功能，因此需要的 VizQL 服务器数量会少于您在先前 Tableau Server 版本中
可能部署的数量。 首先从新的默认配置开始，然后逐步纵向扩展您的进程。
TabJolt - 可扩展性测试工具
Tableau 最近发布了一款名为 TabJolt 的负载和性能测试工具，点击即可运行，可以与
Tableau Server 一起轻松使用。 使用此工具之后，可以省去脚本开发、维护工作，实
现更快速的迭代。 可从 github 免费按原样获得此工具。 您可以阅读发布博客，了解
这款工具的更多信息。
35
有关在实际环境中进行优化的最佳做法
除了经过优化设计的系统之外，还有一些最佳做法可以显著提升性能，缩短平均响
应时间。
使用 Tableau 数据提取 – 如果数据库查询较慢，可考虑使用数据提取来提高查询性
能。 数据提取功能将数据存储在内存中和本地服务器上，用户这样就无需向数据库
发出请求便可访问这些数据。 若用户不需要行一级的详细信息，可以轻松对它们进
行筛选和聚合，从而显著缩短响应时间。
将更新安排在非高峰时段执行 – 数据源通常会实时更新，但用户只是每天或每周
才需要一次数据。 将数据提取安排在非高峰时段，这样可以减轻数据库和 Tableau
Server 在高峰时段的负载。 不仅如此，还可以在现有计算机上添加更多后台程序，
或者使用专用硬件，但前提是您有充足的核心容量。 如果希望以更快的速度完成数
据提取，不妨考虑此方案。
在高峰时段避免执行“高成本”操作 – 发布（特别是发布大文件）是非常耗费资源
的任务。 发布行为通常很容易受到影响。 要求用户在非高峰时段进行发布，从而避
开周一早晨等忙碌时段。 要了解服务器何时的使用量最大，请访问管理员视图，然
后根据实际使用量制定策略。 根据您对 Tableau Server 9.0 所采用的配置方式，发
布内容也意味着会在各群集节点上创建一份数据提取副本，以实现高可用性。 通过
在非高峰时段执行此操作，还能让您最大程度利用网络带宽。
缓存视图 – 当有多个用户开始访问 Tableau Server 时，由于会争用共享资源，响应
时间最初会增加。 开启缓存功能之后，进入系统的所有请求的视图都会被缓存，
然后以更快的速度呈现给同一仪表板的下一位查看者。 缓存服务器进程是 Tableau
Server 9.0 的新功能，可通过如下方式进行预热：计划发送一封电子邮件，写明在完
成数据提取刷新后请求常用的视图。 这样一来，查看者使用的就是在之前的请求中
缓存的数据。 您可能会使用其他方法预热缓存，在此过程中借助自动化工具，加载
经常需要大流量的重要可视化。 用户随时可以手动让外部查询缓存（由缓存服务器
进程所维护）变为无效状态，以便刷新来自数据源的数据并强制重新生成缓存。 这
样一来，无论缓存中是否已有版本，用户总能获得一份最新的数据。
36
少即是多 - 在之前的版本中，您可能不得不在单台计算机上运行多个 VizQL Server
进程来处理负载。 但是，通过引入一种称作协议组的核心技术之后，可以实现并
行查询，如今 VizQL Server 可以使用多条通往后端数据库的连接。 您可能会发
现，Tableau Server 9.0 具有更强的扩展性，它实际上能够将 VizQL 进程数量减少到
四个以下。 新的默认配置是在每台计算机上运行两个 VizQL Server 进程，如今这已
成为最佳做法。
总结
在本白皮书中，我们深入细致地介绍了我们的方法及其来龙去脉，介绍了这种方法
体系的相应变化，以及 Tableau Server 9.0 服务器可扩展性结果的最终结果。 结果
表明，Tableau Server 9.0 可以呈线性扩展，且性能优于 Tableau Server 8.3。
我们观察到，在单台 16 核计算机上，Tableau Server 9.0 最多可支持 927 个用户，
在 3 节点 48 核群集环境中则可以扩展至 2809 个用户，且其中有 10% 的用户积极加
载可视化并与之交互。
我们希望本白皮书能够帮助您顺利部署自己的 Tableau Server 9.0。 考虑到环境、
工作负载和部署各不相同，您得到的结果也可能不尽相同。
37
关于 Tableau
Tableau 致力于帮助人们查看并理解数据。 Tableau 帮助任何人快速分析、可视化并共享信息。
超过 29,000 家客户通过使用 Tableau 在办公室或随时随地快速获得结果。 数以万计的用户使用
Tableau Public 在其博客和网站中分享信息。 登录 www.tableau.com/zh-cn/products/trial 下载免费试
用版，了解 Tableau 能够为您带来哪些帮助。
其他资源
下载免费试用版
相关白皮书
高可用性： 任务关键型快捷 BI 与 Tableau Server
Tableau Secure Software Development（Tableau 安全软件开发）
查看所有白皮书
了解其他资源
· 产品演示
· 培训与教程
· 社区与支持
· 客户故事
· 解决方案
Tableau 和 Tableau Software 是 Tableau Software, Inc. 的商标。所有其他公司和产品名称可能是与其相关联各自公司的商标。