mod_proxy_fcgi and flush

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

mod_proxy_fcgi and flush

Helmut K. C. Tessarek
One of the comments on the documentation page of mod_proxy_fcgi
(http://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html) mentions an
issue with flush:

There is just no flush support it seems. I attempt to use PHP flush()
and it won't work until you fill up a buffer first, rendering Server
Sent Events impossible with proxy_fcgi. It worked very well with
"-flush" with mod_fastcgi FastCgiExternalServer.

If this is really the case, all web applications that use push
notifications won't be working with mod_proxy_fcgi.

The wiki page on https://wiki.apache.org/httpd/php also suggests to use
mod_proxy_fcgi, but if above is true, this might lead to problems.

What is your take on this?

--
regards Helmut K. C. Tessarek
lookup https://sks-keyservers.net/i for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Jim Jagielski
works 4 me... :/

> On Jul 6, 2017, at 2:08 PM, Helmut K. C. Tessarek <[hidden email]> wrote:
>
> One of the comments on the documentation page of mod_proxy_fcgi
> (http://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html) mentions an
> issue with flush:
>
> There is just no flush support it seems. I attempt to use PHP flush()
> and it won't work until you fill up a buffer first, rendering Server
> Sent Events impossible with proxy_fcgi. It worked very well with
> "-flush" with mod_fastcgi FastCgiExternalServer.
>
> If this is really the case, all web applications that use push
> notifications won't be working with mod_proxy_fcgi.
>
> The wiki page on https://wiki.apache.org/httpd/php also suggests to use
> mod_proxy_fcgi, but if above is true, this might lead to problems.
>
> What is your take on this?
>
> --
> regards Helmut K. C. Tessarek
> lookup https://sks-keyservers.net/i for KeyID 0xC11F128D
>
> /*
>   Thou shalt not follow the NULL pointer for chaos and madness
>   await thee at its end.
> */

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Jacob Champion-2
On 07/06/2017 11:13 AM, Jim Jagielski wrote:
> works 4 me...

Doesn't for me. E.g. with a script like

<?php
   print("hi!\n")
   flush();
   sleep(1);
   print("hi!\n");
?>

it takes 1 second to receive a single chunk with both lines in it.

 From a quick skim I assume this is because we don't use nonblocking
sockets in the proxy implementation. (There's even a note in
mod_proxy_fcgi that says, "Yes it sucks to [get the actual data] in a
second recv call, this will eventually change when we move to real
nonblocking recv calls.")

On 07/06/2017 11:08 AM, Helmut K. C. Tessarek wrote:
 > What is your take on this?

If I'm honest, my brutally blunt take on it is "stop using HTTP to try
to emulate push notifications within a single response; pretty much
everything in the ecosystem is actively working against you at this
point; responses are designed to be cacheable and deliverable as a unit,
not as multiple pieces; and we've had *real* solutions like WebSocket
for five years now rabble rabble rabble." But I don't actually think
that's going to be the accepted answer.

It probably makes sense to work on a nonblocking architecture for
proxied responses in general.

-Jacob
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Helmut K. C. Tessarek
On 2017-07-06 14:54, Jacob Champion wrote:
> If I'm honest, my brutally blunt take on it is "stop using HTTP to try
> to emulate push notifications within a single response; pretty much
> everything in the ecosystem is actively working against you at this
> point; responses are designed to be cacheable and deliverable as a unit,
> not as multiple pieces; and we've had *real* solutions like WebSocket
> for five years now rabble rabble rabble." But I don't actually think
> that's going to be the accepted answer.

In a perfect world, I'm right there with you, but we've seen (as long as
technology has existed) that people twist the way how technology is
applied and used. It's hard to convince those people otherwise,
especially when most of the time it has been possible to get it to work
- somehow.

> It probably makes sense to work on a nonblocking architecture for
> proxied responses in general.

I'm not familiar with that particular code, but would be interested in
looking into it. Does anybody volunteer as a mentor?

Cheers,
  K. C.

--
regards Helmut K. C. Tessarek
lookup https://sks-keyservers.net/i for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Jacob Champion-2
On 07/06/2017 08:25 PM, Helmut K. C. Tessarek wrote:
> On 2017-07-06 14:54, Jacob Champion wrote:
>> It probably makes sense to work on a nonblocking architecture for
>> proxied responses in general.
>
> I'm not familiar with that particular code, but would be interested in
> looking into it. Does anybody volunteer as a mentor?

I'm probably not the person you're looking for; I don't know the
mod_proxy code very well. You may find that my root cause analysis is
completely incorrect. But, if you'd like to bounce ideas off me, go for
it. (As Luca already knows, I can be a little sporadic when it comes to
this sort of thing. Fair warning! :) )

#httpd-dev on Freenode is also a place -- very quiet, usually, but I try
to be there when I can.

--Jacob
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Helmut K. C. Tessarek
On 2017-07-07 17:50, Jacob Champion wrote:
> I'm probably not the person you're looking for; I don't know the
> mod_proxy code very well. You may find that my root cause analysis is
> completely incorrect. But, if you'd like to bounce ideas off me, go
> for it. (As Luca already knows, I can be a little sporadic when it
> comes to this sort of thing. Fair warning! :) )

I'm gonna have a look at the mod_proxy and mod_proxy_fcgi code. Who
wrote the code in the first place? Maybe I can bug that person with my
questions. ;-)
Let's see, maybe I'm totally out of my depth anyway. Sometimes it's very
hard to chime in, when you haven't been there from the beginning.

