Re: PROXY protocol and setting headers X-Forwarded-Protocol=https ou X-Forwarded-Ssl=on

2011-09-19 Thread Brane F. Gračnar
On Monday 19 of September 2011 06:18:45 Willy Tarreau wrote:
frontend xxx
bind 1.2.3.4:80
bind /var/run/haproxy/sock-xxx accept-proxy
 
 But this requires that the ssl termination supports unix sockets and I
 believe that stud currently does not.

Just a quick question, Willy; I read somewhere, that zero-copy is not 
supported on unix sockets; Is this true? If yes, does that also affect linux 
tcp splicing?

Regards, Brane



Re: PROXY protocol and setting headers X-Forwarded-Protocol=https ou X-Forwarded-Ssl=on

2011-09-19 Thread Willy Tarreau
On Mon, Sep 19, 2011 at 09:54:16AM +0200, Brane F. Gra??nar wrote:
 On Monday 19 of September 2011 06:18:45 Willy Tarreau wrote:
 frontend xxx
 bind 1.2.3.4:80
 bind /var/run/haproxy/sock-xxx accept-proxy
  
  But this requires that the ssl termination supports unix sockets and I
  believe that stud currently does not.
 
 Just a quick question, Willy; I read somewhere, that zero-copy is not 
 supported on unix sockets; Is this true? If yes, does that also affect linux 
 tcp splicing?

I have some memories of this too, because haproxy only enables splicing if
both ends are pure TCP sockets. So I assume that if I have added this test,
it is because it did not work otherwise ;-)

Cheers,
Willy




RE: Apache translates 500 to 502 from haproxy

2011-09-19 Thread Sachin Shetty
Hey Willy,

So we are now hit by the side effect of this fix i.e. disabling httpclose. 

Two problems:

1. Entries in the log are missing, I guess you already warned me about it.
Do you think if we disable keep alive in our Apache fronting haproxy, this
will problem will go away?
2. Related to one, but an interesting one. 
  - A request comes to haproxy, as configured after waiting in haproxy
queue for 10 seconds due to backend free connection unavailable, it sends a
503 back, logged correctly in haproxy and apache
  - The client retries, I think with Keep Alive over the same connection
and it sees a 400 status back. Now this request is no where in haproxy logs
so there is no way to see what happened in haproxy and who really dropped
the ball. The connection never made it to the backed cherrypy server since
it logs each request it receives.

Thanks
Sachin




-Original Message-
From: Sachin Shetty [mailto:sshe...@egnyte.com] 
Sent: Wednesday, June 15, 2011 5:23 PM
To: 'Willy Tarreau'
Cc: 'Cassidy, Bryan'; 'haproxy@formilux.org'
Subject: RE: Apache translates 500 to 502 from haproxy

tried with option http-server-close instead of option httpclose - no luck it
does not work. The only way I can get it to work is without either.

Thanks
Sachin

-Original Message-
From: Willy Tarreau [mailto:w...@1wt.eu] 
Sent: Wednesday, June 15, 2011 12:40 PM
To: Sachin Shetty
Cc: 'Cassidy, Bryan'; haproxy@formilux.org
Subject: Re: Apache translates 500 to 502 from haproxy

On Wed, Jun 15, 2011 at 12:11:58PM +0530, Sachin Shetty wrote:
 I also think apache is the issue. I think we have a few mischievous
modules
 like mod_rpaf that I need to disable and test. I will keep you posted. 
 
 For now do you see any severe problem if I disabe httpclose as a
workaround?

As I said, in theory no, unless you need haproxy to analyse more than one
request per connection. But please do make a test with http-server-close.
While there is little chance that it helps, it's not completely impossible
because it is able to reinforce keep-alive on the client side even if it is
disable on the server side.

Willy




Re: Proxy Protocol in 1.4.x ?

2011-09-19 Thread Baptiste
Hi there,

Finally, we've finished our bench on SSL tools available for HAProxy:
stud and stunnel.
Please read the benchmark here:

http://blog.exceliance.fr/2011/09/16/benchmarking_ssl_performance/

cheers



Caching

2011-09-19 Thread Christophe Rahier
Hi,

Is there a caching system at HAProxy?

In fact, we find that when we put online new files (CSS, for example) that they 
are not addressed directly, it usually takes about ten minutes.

Thank you in advance for your help.

Christophe


Re: Caching

2011-09-19 Thread Christophe Rahier
Hi,

I thought the problem was in my browser but when I empty the cache, I've
the same problem.

To be sure, I tried with an other browser and the problem is the same.

When I call my page locally from the server, the result is OK.

Christophe


Le 19/09/11 13:45, « Baptiste » bed...@gmail.com a écrit :

hi Christophe,

HAProxy is *only* a reverse proxy.
No caching functions in it.

Have you tried to browse your backend servers directly?
Can it be related to your browser's cache?

cheers

On Mon, Sep 19, 2011 at 1:39 PM, Christophe Rahier
christo...@qualifio.com wrote:
 Hi,
 Is there a caching system at HAProxy?

 In fact, we find that when we put online new files (CSS, for example)
that
 they are not addressed directly, it usually takes about ten minutes.

 Thank you in advance for your help.

 Christophe







Re: Caching

2011-09-19 Thread Baptiste
In any case HAProxy can be pointed about this problem.

Do you have a proxy on your LAN?
or Apache mod_cache enabled?

cheers



