blocks|key|197203|text|您的服务器是否根据内容类型处理不同的type/deflate？我的是这样。相信ab在默认情况下不接受gzip。(您可以在ab中使用带有-H标志的自定义标头进行设置)。但是Chrome总是说它接受gzipping压缩。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|197204|您可以使用curl+test查看这些文件是否具有不同的大小：|197205|+curl+http://www.example.com/whatever+--silent+-H+"Accept-Encoding:+gzip,deflate"+--write-out+"size_download=%25{size_download}\n"+--output+/dev/null|code-block|syntax|javascript|197206|您还可以查看标题以查看是否应用了look：|197207|curl+http://www.example.com/whatever+-I+-H+"Accept-Encoding:+gzip,deflate"+|197208|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Does your server handle gzipping/deflate differently depending on content-type? Mine does. Believe ab does not accept gzip by default. (You can set this in ab with a custom header with the -H flag). But Chrome will always say it accepts gzipping.

You can use curl test to see if the files are different sizes:

<pre><code> curl http://www.example.com/whatever --silent -H "Accept-Encoding: gzip,deflate" --write-out "size_download=%{size_download}\n" --output /dev/null
</code></pre>

You can also look at the headers to see if gzipping is applied:

<pre><code>curl http://www.example.com/whatever -I -H "Accept-Encoding: gzip,deflate" 
</code></pre>

blocks|key|195397|text|我将回答问题的最后一部分：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|195398|尽管存在性能差异，|195399|是否还有使用应用程序/json的原因？|blockquote|195400|195401|195402|回答:是的。|195403|原因:+1)+text/html经常可能是错误的json，直到你尝试解析它时才会被捕获。application/json将失败，只要json格式错误，您就可以轻松地进行调试|195404|2)如果您在浏览器中查看json，使用header类型会将其格式化为用户友好的格式。text/html将更多地将其显示为blob。|195405|3)如果您在网页上使用此json，application/json会立即转换为js对象，您可以通过obj.firstnode.childnode等方式进行访问。|offset|length|style|CODE|195406|4)回调功能可以在application/json上使用，但不能在text/html上使用|195407|注意:使用gzip的将充分缓解性能问题。text/html仍然会更快一些，但不是推荐的获取json对象的方式|BOLD|195408|不过，我希望看到更多关于性能的见解。报头长度绝对不会导致性能问题。更多的是与你的the服务器分析头文件格式有关。|195409|entityMap^0|0|0|0|0|0|0|0|0|1D|N|0|9|G|X|9|0|0|A|K|9|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|14|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|15|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|18|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|19|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1A|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1B|8|@$Q|1C|R|1D|S|T]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1E|8|@$Q|1F|R|1G|S|T]|$Q|1H|R|1I|S|T]]|9|@]|A|$]]|$1|W|3|X|5|6|7|1J|8|@$Q|1K|R|1L|S|Y]|$Q|1M|R|1N|S|T]]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1O|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]]|12|$]]

I'll take up the last part of question:

<blockquote>
 Is there a reason to use application/json despite the performance
 difference?
</blockquote>

Answer: Yes

Why:
1) text/html can often be malformed json and will go uncaught until you try parsing it. application/json will fail and you can easily debug whenever the json is malformed

2) If you are viewing json in browser, having the header type will format it in a user-friendly formatting. text/html will show it more as a blob.

3) If you are consuming this json on your webpage, application/json will immediately be converted into js object and you may access them as <code>obj.firstnode.childnode</code> etc.

4) callback feature can work on <code>application/json</code>, but not on <code>text/html</code>

Note:
Using gzip will sufficiently alleviate the performance problem. <code>text/html</code> will still be bit faster, but not the recommended way for fetching json objects

Would like to see more insight on performance though. Header length is definitely not causing performance issue. More to do with your webserver analyzing the header format.

While evaluating performance of PHP frameworks I came across a strange problem

Sending a JSON as <code>application/json</code> seems to be much slower than sending with no extra header (which seems to fallback to <code>text/html</code>)

Example #1 (application/json)

<pre><code>header('Content-Type: application/json');
echo json_encode($data);
</code></pre>

Example #2 (text/html)

<pre><code>echo json_encode($data);
</code></pre>

Testing with apache bench (<code>ab -c10 -n1000</code>) gives me:

Example #1: 350 #/sec

Example #2: 440 #/sec

which shows that setting the extra header seems to be a little bit slower.

But:

Getting the same JSONs via "ajax" (<code>jQuery.getJSON('url', function(j){console.log(j)});</code>) makes the difference very big (timing as seen in Chrome Web Inspector):

Example #1: 340 ms / request

Example #2: 980 ms / request

Whats the matter of this difference?

Is there a reason to use application/json despite the performance difference?

Performance text/html vs. application/json

服务器

jQuery

JSON

在评估PHP框架的性能时，我遇到了一个奇怪的问题以application/json的形式发送JSON似乎比不带额外报头的发送要慢得多(这似乎是回退到text/html)示例#1 (application/json)header('Content-Type: application/json');echo json_en...

问性能text/html与应用程序/json
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问性能text/html与应用程序/jsonEN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问性能text/html与应用程序/json
EN