> #httpd-dev on Freenode is also a place -- very quiet, usually, but I
> try to be there when I can.

Yea, not a fan of irc. I always find it very frustrating. Asking
something, waiting forever, not getting any answers. I'm more into IM.
I've noticed that people on IM are more responsive, since they really
seem to be online when the status says they are online.
Anyway, I don't think that real time chat is necessary, at least not
right away.


--
regards Helmut K. C. Tessarek
lookup https://sks-keyservers.net/i for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Luca Toscano
In reply to this post by Jacob Champion-2
Hi Jacob, Helmut!

2017-07-06 20:54 GMT+02:00 Jacob Champion <[hidden email]>:
On 07/06/2017 11:13 AM, Jim Jagielski wrote:
works 4 me...

Doesn't for me. E.g. with a script like

<?php
  print("hi!\n")
  flush();
  sleep(1);
  print("hi!\n");
?>

it takes 1 second to receive a single chunk with both lines in it.

From a quick skim I assume this is because we don't use nonblocking sockets in the proxy implementation. (There's even a note in mod_proxy_fcgi that says, "Yes it sucks to [get the actual data] in a second recv call, this will eventually change when we move to real nonblocking recv calls.")

Quick check from my side too, so not sure if it makes sense. IIUC the comment is about getting all the headers from the FCGI backend (get_data_full(..., AP_FCGI_HEADER_LEN)), then get the response body in another one (the [actual data]). 

I checked mod_fcgi as Helmut suggested and it seems to me that the -flush feature is a simple "flush every data that you receive", so I tested the following patch with Jacob's php example code and it seems doing what Helmut asked (please correct me if I am wrong).

Caveat: I had to set output_buffering = Off in my php-fpm's php.ini config file.


I am still not sure if the get_data function (responsible to read the body after the headers in dispatch()) works in this way only my local test or not, but it seems simply calling apr_socket_recv with a buffer len and return whatever data it comes from the backend. IIUC apr_socket_recv should return data even if less than the buffer specified..

So if what I wrote vaguely makes sense, we might think about adding a new directive that enables explicit flushing to mod_proxy_fcgi, so admins can twist its behavior if needed?

 
On 07/06/2017 11:08 AM, Helmut K. C. Tessarek wrote:
> What is your take on this?

If I'm honest, my brutally blunt take on it is "stop using HTTP to try to emulate push notifications within a single response; pretty much everything in the ecosystem is actively working against you at this point; responses are designed to be cacheable and deliverable as a unit, not as multiple pieces; and we've had *real* solutions like WebSocket for five years now rabble rabble rabble." But I don't actually think that's going to be the accepted answer.

