JSON响应对象：“漂亮”键和更大的响应或短键和更小的响应？ [关闭]答案

【问题标题】：JSON response objects: "pretty" keys and larger response or short keys and smaller response? [closed]JSON响应对象：“漂亮”键和更大的响应或短键和更小的响应？ [关闭]
【发布时间】：2013-11-17 00:22:23
【问题描述】：

我的实时网络应用发出 ajax 请求以获取 JSON 后处理的数据响应。

返回的数据通常是对象数组的形式。

由于数组通常有很多元素（虽然发送的数据被服务器压缩），为了将响应大小保持在最小，我保留了 keys 回复很短。

例如，不使用 description: 我使用 d:，而不是使用 width: 我使用 w:强>等等……

这样做会减小响应的大小，但在客户端，非常短的非人工可读键会降低 JavaScript 代码（访问对象）的可读性。

唯一的解决方案似乎是重新解析响应并使用 pretty 键重建对象，或者将它们替换为收到的原始对象。但这可能会损害 JavaScript 代码性能，从而导致更多延迟...

有更好的解决方案吗？

编辑：

正如 Björn Roberg 在他的评论中建议的那样，我做了一个比较：

pretty-response.json       459,809 bytes
 short-response.json       245,881 bytes

pretty-response.json.zip    28,635 bytes
 short-response.json.zip    26,388 bytes

因此，由于响应是由服务器压缩的，因此差异确实很小。

不过，漂亮的响应需要服务器压缩 450 KB 的数据，而短响应只需 240 KB。

这会影响服务器性能吗（或者有办法衡量它）吗？

【问题讨论】：

您是否尝试过使用“漂亮”键并比较传输的实际大小？
当您说您拥有“大量”数据时，您指的是多少？您可以使用redis 来“外包” JSON 对象的存储，如果您需要处理大量元素，这将有所帮助
@BjörnRoberg 查看我的编辑...
我不禁觉得，不管你的问题是什么，一定有比 450kb 的 JSON 更好的解决方案。

标签： javascript json

【解决方案1】：

由于您正在考虑在客户端将短密钥转换回长密钥，因此您显然关心的是数据的带宽需求，而不是客户端的内存需求。

我生成了一些文件，其中包含随机数据和三个键（描述、某些内容和其他内容）。我还通过 sed 转储数据，用 d、s 和 e 替换这些键。

这会导致：

750K   long-keys
457K   short-keys

HTTP 有support for compression，所有重要的客户端都通过 gzip 支持这个。那么，如果我们 gzip 文件会发生什么：

187K   10:26 long-keys.gz
179K   10:27 short-keys.gz

它们之间几乎没有选择余地，因为 gzip 非常擅长压缩重复的字符串。

所以，只需使用 HTTP 压缩即可，不用担心修改数据。

gzip 也是一种非常快的算法，因此它对服务器性能的影响可以忽略不计。

【讨论】：

【解决方案2】：

也许你可以试试protocol buffers 看看是否有什么不同。它被开发为比许多其他序列化格式（即 XML 和 JSON）更快更轻。

存在其他具有相同目标的格式，但协议缓冲区（也称为 protobufs）是我想到的一种。

请参阅this answer 进行很好的比较。

【讨论】：

【解决方案3】：

您可以使用装饰器模式在从数组中检索对象时包装对象。

但是，鉴于您可能想要访问返回的所有对象（为什么要返回客户端不需要的对象？），将对象转换为对象可能不会更慢，甚至可能更快从数组中检索时具有更长的字段名称。

如果您要多次检索每个对象，您甚至可以遍历数组并一一替换，以避免重复转换。

所有这些选项都有性能成本，但可能并不重要。简介！

【讨论】：

将对象转换为具有更长字段的对象确实需要在客户端处理一段时间。我的范围从 1,000 到 10,000 个元素。至于分析实际成本是多少，这很难，因为取决于硬件/操作系统/浏览器的组合......太多的案例需要测试！
你真的需要在一页上处理这么多的对象吗？您不能使用延迟加载和/或在服务器上进行更多处理吗？
是的，我愿意。我知道有这么大的响应是很奇怪的，但这正是网络应用程序根据某些用户操作执行其任务所需的最少数据。

【解决方案4】：

使用http://dean.edwards.name/packer/从服务器压缩你的json

压缩库http://dean.edwards.name/download/#packer

您也可以通过在线检查您的 json 大小是否减少

【讨论】：

问题是在客户端解压缩它的计算成本。
为什么不在服务器端压缩，我相信它会帮助你
我已经压缩了服务器端，这使得差异最小化。但现在我想知道（因为我不知道如何衡量）压缩 450KB 而不是 250KB 在服务器端的影响有多大？（见我的编辑）
可以查看服务器的响应时间
服务器的响应时间是很多东西的总和（每次不定），其中压缩时间只是其中之一

【解决方案5】：

如果您希望您的代码可读并且仍然使用短键，您可以使用索引符号来访问成员：

var descriptionKey = 'd';
var widthKey = 'w';

//...

var description = yourObject[descriptionKey];

【讨论】：