On Mon, Sep 19, 2011 at 2:30 PM, Christophe Rahier
christo...@qualifio.com wrote:
 Hi,

 I thought the problem was in my browser but when I empty the cache, I've
 the same problem.

 To be sure, I tried with an other browser and the problem is the same.

 When I call my page locally from the server, the result is OK.

 Christophe


 Le 19/09/11 13:45, « Baptiste » bed...@gmail.com a écrit :

hi Christophe,

HAProxy is *only* a reverse proxy.
No caching functions in it.

Have you tried to browse your backend servers directly?
Can it be related to your browser's cache?

cheers

On Mon, Sep 19, 2011 at 1:39 PM, Christophe Rahier
christo...@qualifio.com wrote:
 Hi,
 Is there a caching system at HAProxy?

 In fact, we find that when we put online new files (CSS, for example)
that
 they are not addressed directly, it usually takes about ten minutes.

 Thank you in advance for your help.

 Christophe








Re: httpclose/forceclose and TCP states

2011-09-19 Thread Chris Burroughs
On 09/08/2011 02:20 AM, Willy Tarreau wrote:
 On Tue, Sep 06, 2011 at 07:01:44PM -0400, Chris Burroughs wrote:
  On 09/01/2011 09:04 PM, Chris Burroughs wrote:
   I've looked at the source code and I think that's what's going on, but
   it has been a while since I've read C networking code.
  
  If someone is in a particularly explanatory mood, I'm also trying to
  figure out how haproxy handles the SO_LINGER blocking/throws-away-data
  trap.  Apache httpd for example does this:
  https://github.com/apache/httpd/blob/trunk/server/connection.c#L43
 Those are complex issues and we had to perform some changes in the past.
 To make it short, by default the system handles orphans, which are
 connections that have been closed but still have unacked data. This is
 very common with protocols working in question/response/close mode, as
 the server closes after sending the response.
 
...
 Regards,
 Willy
 


Thanks Willy, I found both of your responses helpful in figuring out
what exactly is going on.



Re: Caching

2011-09-19 Thread Hank A. Paulson
You can get weird results like this sometimes if you don't use http-close or 
any other http closing option on http backends. You should paste your config.


Maybe there should be a warning, if there is not already, for that situation - 
maybe just when running -c.


On 9/19/11 5:46 AM, Christophe Rahier wrote:

I don't use Apache but IIS.

I tried to disable caching on IIS but the problem is still there.

There's no proxy, all requests are sent from pfSense.

Christophe




Le 19/09/11 13:45, « Baptiste »bed...@gmail.com  a écrit :


hi Christophe,

HAProxy is *only* a reverse proxy.
No caching functions in it.

Have you tried to browse your backend servers directly?
Can it be related to your browser's cache?

cheers

On Mon, Sep 19, 2011 at 1:39 PM, Christophe Rahier
christo...@qualifio.com  wrote:

Hi,
Is there a caching system at HAProxy?

In fact, we find that when we put online new files (CSS, for example)
that
they are not addressed directly, it usually takes about ten minutes.

Thank you in advance for your help.

Christophe







haproxy at amazon

2011-09-19 Thread Dean Hiller
We are running haproxy at amazon and running some load tests and seem to be
hitting some bottleneck between haproxy and webservers or haproxy itself.

How can you tell when haproxy is maxed out?  Will cpu hit 100% or is it some
other characteristic?  our cpu is 4% and I only have 10 webservers and 10
clients, and my 10 clients generate about 1000 requests/second each on a
socket and each one is stateless independent of the other, no session is
saved at all.

I have a support ticket open with amazon but wanted to make sure I had more
information on haproxy when going into the meeting I have with amazon
engineering.

thanks,
Dean


Re: Apache translates 500 to 502 from haproxy

2011-09-19 Thread Willy Tarreau
Hi Sachin,

On Mon, Sep 19, 2011 at 01:47:28PM +0530, Sachin Shetty wrote:
 Hey Willy,
 
 So we are now hit by the side effect of this fix i.e. disabling httpclose. 
 
 Two problems:
 
 1. Entries in the log are missing, I guess you already warned me about it.
 Do you think if we disable keep alive in our Apache fronting haproxy, this
 will problem will go away?

Yes it will solve this issue at least. BTW, with what I saw in your trace,
I really see no reason why http-server-close would not work, because the
server advertises a correct content-length so haproxy should wait for both
streams to synchronize. Are you sure you had http-server-close in both the
frontend and the backend, and that you didn't have any remains of forceclose
nor httpclose ? Just in doubt, if you're willing to make a new test, I'm
interested in a new trace :-)

 2. Related to one, but an interesting one. 
   - A request comes to haproxy, as configured after waiting in haproxy
 queue for 10 seconds due to backend free connection unavailable, it sends a
 503 back, logged correctly in haproxy and apache
   - The client retries, I think with Keep Alive over the same connection
 and it sees a 400 status back. Now this request is no where in haproxy logs
 so there is no way to see what happened in haproxy and who really dropped
 the ball. The connection never made it to the backed cherrypy server since
 it logs each request it receives.

When you see the 400, is it the standard haproxy response or is it apache ?
If it is haproxy, you should see it in its logs, which doesn't seem to be
the case. It is possible that the client (or apache ?) continues to send a
bit of the remaining POST data before the request and that this confuses
the next hop (apache or haproxy). That's just a guess, of course.

Cheers,
Willy