It probably makes sense to work on a nonblocking architecture for proxied responses in general.

-Jacob

Completely agree with Jacob, this use case might not be the best one for HTTP :)

Luca 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Helmut K. C. Tessarek
Hi Luca,

Thanks for looking into this.

On 2017-07-08 03:51, Luca Toscano wrote:
> I checked mod_fcgi as Helmut suggested and it seems to me that the
> -flush feature is a simple "flush every data that you receive", so I
> tested the following patch with Jacob's php example code and it seems
> doing what Helmut asked (please correct me if I am wrong).

No, you are correct. But I was merely referring to the comment on the
documentation page.
But yes, this seems to mirror the "-flush" option that is present for
FastCgiExternalServer.

> Caveat: I had to set output_buffering = Off in my php-fpm's php.ini
> config file.

This should be ok, since people who are using output buffering are
usually aware that it can influence the app's behaviour. I think that
was even stated in the PHP manual somewhere.
Although I also remember that there was a section that states that both
ob_flush() and flush() have to be called to make flush work with output
buffering on.

> So if what I wrote vaguely makes sense, we might think about adding a
> new directive that enables explicit flushing to mod_proxy_fcgi, so
> admins can twist its behavior if needed?

As far as I can tell it makes sense, but I haven't gone through the
entire proxy code yet.

Are you thinking of a directive like ProxyFCGIFlush or an option to the
proxy worker:

<Proxy "fcgi://localhost/" flush=yes>
</Proxy>

> Completely agree with Jacob, this use case might not be the best one for
> HTTP :)

As mentioned before, in a perfect world I'd agree. But this option was
available with FastCgiExternalServer, thus it should be available with
proxy_fcgi as well, especially when proxy_fcgi is the preferred way for
Apache >= 2.4.

Cheers,
 K. C.

--
regards Helmut K. C. Tessarek
lookup https://sks-keyservers.net/i for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Nick Kew-3
In reply to this post by Helmut K. C. Tessarek
On Thu, 2017-07-06 at 14:08 -0400, Helmut K. C. Tessarek wrote:
> One of the comments on the documentation page of mod_proxy_fcgi
> (http://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html) mentions an
> issue with flush:
>
> There is just no flush support it seems. I attempt to use PHP flush()
> and it won't work until you fill up a buffer first, rendering Server
> Sent Events impossible with proxy_fcgi.

Do we have any idea what (if anything) proxy_fcgi receives from a
PHP flush()?  Your fix could be as simple as propagating an event.

> > In a perfect world, I'm right there with you, but we've seen (as long as
> > technology has existed) that people twist the way how technology is
> > applied and used. It's hard to convince those people otherwise,
> > especially when most of the time it has been possible to get it to work

That takes me back ...
https://www.theregister.co.uk/2007/08/24/everything_over_http/

> > > It probably makes sense to work on a nonblocking architecture for
> > > proxied responses in general.

Is that really the issue in the first place?  We have a concept of
flushing, and can implement more finely-tuned throughput than merely
blocking vs non-blocking.  The point at issue is for PHP to communicate
a flush with proxy_fcgi, and for proxy_fcgi then to honour it.
It seems one or both of those things isn't happening.

> > I'm not familiar with that particular code, but would be interested in
> > looking into it. Does anybody volunteer as a mentor?

Best mentor is this list.  Or #httpd-dev on Freenode (IRC),
if someone's paying attention there.

> lookup https://sks-keyservers.net/i for KeyID 0xC11F128D

Please update that: it's too easy to spoof.
See https://evil32.com/ , or my blog article at
https://bahumbug.wordpress.com/2017/04/27/pretty-good-phishing/

--
Nick Kew

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Jacob Champion-2
On Jul 8, 2017 6:14 PM, "Nick Kew" <[hidden email]> wrote:
> > > It probably makes sense to work on a nonblocking architecture for
> > > proxied responses in general.

Is that really the issue in the first place?  We have a concept of
flushing, and can implement more finely-tuned throughput than merely
blocking vs non-blocking.  The point at issue is for PHP to communicate
a flush with proxy_fcgi, and for proxy_fcgi then to honour it.
It seems one or both of those things isn't happening.

Not sure yet, but based on Luca's note, I think there's a good chance that my skim of the code gave me the wrong idea. If FPM sends a full message in a flush (and I can't see why it wouldn't) this might be fixable with a single FPM option.

--Jacob
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: mod_proxy_fcgi and flush

Plüm, Rüdiger, Vodafone Group
In reply to this post by Luca Toscano

 

 

Von: Luca Toscano [mailto:[hidden email]]
Gesendet: Samstag, 8. Juli 2017 09:52
An: Apache HTTP Server Development List <[hidden email]>
Betreff: Re: mod_proxy_fcgi and flush

 

Hi Jacob, Helmut!

 

2017-07-06 20:54 GMT+02:00 Jacob Champion <[hidden email]>:

On 07/06/2017 11:13 AM, Jim Jagielski wrote:

works 4 me...


Doesn't for me. E.g. with a script like

<?php
  print("hi!\n")
  flush();
  sleep(1);
  print("hi!\n");
?>

it takes 1 second to receive a single chunk with both lines in it.

From a quick skim I assume this is because we don't use nonblocking sockets in the proxy implementation. (There's even a note in mod_proxy_fcgi that says, "Yes it sucks to [get the actual data] in a second recv call, this will eventually change when we move to real nonblocking recv calls.")

 

