Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

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