JSON响应对象:"漂亮"键和更大的响应或短键以及更小的响应？

Question

我的实时Web应用程序生成ajax请求以获取JSON经济数据响应.

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

由于数组通常有很多元素(虽然发送的数据是由服务器进行的,但是为了使响应大小保持最小),我仍然保持响应中的密钥非常短.

例如,而不是使用描述:我使用d:而不是使用宽度:我使用w:等等......

这样做会减小响应的大小,但是在客户端,非常短的非人类可读密钥会使JavaScript代码(访问对象)的可读性降低.

唯一的解决方案似乎是重新解析响应并使用漂亮的密钥重建对象,或者在接收的原始对象中替换它们.但这可能会损害JavaScript代码性能,从而导致更多延迟......

存在更好的解决方案？

---

编辑:

正如BjörnRobberg在评论中所说,我做了一个比较:

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.

这是否会影响服务器性能(或者有没有办法测量它)？

Answer 1

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

我已经生成了一些包含随机数据和三个键的文件(描述,东西和其他东西).我还通过sed转储数据,用d,s和e替换这些密钥.

这导致:

750K   long-keys
457K   short-keys

HTTP 支持压缩,所有重要的客户端都支持gzip.那么,如果我们gzip文件会发生什么:

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

因为gzip相当擅长压缩重复的字符串,所以它们之间几乎没有什么选择.

因此,只需使用HTTP压缩,不要担心重复数据.

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

Answer 2

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

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

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

所有这些选项都会产生性能成本，但可能并不显着。轮廓！