Quick check from my side too, so not sure if it makes sense. IIUC the comment is about getting all the headers from the FCGI backend (get_data_full(..., AP_FCGI_HEADER_LEN)), then get the response body in another one (the [actual data]). 

 

I checked mod_fcgi as Helmut suggested and it seems to me that the -flush feature is a simple "flush every data that you receive", so I tested the following patch with Jacob's php example code and it seems doing what Helmut asked (please correct me if I am wrong).

 

Caveat: I had to set output_buffering = Off in my php-fpm's php.ini config file.

 

http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_fcgi-force_flush.patch

 

Flushing unconditionally is a bad idea performance wise. Please have a look how ajp solved this issue:

 

https://svn.apache.org/r327185

https://svn.apache.org/r384580

https://svn.apache.org/r390210

https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_ajp.c?r1=325879&r2=390210

 

Hint: The above diff contains further unrelated changes.

 

Regards

 

Rüdiger

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Luca Toscano
Hi Rüdiger,

2017-07-10 8:31 GMT+02:00 Plüm, Rüdiger, Vodafone Group <[hidden email]>:

 

 

Von: Luca Toscano [mailto:[hidden email]]
Gesendet: Samstag, 8. Juli 2017 09:52
An: Apache HTTP Server Development List <[hidden email]>
Betreff: Re: mod_proxy_fcgi and flush

 

Hi Jacob, Helmut!

 

2017-07-06 20:54 GMT+02:00 Jacob Champion <[hidden email]>:

On 07/06/2017 11:13 AM, Jim Jagielski wrote:

works 4 me...


Doesn't for me. E.g. with a script like

<?php
  print("hi!\n")
  flush();
  sleep(1);
  print("hi!\n");
?>

it takes 1 second to receive a single chunk with both lines in it.

From a quick skim I assume this is because we don't use nonblocking sockets in the proxy implementation. (There's even a note in mod_proxy_fcgi that says, "Yes it sucks to [get the actual data] in a second recv call, this will eventually change when we move to real nonblocking recv calls.")

 

Quick check from my side too, so not sure if it makes sense. IIUC the comment is about getting all the headers from the FCGI backend (get_data_full(..., AP_FCGI_HEADER_LEN)), then get the response body in another one (the [actual data]). 

 

I checked mod_fcgi as Helmut suggested and it seems to me that the -flush feature is a simple "flush every data that you receive", so I tested the following patch with Jacob's php example code and it seems doing what Helmut asked (please correct me if I am wrong).

 

Caveat: I had to set output_buffering = Off in my php-fpm's php.ini config file.

 

http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_fcgi-force_flush.patch

 

Flushing unconditionally is a bad idea performance wise. Please have a look how ajp solved this issue:

 

