Hi Sean, > So, it looks about the same. The single instance outperforms the > cluster, which doesn't make any sense. I'll try those changes and see if > it gets any better.
at first glance it looks like your problem (increased latency) could be related to connection setup costs: You're using "option httpclose", which closes the client and server connection after every request, requiring two new connections to be created for each and every request (client -> haproxy, haproxy -> server). I didn't see the implementation/configuration of your application server, but it will end up with at least half the amound of established connections. And if using keepalive, it will be even less. So to get this sorted out, make sure to know how keep-alive and connections are handled in both scenarios. This can be a big factor, especially when doing synthetic benchmarks. For the haproxy 1.4+ case, you might want to use "option http-server-close" if you want real round-robin on request basis. This will keep the client connection open, but close the server connection after every request, which can result in better latency if clients support keep-alive. Have a look at this paragraph from the haproxy 1.4 doc: > By default HAProxy operates in a tunnel-like mode with regards to persistent > connections: for each connection it processes the first request and forwards > everything else (including additional requests) to selected server. Once > established, the connection is persisted both on the client and server > sides. Use "option http-server-close" to preserve client persistent > connections > while handling every incoming request individually, dispatching them one after > another to servers, in HTTP close mode. Use "option httpclose" to switch both > sides to HTTP close mode. "option forceclose" and "option > http-pretend-keepalive" help working around servers misbehaving in HTTP close > mode. Best regards, John
