/files慢速响应

Question

我想在下面描述的问题上寻求帮助/想法。

我们的iOS应用程序允许用户访问他们的Google文件。

我们使用更改API (https://developers.google.com/drive/api/v3/reference/changes)。使用此API的主要先决条件是构建一个本地DB，该数据库保存用户的驱动器文件树和令牌的快照。要开始填充DB，我们必须从用户的驱动器请求所有文件的列表。获取所有文件的列表(带有元数据)对我们的许多用户来说太长了。这就是我想要解决的问题。

我们使用一系列文件请求(https://developers.google.com/drive/api/v3/reference/files/list)请求文件。大多数请求都是普通的files?q=trashed%20%3D%20false。

例如，在我自己的私人Google驱动器上：

以我目前的网络速度(下载527 Mbps，上传417 Mbps；ping www.googleapis.com -40-45 ms)，

• 69K文件
• 所有文件的初始请求需要5+分钟(ping www.googleapis.com-40-45 ms)
• ~150 ping www.googleapis.com请求带来关于~460个文件的信息，
• 每个请求大约需要2-2.5秒<代码>H 214f 215

有时，我观察到请求占用最多6秒，这意味着获取所有文件列表在我的帐户花了15分钟。

如果我查看开发人员控制台，延迟时间将低于0.1s。

我们的许多用户的驱动器比我的要大得多。标准iOS应用程序用户的会话时间不够长，无法完成初始请求。我们保存每个中间页面令牌，以便在单个应用程序会话期间收到的所有数据不会丢失，如果用户离开应用程序-下一次会话，我们将继续从上次保存的令牌下载数据。但是，在某些情况下，我们的应用程序需要在开始某些操作之前用数据填充DB --在这种情况下，我们的用户会看到“挂起.”他们抱怨说我们的应用程序太慢了。

那么，问题是：

是否有可能改进所描述的请求speed/latency?

• maybe --我们缺少一些配额，并且可以是changed?

• maybe --有人可以建议一种更有效的方法来获取所有文件列表？

我们可能会减少请求的数量。我们必须对与我共享的文件夹执行一些双重检查，因为我们观察到，有时所有文件的请求并不会列出共享文件夹中的所有文件。这是一个附带的故事，我不认为这会显着地改善我们的情况。如果需要，我可以提供更多关于我们执行的实际请求集的详细信息。

Answer 1

您是否返回所有字段--我假设是这样的，因为提供的唯一查询参数是trashed=false作为查询参数。你需要所有的田地吗？您能否尝试将查询简化为只返回您真正关心的字段(使用字段掩码)，并查看这是否提高了性能？