https://svn.apache.org/r327185

https://svn.apache.org/r384580

https://svn.apache.org/r390210

https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_ajp.c?r1=325879&r2=390210

 

Hint: The above diff contains further unrelated changes.



Definitely, I added that quick and dirty patch to show my idea, really far from being ready for a commit :)
Will review the commits that you posted, thanks!

Luca 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Luca Toscano


2017-07-10 11:42 GMT+02:00 Luca Toscano <[hidden email]>:
Hi Rüdiger,

2017-07-10 8:31 GMT+02:00 Plüm, Rüdiger, Vodafone Group <[hidden email]>:

 

 

Von: Luca Toscano [mailto:[hidden email]]
Gesendet: Samstag, 8. Juli 2017 09:52
An: Apache HTTP Server Development List <[hidden email]>
Betreff: Re: mod_proxy_fcgi and flush

 

Hi Jacob, Helmut!

 

2017-07-06 20:54 GMT+02:00 Jacob Champion <[hidden email]>:

On 07/06/2017 11:13 AM, Jim Jagielski wrote:

works 4 me...


Doesn't for me. E.g. with a script like

<?php
  print("hi!\n")
  flush();
  sleep(1);
  print("hi!\n");
?>

it takes 1 second to receive a single chunk with both lines in it.

From a quick skim I assume this is because we don't use nonblocking sockets in the proxy implementation. (There's even a note in mod_proxy_fcgi that says, "Yes it sucks to [get the actual data] in a second recv call, this will eventually change when we move to real nonblocking recv calls.")

 

Quick check from my side too, so not sure if it makes sense. IIUC the comment is about getting all the headers from the FCGI backend (get_data_full(..., AP_FCGI_HEADER_LEN)), then get the response body in another one (the [actual data]). 

 

I checked mod_fcgi as Helmut suggested and it seems to me that the -flush feature is a simple "flush every data that you receive", so I tested the following patch with Jacob's php example code and it seems doing what Helmut asked (please correct me if I am wrong).

 

Caveat: I had to set output_buffering = Off in my php-fpm's php.ini config file.

 

http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_fcgi-force_flush.patch

 

Flushing unconditionally is a bad idea performance wise. Please have a look how ajp solved this issue:

 

https://svn.apache.org/r327185

https://svn.apache.org/r384580

https://svn.apache.org/r390210

https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_ajp.c?r1=325879&r2=390210

 

Hint: The above diff contains further unrelated changes.



Definitely, I added that quick and dirty patch to show my idea, really far from being ready for a commit :)
Will review the commits that you posted, thanks!


 With a bit of delay I have something to share to the list :)

I kept the following test as the "use case":

<?php
  print("hi!\n")
  flush();
  sleep(1);
  print("hi!\n");
?>

First of all, I tested it with httpd-trunk and it seems working fine thanks to several core non-blocking writes, removing the need of explicit FLUSH buckets. I am very ignorant about this part of httpd so I can't say much more, but it is really nice to see! 

I then checked Rüdiger's commits and this is my understanding about mod_ajp:

- if "flushpackets" is set to "on" by mod_proxy then mod_proxy_ajp will insert a FLUSH bucket as soon as data is ready to be passed to the output filter chain.
- if "flushpackets" is set to "auto" then mod_proxy_ajp will be a bit smarter and will apr_poll for "flushwait" seconds before inserting any FLUSH bucket, since new data might come from the backend and it would be more efficient to force a FLUSH with more data.

IIUC mod_proxy_fcgi leverages the fact that the backend sends FCGI records with a predefined structure (FCGI_Record), containing "FCGI headers" (content len, padding len, version, type, etc..) that can be used to know how much data to expect from the backend. As far as I can see (with php-fpm) our use case is handled with multiple FCGI records, one for each "flush()" done in the php script. mod_proxy_fcgi does the following for each of them:

1) read the FCGI headers to gather how much data the record is carrying (clen)
2) read the data in iobuf_size batches, sending each time the bytes collected to the output filter chain.
3) finally read the padding bytes (if any).

