Hi Cyril, On Sat, Dec 25, 2010 at 10:28:54PM +0100, Cyril Bonté wrote: > Hi all, > > Le jeudi 9 décembre 2010 07:40:20, ?????? a écrit : > > My english is very poor. If nginx proxy server is front of haproxy > > server with option http-pretent-keeplive , the requests become very > > slow. But is normal of direct request to haproxy server . > > please help me. > > Changrong.zhou > > I think I could reproduce the same issue, with and whithout nginx, with this > short configuration sample (with KeepAliveTimeout 15 on the apache backend) : > listen close_test :8080 > mode http > option httpclose > option http-pretend-keepalive > server www localhost:80 > > listen tunnel_test :8081 > mode http > option http-pretend-keepalive > server www localhost:80 > > Both have problems nginx (unless I disabled buffering in nginx). > But it's also reproducible with ab : > $ ab -n1 http://localhost:8080/ > Time taken for tests: 15.017 seconds > > $ ab -n1 http://localhost:8081/ > Time taken for tests: 15.016 seconds > > $ ab -n1 http://localhost:8082/ > Time taken for tests: 15.016 seconds
It's nice that you managed to reproduce it ! I'm not sure how you managed to get it though because you're saying that you have it with and without nginx. > It appeared with this commit : > http://haproxy.1wt.eu/git?p=haproxy-1.4.git;a=commit;h=2be7ec90fa9caf66294f446423bbab2d00db9004 > > Willy, can you review the patch below to see if it's the right approach ? > Thanks ;-) [ I unwrapped your patch because apparently your mailer did not like it ] > --- haproxy-1.4.10/src/proto_http.c 2010-11-29 07:36:47.000000000 +0100 > +++ haproxy-1.4.10-ka/src/proto_http.c 2010-12-25 21:58:29.943435278 > +0100 > @@ -3057,9 +3057,11 @@ > del_cl = del_ka = 0; > > if ((!(txn->flags & TX_HDR_CONN_PRS) && > - (s->fe->options & (PR_O_KEEPALIVE|PR_O_SERVER_CLO|PR_O_HTTP_CLOSE| > PR_O_FORCE_CLO))) || > + (s->fe->options & (PR_O_KEEPALIVE|PR_O_SERVER_CLO|PR_O_HTTP_CLOSE| > PR_O_FORCE_CLO)) || > + (s->fe->options2 & PR_O2_FAKE_KA)) || > ((s->fe->options & (PR_O_KEEPALIVE|PR_O_SERVER_CLO|PR_O_HTTP_CLOSE| > PR_O_FORCE_CLO)) != > - (s->be->options & (PR_O_KEEPALIVE|PR_O_SERVER_CLO|PR_O_HTTP_CLOSE| > PR_O_FORCE_CLO)))) { > + (s->be->options & (PR_O_KEEPALIVE|PR_O_SERVER_CLO|PR_O_HTTP_CLOSE| > PR_O_FORCE_CLO))) || > + ((s->fe->options2 & PR_O2_FAKE_KA) != (s->be->options & > > PR_O2_FAKE_KA))) { ^^^ Here above it should be "options2". I must say I'm having difficulties to understand the logics. The rule is becoming quite complex, so we should probably first try to define how we'd like pretend-keep-alive to work in various cases. In my opinion, this option's goal is to make a server think we're sending it a keep-alive request so that it can announce a valid content-length or chunking to the client, eventhough we intend to close its connection. So what I'm thinking is that this option should only be considered if either "httpclose", "forceclose" or "http-server-close" is enabled in either the frontend or backend, or if the request indicates a close. I also think that if we have httpclose (or the request indicated a close) with the option set, then we can assume the server will not close after its response, which can make the client wait for a timeout. Thus, we should probably turn the response to a forced close in this case. Do you agree with that ? Is it what you wanted to do ? Do you see any other case that must be covered ? Thanks, Willy
