Introduction to the use of php buffering output_buffering and ob_start

buffer

Buffer is a memory address space. The default size of Linux system is generally 4096 (4kb), which is one memory page. It is mainly used to store data transfer areas between devices with unsynchronized speeds or devices with different priorities. Through the buffer, the processes can wait less for each other. Here is a more general example. When you open a text editor to edit a file, every time you enter a character, the operating system will not immediately write the character directly to the disk, but first write it to the buffer. When writing When a buffer is full, the data in the buffer will be written to the disk. Of course, when the kernel function flush() is called, it is mandatory to write the dirty data in the buffer back to the disk.
Similarly, when echo and print are executed, the output is not immediately sent to the client browser for display through tcp, but the data is written to the php buffer. The php output_buffering mechanism means that a new queue is established before the tcp buffer, and data must pass through the queue. When a php buffer is full, the script process will hand over the output data in the php buffer to the system kernel and pass it to the browser via TCP for display. Therefore, the data will be written to these places in sequence echo/pring -> php buffer -> tcp buffer -> browser

php output_buffering

By default, php buffer is enabled, and the default value of the buffer is 4096, which is 4kb. You can find the output_buffering configuration in the php.ini configuration file. When echo, print, etc. output user data, the output data will be written to php output_buffering. Until output_buffering is full, the data will be sent to the browser through tcp. show. You can also manually activate the php output_buffering mechanism through ob_start(), so that even if the output exceeds 4kb of data, the data is not actually handed over to tcp and passed to the browser, because ob_start() sets the php buffer space to be large enough. The data will not be sent to the client browser until the end of the script or the ob_end_flush function is called.
1. When output_buffering=4096, and output less data (less than one buffer)

Copy code The code is as follows:

for ($i = 0; $i < 10; $i++) {
echo $i . '
';
sleep ($i + 1); //
}
?>

Phenomenon: Instead of intermittent output every few seconds, the output cannot be seen all at once until the response is completed. The browser interface remains blank until the server script processing is completed. This is because the amount of data is too small and php output_buffering is not full. The order of writing data is echo->php buffer->tcp buffer->browser
2. When output_buffering=0, and output less data (less than one buffer)

Copy code The code is as follows:

//Pass ini_set('output_buffering', 0) It does not take effect
//You should edit /etc/php.ini and set output_buffering=0 to disable the output buffering mechanism
//ini_set('output_buffering', 0); // Completely disable the output buffering function
for ($i = 0; $i < 10; $i++) {
echo $i . '
';
flush(); //Notify the bottom layer of the operating system and send the data to the client browser as soon as possible
($i + 1); //
}
?>

Phenomenon: It is not consistent with the display just now. After disabling the php buffering mechanism, you can see intermittent output in the browser, and you do not have to wait until the script is executed to see the output. This is because, the data does not stay in php output_buffering. The order of writing data is echo->tcp buffer->browser
3. When output_buffering=4096., the output data is larger than one buffer, and ob_start() is not called
to create a 4kb file
$dd if=/dev/zero of=f4096 bs=4096 count=1

Copy code The code is as follows:

for ($i = 0; $i < 10; $i++) {
echo file_get_contents('./f4096') . $i . '
';
sleep($i +1);
}
?>

Phenomena: The response has not ended (the http connection is not closed), intermittent output can be seen intermittently, and the browser interface will not remain blank. Although the php output_buffering mechanism is enabled, there is still intermittent output instead of one-time output because the output_buffering space is not enough. Every time a php buffering is filled, the data will be sent to the client browser. 4. When output_buffering=4096, the output data is larger than one tcp buffer, call ob_start()

Copy code The code is as follows:

ob_start(); //Enable php buffer
for ($i = 0; $i < 10; $i++) {
echo sleep($i + 1);
}
ob_end_flush();
?>