I tried to use the same trick as mod_ajp for flushpackets=auto, but apr_poll returned immediately most of the times due to the padding bytes ready to read (took me a while to realize this simple thing).

I didn't find a real use case for flushpackets=auto in mod_proxy_fcgi, but I have two proposals for fluspackets=on:


The second one is a bit more conservative and does not insert the FLUSH bucket if it knows that the content len (clen) is bigger than the iobuf_size (since there is a goto that forces another get_data() in this case).

Let me know if what I wrote make sense, suggestions and comments are welcome. It would be interesting to also know from Helmut a simple (PHP?) use case to use as a test, so I'll not base my code only on Jacob's example (that was really useful though!!).

Thanks!

Luca

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Ruediger Pluem


On 07/13/2017 07:36 PM, Luca Toscano wrote:

> I didn't find a real use case for flushpackets=auto in mod_proxy_fcgi, but I have two proposals for fluspackets=on:
>
> http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_fcgi-force_flush.patch
> http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_fcgi-force_flush-v2.patch
>
> The second one is a bit more conservative and does not insert the FLUSH bucket if it knows that the content len (clen)
> is bigger than the iobuf_size (since there is a goto that forces another get_data() in this case).

I only looked at it very briefly, but from that I would favor v2 of the patch.

Regards

Rüdiger
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Yann Ylavic
In reply to this post by Luca Toscano
On Thu, Jul 13, 2017 at 7:36 PM, Luca Toscano <[hidden email]> wrote:

>
> 1) read the FCGI headers to gather how much data the record is carrying
> (clen)
> 2) read the data in iobuf_size batches, sending each time the bytes
> collected to the output filter chain.
> 3) finally read the padding bytes (if any).
>
> I tried to use the same trick as mod_ajp for flushpackets=auto, but apr_poll
> returned immediately most of the times due to the padding bytes ready to
> read (took me a while to realize this simple thing).

I forgot some details about proxy_fcgi so am asking before (re)looking at it :p

Can't we poll() after 3) ?
If so, maybe we could flush only if a small/zero timeout poll() times
out, and hence still be able to coalesce multiple (closed) records.


Regards,
Yann.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Helmut K. C. Tessarek
In reply to this post by Luca Toscano
Hi Luca,

On 2017-07-13 13:36, Luca Toscano wrote:
> It would be interesting to also know from Helmut a simple (PHP?) use
> case to use as a test, so I'll not base my code only on Jacob's example
> (that was really useful though!!).

I don't have a specific example. I referred to a comment on the
proxy_fcgi documentation web page in my first post in this thread.

It struck me as odd that flushing was possible with an option for
FastCgiExternalServer, but apparently not available in a proxy_fcgi setup.

I recently switched my setup to an event mpm with php-fpm and
proxy_fcgi. I'm also still working out a few kinks with mod_rewrite
which seems to behave differently all of a sudden. When I can't figure
it out by reading the debug logs, I will most likely post another
question on this mailing list. ;-)
IMO the same rules should yield the same results, no matter the backend.
Anyway, I'm getting off-topic here...

--
regards Helmut K. C. Tessarek              KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Luca Toscano
In reply to this post by Yann Ylavic
Hi Yann,

2017-07-13 22:15 GMT+02:00 Yann Ylavic <[hidden email]>:
On Thu, Jul 13, 2017 at 7:36 PM, Luca Toscano <[hidden email]> wrote:
>
> 1) read the FCGI headers to gather how much data the record is carrying
> (clen)
> 2) read the data in iobuf_size batches, sending each time the bytes
> collected to the output filter chain.
> 3) finally read the padding bytes (if any).
>
> I tried to use the same trick as mod_ajp for flushpackets=auto, but apr_poll
> returned immediately most of the times due to the padding bytes ready to
> read (took me a while to realize this simple thing).

I forgot some details about proxy_fcgi so am asking before (re)looking at it :p

Can't we poll() after 3) ?
If so, maybe we could flush only if a small/zero timeout poll() times
out, and hence still be able to coalesce multiple (closed) records.

http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_fcgi-force_flush-v3.patch created, I tested it quickly and it seems working fine (still unsure about using r->connection->pool vs conn->pool in palloc). More tests following in the weekend :)

