PHP Flush:频率和最佳实践 [英] PHP Flush: How Often and Best Practices
问题描述
我刚读完这篇文章: https://developer.yahoo.com/performance/rules.html#flush ，并且已经在页面顶部加载(头部，css，顶部横幅/搜索/导航)后实施了刷新.
冲洗是否有性能下降?是否有经常做这样的事情?最佳做法是什么?
如果我要使用外部API来获取数据，那么在事前刷新是否有意义，以便用户不必等待该数据返回，并且至少可以在事前获取一些数据?
所描述的技术看起来不错，但有一些陷阱:
1)PHP脚本开始和结束之间的时间比传输时间短；另外，根据您的消息来源，这可以为用户节省约0.5秒的时间.那对您来说是大量的时间吗?
2)此技术不适用于gzip输出缓冲
3)如果您经常刷新，则会在刷新时发送几乎为空的数据包，这实际上可能会增加加载时间(在缓慢，嘈杂的连接上).
4)刷新后，您将无法再发送任何标头
5)(次要问题)，服务器响应将采用分块编码，这意味着客户端不会事先知道大小(因此下载文件时不会显示"x％完成").
另一方面，如果您希望脚本运行很长一段时间(20秒钟以上)，则可能需要发送一些数据(例如空格)以防止浏览器超时连接. /p>
I just finished reading this post: https://developer.yahoo.com/performance/rules.html#flush and have already implemented a flush after the top portion of my page loads (head, css, top banner/search/nav).
Is there any performance hit in flushing? Is there such a thing as doing it too often? What are the best practices?
If I am going to hit an external API for data, would it make sense to flush before hand so that the user isn't waiting on that data to come back, and can at least get some data before hand?
The technique described looks nice, but has several pitfalls:
1) the time between PHP script start and end is small compared to transmission time; also, this saves the user about 0.5 seconds, according to your source. Is that a significant amount of time for you?
2) this technique doesn't work with gzip output buffering
3) if you flush too often, you'll be sending an almost-empty packet on flush, which might actually increase loading time (on slow, noisy connections).
4) once you flush, you can't send any more headers
5) (minor issue) the server response will come in chunked encoding, which means the client won't know the size in advance (therefore won't display "x% done" when downloading a file).
On the other hand, if you expect your script to run for a loooong time (20+ seconds), it may be needed to send some data (spaces, for example) to keep the browser from timing out the connection.
这篇关于PHP Flush:频率和最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
