On Thu, Oct 18, 2018 at 12:51:06PM +0200, Ruediger Pluem wrote:
> >>>
> >>> Curiously inefficient writev use when stracing the process, though,
> >>> dunno what's going on there (trunk/prefork):
> >>>
> >>> writev(46, [{iov_base="\r\n", iov_len=2}], 1) = 2
> >>> writev(46, [{iov_base="1f84\r\n", iov_len=6}], 1) = 6
> >>> writev(46, [{iov_base="<D:lockdiscovery/>\n<D:getcontent"...,
> >>> iov_len=7820}], 1) = 7820
> >>> writev(46, [{iov_base="<D:supportedlock>\n<D:lockentry>\n"...,
> >>> iov_len=248}], 1) = 248
> >>
> >> The reason is ap_request_core_filter. It iterates over the brigade and
> >> hands over each bucket alone to
> >> ap_core_output_filter. IMHO a bug.
> >
> > How about the attached patch for fixing?
>
> Scratch that. I guess it is much more complex.
Hmm, well it works for me and looks correct, it batches up those the
writev(,,1) calls as expected, but it seems YMMV :)
I notice the function is doing unconditional blocking reads without
flushing first - rule 10 of the golden rules of output filters! --
status = apr_bucket_read(bucket, &data, &size, APR_BLOCK_READ);