Thanks for the hint!

Luca
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: mod_proxy_fcgi and flush

Plüm, Rüdiger, Vodafone Group

 

 

Von: Luca Toscano [mailto:[hidden email]]
Gesendet: Freitag, 14. Juli 2017 11:30
An: Apache HTTP Server Development List <[hidden email]>
Betreff: Re: mod_proxy_fcgi and flush

 

Hi Yann,

 

2017-07-13 22:15 GMT+02:00 Yann Ylavic <[hidden email]>:

On Thu, Jul 13, 2017 at 7:36 PM, Luca Toscano <[hidden email]> wrote:
>
> 1) read the FCGI headers to gather how much data the record is carrying
> (clen)
> 2) read the data in iobuf_size batches, sending each time the bytes
> collected to the output filter chain.
> 3) finally read the padding bytes (if any).
>
> I tried to use the same trick as mod_ajp for flushpackets=auto, but apr_poll
> returned immediately most of the times due to the padding bytes ready to
> read (took me a while to realize this simple thing).

I forgot some details about proxy_fcgi so am asking before (re)looking at it :p

Can't we poll() after 3) ?
If so, maybe we could flush only if a small/zero timeout poll() times
out, and hence still be able to coalesce multiple (closed) records.

 

http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_fcgi-force_flush-v3.patch created, I tested it quickly and it seems working fine (still unsure about using r->connection->pool vs conn->pool in palloc). More tests following in the weekend :)

 

r->pool is the correct pool to use.

 

Regards

 

Rüdiger

 

Thanks for the hint!

 

Luca

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Yann Ylavic
On Fri, Jul 14, 2017 at 11:38 AM, Plüm, Rüdiger, Vodafone Group
<[hidden email]> wrote:>
> Von: Luca Toscano [mailto:[hidden email]] Gesendet:
>>
>> http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_fcgi-force_flush-v3.patch

LGTM (with r->pool as suggested by Rüdiger below), thanks Luca.

>>
>> created, I tested it quickly and it seems working fine (still
>> unsure about using r->connection->pool vs conn->pool in palloc).
>> More tests following in the weekend :)
>
> r->pool is the correct pool to use.

+1
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_proxy_fcgi and flush

Jim Jagielski
In reply to this post by Plüm, Rüdiger, Vodafone Group
Agreed. r->pool for the win.

> On Jul 14, 2017, at 5:38 AM, Plüm, Rüdiger, Vodafone Group <[hidden email]> wrote:
>
>  
>  
> Von: Luca Toscano [mailto:[hidden email]]
> Gesendet: Freitag, 14. Juli 2017 11:30
> An: Apache HTTP Server Development List <[hidden email]>
> Betreff: Re: mod_proxy_fcgi and flush
>  
> Hi Yann,
>  
> 2017-07-13 22:15 GMT+02:00 Yann Ylavic <[hidden email]>:
> On Thu, Jul 13, 2017 at 7:36 PM, Luca Toscano <[hidden email]> wrote:
> >
> > 1) read the FCGI headers to gather how much data the record is carrying
> > (clen)
> > 2) read the data in iobuf_size batches, sending each time the bytes
> > collected to the output filter chain.
> > 3) finally read the padding bytes (if any).
> >
> > I tried to use the same trick as mod_ajp for flushpackets=auto, but apr_poll
> > returned immediately most of the times due to the padding bytes ready to
> > read (took me a while to realize this simple thing).
>
> I forgot some details about proxy_fcgi so am asking before (re)looking at it :p
>
> Can't we poll() after 3) ?
> If so, maybe we could flush only if a small/zero timeout poll() times
> out, and hence still be able to coalesce multiple (closed) records.
>  
> http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_fcgi-force_flush-v3.patch created, I tested it quickly and it seems working fine (still unsure about using r->connection->pool vs conn->pool in palloc). More tests following in the weekend :)
>  
> r->pool is the correct pool to use.
>  
> Regards
>  
> Rüdiger
>  
> Thanks for the hint!
>  
> Luca

12
Loading...