Phenomenon: You don’t see complete output until the server-side script processing is completed and the response ends. The output interval is so short that you can’t feel the pause. Before output, the browser maintains a blank interface, waiting for server data. This is because once PHP calls the ob_start() function, it will expand the PHP buffer to a large enough size. The data in the PHP buffer will not be sent to the client browser until the ob_end_flush function is called or the script ends.
tcpdump observation
Here, we monitor tcp messages through tcpdump to observe the difference between using ob_start() and not using it.
1. Not using ob_start()
12:30:21.499528 IP 192.168.0.8.webcache > 192.168.0.28.cymtec-port: . ack 485 win 6432 12:30:21.500127 IP 192.168.0.8.webc ache > 192.168.0.28.cymtec-port: . 1:2921(2920) ack 485 win 6432 12:30:21.501000 IP 192.168.0.8.webcache > 192.168.0.28.cymtec-port: . 2921:7301(43 80) ack 485 win 6432 12:30:21.501868 IP 192.168.0.8.webcache > 192.168.0.28.cymtec-port: P 7301:8412(1111) ack 485 win 643 12:30:24.502340 IP 192.168.0. 8.webcache > 192.168. 0.28.cymtec-port: . 8412:14252(5840) ack 485 win 6432 12:30:24.503214 IP 192.168.0.8.webcache > 192.168.0.28.cymtec-port: . 14252:15712(1460) ack 485 win 6432 12 :30:24.503217 IP 192.168.0.8.webcache > 192.168.0.28.cymtec- port: . 16624:23924(7300) ack 485 win 6432 12:30:31.506839 IP 192.168.0.8.webcache > 192.168.0.28.cymtec-port: P 23924:24836(912) ack 485 win 6432 1 2:30:42.508871 IP 192.168.0.8.webcache > 192.168.0.28.cymtec-port: . 24836:32136(7300) ack 485 win 6432 12:30:42.509744 IP 192.168.0.8.webcache > 192.168.0.28 .cymtec-port: P 32136 :33048(912) ack 485 win 6432 12:30:57.512137 IP 192.168.0.8.webcache > 192.168.0.28.cymtec-port: . 33048:40348(7300) ack 485 win 6432 12:30:57.5 13016 IP 192.168.0.8 .webcache > 192.168.0.28.cymtec-port: P 40348:41260(912) ack 485 win 6432 12:31:06.513912 IP 192.168.0.8.webcache > 192.168.0.28.cymtec-port: P 41260 :41265(5 ) ack 485 win 6432 12:31:06.514012 IP 192.168.0.8.webcache > 192.168.0.28.cymtec-port: F 41265:41265(0) ack 485 win 6432 12:31:06.514361 IP 192.168 .0.8.webcache > 192.168.0.28.cymtec-port:. ACK 486 Win 6432
2. Use OB_START ()
36: 06.542244 IP 192.168.0.8.Webcache & GT; 192.168.0.28.noagent:. ACK 485 W in 6432 12:36:51.559128 IP 192.168.0.8.webcache > 192.168.0.28.noagent: . 1:2921(2920) ack 485 win 6432 12:36:51.559996 IP 192.168.0.8.webcache > 192 .168.0.28.noagent: . 2921:7301(4380) ack 485 win 6432 12:36:51.560866 IP 192.168.0.8.webcache > 192.168.0.28.noagent: . 7301:11681(4380) ack 485 win 6432 12:36:51 .561612 IP 192.168.0.8. webcache > 192.168.0.28.noagent: . 11681:16061(4380) ack 485 win 6432 12:36:51.561852 IP 192.168.0.8.webcache > 192.168.0.28.noagent: . 441(4380) ack 485 win 6432 12:36:51.562479 IP 192.168.0.8.webcache > 192.168.0.28.noagent: . 20441:24821(4380) ack 485 win 6432 12:36:51.562743 IP 192.168.0.8.webcache > ; 192.168.0.28.noagent: . 24821:29201(4380) ack 485 win 6432 12:36:51.562996 IP 192.168.0.8.webcache > 192.168.0.28.noagent: . 29201:33581(4380) ack 485 win 6432 12:36 :51.563344 IP 192.168.0.8. webcache > 192.168.0.28.noagent: P 33581:35041(1460) ack 485 win 6432 12:36:51.563514 IP 192.168.0.8.webcache > 192.168.0.28.noagent: . 01(1460) ack 485 win 6432 12:36:51.563518 IP 192.168.0.8.webcache > 192.168.0.28.noagent: . 36501:37961(1460) ack 485 win 6432 12:36:51.563523 IP 192.168.0.8.webcache > ; 192.168.0.28.noagent: . 37961:39421(1460) ack 485 win 6432 12:36:51.563526 IP 192.168.0.8.webcache > 192.168.0.28.noagent: . 39421:40881(1460) ack 485 win 6432 12:36 :51.563529 IP 192.168.0.8. webcache > 192.168.0.28.noagent: FP 40881:41233(352) ack 485 win 6432 12:36:51.570364 IP 192.168.0.8.noagent: . ack 486 win 64 32
By the above By comparison, we can see that the time intervals of data packets are obviously different. Without using ob_start(), the time interval is relatively large, and the data in the tcp buffer is sent out after waiting for about 4 seconds. The data does not stay in the php buffer for too long, and the output data is sent to the client browser. This is because the php buffer is quickly filled up and the data has to be sent out. When ob_start() is enabled, it is different. Data packets are sent to the client almost at the same time. It can be inferred that the data stays in the php buffer until ob_end_flush() is called before the data in the php buffer is sent to the client browser.

