4

当涉及到 web 服务响应消息时，有多少数据太多了？

我有一个用 Java 编写的 HTTP servlet，它在我们的网络之外打开。它调用数据库，然后通过防火墙发回 JSON 消息。我们所说的 344kb 仅用于数据，不包括数据包标头。我不会认为这很重要。我们在 iOS 和 Android 平台上都收到了响应，总往返时间可能在 1 秒到 15 秒之间。平均可能 > 6。我想在 5 秒内稳定地完成这个，我正在学习这是相当了不起的壮举。根据我的时间，对数据库的 web 服务调用是毫秒。我们直接在防火墙后面连接，但在互联网前面（因此排除了互联网），并且看到了可能一秒钟的总往返行程。

作为一项测试，我将返回 JSON 修剪为仅返回 1 行数据 (4kb)，当然，我看到速度大幅提高...... 这真的引出了一个问题，当返回 JSON 消息以在期望小于 5 秒的移动设备上消费时，是否存在最大数据大小？运行 wireshark 向我展示了这是作为多个数据包交付的，我想与它有很多关系。

我还计算了客户端接收消息的时间以及在屏幕上呈现消息所花费的时间……仅毫秒。

我不想将我的客户端程序分解为针对不同数据的多个 Web 服务调用，因为该程序非常基础，而且我认为它不需要多次调用。

你怎么看？责怪互联网，只是制作一个漂亮的启动/加载屏幕？:)

** 编辑：我也忘了补充说我正在通过 SSL **

4

2 回答 2

5

归咎于移动连接及其增加的延迟。明确地说，它甚至不是下载速度，而是保持恒定连接的可能性和非分块数据包。

可悲的是，您不会在这里找到“正确”的答案。

在完美的条件下，一部手机的 RTT 可能只有一两秒，其中包含您的所有数据。
在不太理想的情况下，您的数据可能永远不会到达。

因此，您需要订阅重量与频率的平衡行为。
除了你，没有人能真正给你这个比例。

就个人而言，我的建议可能是开始按模块分解数据。
如果你有组成应用程序的小模块化小部件，每个小部件都需要配置数据或用户数据，请分别以松散耦合的方式加载每个小部件。

作为一个简单的例子，你可能有一个聊天应用程序，你的消息窗口、在线朋友列表和 PM 列表都相互独立加载。

如果每个都在准备就绪时进行初始化，并且每个都有自己单独的“加载”指示器（进度很好，但实际上“正在处理”就可以了）。

如果您的应用更像是一个博客卷或一组项目，其中只有少数可以在屏幕上显示，那么根据每个屏幕的平均数量对它们进行逻辑分块。
将其设置在计时器上，或者在成功加载触发下一次异步加载的队列中设置，直到您得到空响应。

如果您的应用程序更像是一个分析套件，您要在其中加载数千行统计信息......好吧，您无能为力，但请确保用户知道它正在运行。您可以发送带有第一个结果的“总计”字段，并根据您迄今为止加载的唯一行数来标记您的进度。
或者，如果您有按天计算的统计数据，您可以按天或按周进行分组，并在条形图或日历上标记您当前可用的集合有多远。

这里没有简单的答案，但希望能得到一点帮助和一条建议：

在一个程序中等待 5 秒钟，我可以看到所有内容都在流入，并且在完成后将起作用，这比在完成的产品弹出之前只是一个空白屏幕并且没有人告诉我任何事情的 3 秒钟更可以忍受。

于 2012-11-02T17:59:21.857 回答
0

对于移动集成，JSON 中的 65000 个字符非常好...... 对于更大尺寸的 JSON，您应该进行批处理。

对于更多字符，问题来自带宽。如果互联网带宽变慢，那么您可能无法接收数据（数据丢失）。

于 2013-02-28T10:47:16.673 回答