使用云服务就不得不考虑网络问题。一些云服务使用标准的Webdriver/Appium
client/server模型来运行Appium测试。但它们拥有非常多的设备，因此就需要大量的Appium服务器。
为了让用户更易用，他们通常会为启动会话（sessions）仅提供一个入口点。用户的请求都来自这个单一的入口点，他们会根据用户的验证信息和session
ID代理到相应的Appium服务器。如此一来，入口点就像Appium负载均衡器，如下图所示：
这个模型让用户非常便利的去连接Appium服务器。但这个方式的性能并不好，因为它在客户和Appium服务之间需要多发送一个HTTP
request/response（译者注：在Appium服务与客户之间存在Cloud Service Entry Point，因此要多发送一个请求给它）。
** 延迟怎么办？**
性能的好坏取决于Cloud Service Entry
Point的安排。有些云可以保持负载均衡，它让所有设备在一个物理数据中心内。在这种情况下，额外的HTTP请求/响应并不会造成什么影响，因为这是数据中心的本地调用。
其他云提供商强调地理和网络分布，真实设备遍布全球，这意味着Appium服务器也散布在世界各地，因为Appium服务器必须运行在主机上（连接了设备的主机）。所以，如果你希望自己的测试脚本拥有一对一的Appium端点和高度分布式云设备，你将不得不忍受延迟。
当然，Appium团队真的不喜欢延迟，所以我们想到了一个方法，我们称之为直接连接。每当Appium服务器完成会话时，它都会向Appium客户端发送一个JSON响应（这个响应通常是你请求的东西），如果一个云服务使用了直接连接，它将添加下面四个新功能：
-
directConnectProtocol
-
directConnectHost
-
directConnectPort
-
directConnectPath
由于客户端使用Cloud Service Entry
Point，所以它不知道Appium云服务的任何信息，这四个功能将编码Appium服务器的位置和访问信息并发送给客户端，如果客户端支持直连，它会自动解析这四个功能，以确保后续命令不会发送到Cloud
Service Entry
Point，而是直接发送到处理会话的Appium服务器。目前，官方Appium的Ruby和Python库支持直接连接，以及WebdriverIO。
就像下图这样，对于每一条指令都会初始化会话，HTTP请求直接发送到Appium服务器：
最棒的是，你不需要知道直接连接的工作原理！这是一个被动的客户端功能，只要Appium云务也开启这个功能。因为这是一个新功能，你要在客户端打开一个标志，表示您希望使用此功能（例如，在WebdriverIO中，您需要将enableDirectConnect选项添加到WebdriverIO配置文件或对象）当你开启后，后面的事情全部自动化！
你仅仅需要考虑自己公司的防火墙，如果公司的安全部门允许网络连接通过防火墙连接到负载均衡，你可能遇到防火墙阻止命令。在这种情况下，要么让安全团队更新防火墙规则，要么关闭直接连接。
** 直接连接的表现**
为了查看直接连接的真实使用情况，我再次使用HeadSpin的云设备做一些实验（HeadSpin实现直接连接，他们的云目前支持它）。这是我在Vancouver中的办公室进行的实验，我在California和Japan的设备上运行了一系列测试（一堆命令），对使用直接连接和不使用直接连接进行以下对比：
Devices
|
Using Direct Connect?
|
Avg Test Time
|
Avg Command Time
|
Avg Speedup
---|---|---|---|---
Cali
|
No
|
72.53s
|
0.81s
|
Cali
|
Yes
|
71.62
|
0.80s
|
1.2%
Japan
|
No
|
102.03s
|
1.13s
|
Japan
|
Yes
|
70.83s
|
0.79s
|
30.6%
** 分析**
在California设备上使用直接连接增益甚微。它确实产生了增益，所以还不错，但因为Vancouver和
California非常接近，负载均衡器非常接近远程设备，我们并没有获得太多收益。
看看设备（以及Appium服务器）位于远处的效果，我们发现直接连接加速近30％。这是因为，如果没有直接连接，每个命令必须从
Vancouver到California再到Japan。通过直接连接，我们不仅切断了California这个中间人，而且还避免构建额外的HTTP请求。
** 测试方法**
（我运行这些测试的方式与我在Execute Driver ScriptExecute Driver Script上运行测试的方式基本相同）
-
这些测试是在HeadSpin在世界各地的真实网络上运行，并且使用真实的Android设备上，这些设备位于加州山景城和日本东京。
-
对于每个测试条件（不同位置，是否使用直接连接），运行了15个不同的测试。
-
每个测试包括重复登录和注销5次。
-
Appium命令的总数（不计算会话开始和退出）是每次测试90个，这意味着每个测试条件总共为1,350个。
-
表中的数字会丢弃会话开始和退出时间，仅计算会话中的测试时间（如果你的时间主要集中在会话开始上，有非常少的命令，那么本篇文章对您用处不大）。
** 结论**
您可能不确定是否使用直接连接，如果您是Appium云提供商的常规用户，请务必与他们联系，询问他们是否支持该功能以及您是否受益。因为该功能需要在负载均衡器中实现，开源的Appium不能使用它（当然，如果有人写了Selenium
Grid的插件，可以支持直接连接，那将会很棒！）随着设备遍布世界各地，我很高兴有部分解决方案来消除任何不必要的延迟。
翻译：若桐
往期推荐
大话JMeter2｜正确get参数传递和HTTP如何正确使用
- 今日互动 -
欢迎文章下方留言并分享给其他测试小伙伴哦~
小编PS：
因为很多小伙伴想深入学习性能测试。我们邀请了专注性能十多年的性能架构师高楼老师给大家带来了《高级性能测试实战训练营》，想了解的小伙伴可以添加小助手微信进行咨询哦。课程信息可点击下方蓝色字体“阅读原文”进行试听。
（别忘了 长按 加小助手微信：jasmine07222
回复“ 性能测试 ”即可入群交流哦~）
来霍格沃兹测试开发学社，学习更多软件测试与测试开发的进阶技术，知识点涵盖web自动化测试 app自动化测试、接口自动化测试、测试框架、性能测试、安全测试、持续集成/持续交付/DevOps，测试左移、测试右移、精准测试、测试平台开发、测试管理等内容，课程技术涵盖bash、pytest、junit、selenium、appium、postman、requests、httprunner、jmeter、jenkins、docker、k8s、elk、sonarqube、jacoco、jvm-sandbox等相关技术，全面提升测试开发工程师的技术实力
QQ交流群：484590337
公众号 TestingStudio
点击获取更多信息