On 02/01/2016 03:54 PM, Yann Ylavic wrote: > On Mon, Feb 1, 2016 at 3:32 PM, Ruediger Pluem <rpl...@apache.org> wrote: >>> >>> I am fine with flushing at the end of the loop. If no one opposes I can do >>> this. >>> >> >> Looking into this in more detail the following thoughts came up: >> >> What do we think how much iterations do we do in this loop in the typical >> case >> a.k.a how often do we call ap_get_brigade with a non blocking read? >> My gut feeling tells me that we only do this once at least in the websocket >> case. > > I guess it depends on the size of the outgoing traffic, it the backend > sometimes sends large data at once we may end up needing more than one > non-blocking read (AP_IOBUFSIZE/8K each) to forward the fragments.
True and I guess this is often the case for mod_proxy_connect. For mod_proxy_wstunnel I would expect that we see stuff below 8k, e.g. chat messages and alike in most use cases. > >> If this is the case the discussion whether to flush after the loop or in the >> loop wouldn't be >> relevant any longer, but more important: >> If it is ok to flush in the loop I think it would be better to add the flush >> bucket >> directly to bb_out instead of calling ap_fflush afterwards. The reason for >> this is >> that it gives downstream filters a better information on what they should do. > > +1 > >> With the current >> approach they might set the buckets aside and store them for later >> processing and only >> process them in the second round when they see the flush. If the flush would >> be on the first >> brigade at least some of them would process the buckets directly without >> setting them aside. >> Comments? > > That's the "issue" with transient buckets, the core output will almost > always set them aside if not flushed (including in the mod_proxy_http > case). > It wouldn't have to (or this would be a noop) if the buckets were > allocated on its bucket_alloc instead of the origin's. > But I agree that for now your approach makes sense. I guess I will hack something up and we discuss further once I have a proposal. Regards Rüdiger
