Hello Benedikt,

On Tue, May 08, 2012 at 05:33:46PM +0200, Benedikt Fraunhofer wrote:
> Hello List,
> 
> I placed haproxy in front of our exchange cluster for OutlookAnywhere
> Clients (that's just RPCoverHTTP, port 443). SSL is terminated by
> pound and forwards traffic on loopback to haproxy.
> 
> Everything works but it's awfully slow when i use "mode http";
> requests look like this:
> 
> RPC_IN_DATA /rpc/rpcproxy.dll?[...] HTTP/1.1
> 
> HTTP/1.1 200 Success..Content-Type:application/rpc..Content-Length:1073741824
> 
> RPC_OUT_DATA /rpc/rpcproxy.dll?[..] HTTP/1.1
> 
> HTTP/1.1 200 Success..Content-Type:application/rpc..Content-Length:1073741824
> 
> (this is the nature of microsoft rpc I've been told, it's using two
> channels to make it "duplex")
> and are held open in both cases (mode tcp and mode http) due to long
> configured timeouts (and "no option httpclose" for the http-mode)
> 
> I can't see a big difference in how packets look, there's an awful lot
> of nearly empty packets
> with Syn and Push set, but that's in both cases. Packets reach 16k
> (that's the mtu of the loopback device)
> 
> The only difference you can see in the Outlook Connection Info Window
> is the response-time: with mode tcp it's around 16-200ms while in
> http-mode it's above 800ms.
> 
> Any hint? Or is mode-http of no use because I'll be unable to inject
> stuff into the session-cookie at all?

For such border-line uses, you need to enable "option http-no-delay". By
default, haproxy tries to merge as many TCP segments as possible. But in
your case, the application is abusing the HTTP protocol by expecting that
incomplete data will be immediately delivered to the other end (which is
wrong but it's not the first time microsoft does crappy things with HTTP,
see NTLM). Please note that such protocols will generally not work across
caches or anti-virus proxies.

With "option http-no-delay", haproxy refrains from merging consecutive
segments and forwards data as fast as they enter. This obviously leads
to higher CPU and network usage due to the increase of small packets,
but at least it will work as expected.

Regards,
Willy


Reply via email to