On Sat, 8 Jun 2002, Brian Pane wrote:
> 1.3:
> writev(3, [{"HTTP/1.1 200 OK\r\nDate: Sat, 08 J"..., 4089}, {"28\r\n",
> 4}, {"<tr valign=\"baseline\" bgcolor=\"#"..., 40}, {"\r\n", 2}], 4) = 4135
> write(3, "ffb\r\n<td bgcolor=\"#ccccff\"><b>as"..., 4098) = 4098
...
> 2.0:
> writev(8, [{"HTTP/1.1 200 OK\r\nDate: Sat, 08 J"..., 220}, {"47\r\n",
> 4}, {"<!DOCTYPE HTML PUBLIC \"-//W3C//D"..., 71}, {"\r\n", 2}], 4) = 297
> writev(8, [{"6\r\n", 3}, {"<head>", 6}, {"\r\n", 2}], 3) = 11
> writev(8, [{"1c\r\n", 4}, {"<style type=\"text/css\"><!--\n", 28},
>
> It looks like "unbuffered" PHP output in 1.3 is benefitting from the
> httpd's own buffering. And "unbuffered" output in 2.0, in contrast,
> is really, really not buffered, because of the flush buckets inserted
> by php_apache_sapi_ub_write.
If the unbuffered write really *is* allowed to be buffered (wtf?), then by
all means we should change to using apr_brigade_write() there instead of
the flush() buckets. The data that gets passed to ub_write() is transient
in lifetime so apr_brigade_write() will be forced to copy it, but that's
better than sending out 11 byte packets by a long shot.
--Cliff
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