output buffering function

1.ob_start

Activate the output_buffering mechanism. Once activated, the script output is no longer sent directly to the browser, but is temporarily written to the PHP buffer memory area.
php enables the output_buffering mechanism by default, but by calling the ob_start() function, the data output_buffering value is expanded to a large enough value. You can also specify $chunk_size to specify the value of output_buffering. The default value of $chunk_size is 0, which means that the data in the php buffer will not be sent to the browser until the end of the script. If you set the size of $chunk_size, it means that as long as the data length in the buffer reaches this value, the data in the buffer will be sent to the browser.
Of course, you can process the data in the buffer by specifying $ouput_callback. For example, the function ob_gzhandler compresses the data in the buffer and then sends it to the browser.

2.ob_get_contents

Get a copy of the data in the php buffer. It is worth noting that you should call this function within the ob_end_clean() function call, otherwise ob_get_contents() returns a null character.

3. ob_end_flush and ob_end_clean

These two functions are somewhat similar, both turn off the ouptu_buffering mechanism. But the difference is that ob_end_flush only flushes (flush/send) the data in the php buffer to the client browser, while ob_clean_clean clears (erase) the data in the php bufeer but does not send it to the client browser. After ob_end_flush is called, the data in the php buffer still exists, and ob_get_contents() can still obtain a copy of the data in the php buffer. After calling ob_end_clean(), ob_get_contents() gets an empty string, and the browser cannot receive the output, that is, there is no output.

Usage cases

Ob_start() is often seen used in some template engines and page file caches. Their traces can be found in well-known open source projects such as wordpress, drupal, smarty, etc. Here is the application of drupal.
Template file

Copy code The code is as follows:

//@file:user-profile.tpl.php
& Lt; ul & gt;
& lt; Li & gt; username: & lt;? PHP Echo $ user- & gt; name;? & Lt;/li & gt;
& li; Ture: & lt;? PHP echo $user->picture; ?>

//@file:template-render.php
function theme_render_template($template_file, $variables) {
if (!is_file( $template_file) { return ""; }
extract($variables, EXTR_SKIP);
ob_start();
$contents = ();
ob_end_clean();
return $contents;
}
?>

//@file:profile.php
$variables = array('user' => $user);
print theme_render_template('user-profile.tpl.php', $variables);
?>

Introduction to the use of php buffering output_buffering and ob_start_PHP tutorial