Hi Willy,
Sorry for reply so late, I test my configuration according your
suggestion. It is correct that We need stunnel in front of haproxy to
decipher HTTPS. I misunderstand the configuration on https and it works. We
have lots of long connection on our application server which use GWT to do
the chat service with comet support, So I need to change the srvtimeout to
about 32s.
We are a WAP website that use access our website by mobile phone browser,
there are about one-third users browser can not support Cookie according
to our access log. When they first access the Haproxy ,the session status
is --NI and when they come back again, the status change to --VN.
(
The third character means:
N : the client provided NO cookie. This is usually the case for new
visitors, so counting the number of occurrences of this flag in the
logs generally indicate a valid trend for the site frequentation.
V : the client provided a VALID cookie, and was sent to the associated
server.
The last character means:
N : NO cookie was provided by the server, and none was inserted either.
I : no cookie was provided by the server, and the proxy INSERTED one.
Note that in "cookie insert" mode, if the server provides a cookie,
it will still be overwritten and reported as "I" here.
)
The VN means that the browser don't support cookie but Haproxy already get
the mapping of jsessionid and server, so it still be transfer the request to
correct backend server.
Best Regards,
Hogan
On Mon, Nov 15, 2010 at 1:37 PM, Willy Tarreau <[email protected]> wrote:
> On Mon, Nov 15, 2010 at 09:57:08AM +0800, Hogan Yu wrote:
> > HI Willy,
> > Great thanks for you explanation.
> > About the second part you introduced,
> > In part, because right now all browsers support cookies and have done
> > so for the last 10 years at least. Even WAP gateways and terminals do
> > support cookies. What you may find are browsers where cookie support
> > has been explicitly disabled. But even then, when users disable cookies,
> > they normally disable persistent cookies, those that are stored into a
> > file. Session cookies, such as the cookies haproxy inserts, just live
> > while the browser window is open and are not stored in any file. Those
> > ones are almost never blocked.
> > When we disable the cookie in browsers such as Firefox, IE, It will
> don't
> > send cookie to the server in the request, We really need the appsession
> to
> > do the sticky session persistence.
>
> I agree that if you completely disable cookies, only appsession will work.
> My point was that most of the time, only stored cookies are disabled or
> blocked, but session cookies are almost never because no website works
> anymore without them.
>
> > According you guys suggestion, I adjust my configuration file as follows:
> >
> > ==============================================================
> > global
> > maxconn 32000 # Total Max Connections. This is dependent on
> > ulimit
> > daemon
> > nbproc 1 # Number of processing cores. Dual Dual-core
> Opteron
> > is 4 cores for example.
>
> I suggest that you completely remove the nbproc line and its comment, it
> will
> avoid any risk of changing it in the future.
>
> > pidfile /tmp/haproxy.pid
>
> /var/run is commonly used to store pid files.
>
> > #stats maxconn 5
>
> you may also add the stats socket in order to debug if anything goes wrong
> :
>
> stats socket /var/run/haproxy.sock mode 600 level admin
> stats timeout 1m
>
> > defaults
> > mode http
> > clitimeout 10000
> > srvtimeout 10000
> > contimeout 10000
>
> in general you can lower the client timeout (5s are more than enough on a
> local network), and if your application is sometimes slow, you may want to
> increase the server timeout.
>
> > #option httpclose # Disable Keepalive
>
> probably that you should remove this line and put http-server-close here
> so that every other section has it by default ?
>
> > log global
> > log 127.0.0.1 local3
> > option httplog
>
> I notice there is no maxconn in your defaults section, and there is none
> either in the listen section. The one from the global section is for the
> whole process. You should set a slightly lower one for each section, and
> the best way to do this would be to add this here :
>
> maxconn 30000
>
> > listen http_proxy 10.211.162.15:80
> > balance roundrobin # Load Balancing algorithm
> > option httpchk HEAD /wap2/login.jsp HTTP/1.0
> > option forwardfor # This sets X-Forwarded-For
> > stats enable
> > stats realm testing \ Haproxy
> > stats uri /admin
> > stats auth hogan:hogan
> > stats refresh 30s
> > stats hide-version
> > #option httpclose
> > option http-server-close
> >
> > capture cookie JSESSIONID len 52
> > #stick-table type string len 52 size 2g expire 1h
> > cookie HTTPSERVERID insert nocache indirect
> > #appsession JSESSIONID len 52 timeout 3h mode query-string
> > appsession JSESSIONID len 34 timeout 1h
> > acl image_ico path_sub .ico
> > acl image_gif path_sub .gif
> > acl image_png path_sub .png
> > acl image_jpg path_sub .jpg
> > ignore-persist if image_ico || image_gif || image_png ||
> image_jpg
>
> You can simplify that in a single ACL if you prefer :
>
> acl image path_sub .ico .gif .png .jpg
> ignore-persist if image
>
> > ## Define your servers to balance
> > server server1 10.211.162.15:8280 weight 1 maxconn 15000 check
> inter
> > 2000 rise 2 fall 3 cookie A
> > server server2 10.198.9.139:8280 weight 1 maxconn 15000 check
> inter
> > 2000 rise 2 fall 3 cookie B
>
> I really doubt that your servers will accept 15000 concurrent connections !
> In my opinion, numbers between 30 and 200 are much more suited for
> Java-based
> applications ! You should check that on your server and set it up
> accordingly.
>
> > listen https_proxy 10.211.162.15:443
>
> Hmmm do you have something in front of haproxy to decipher HTTPS ? Haproxy
> will not do that itself, so if your clients directly connect to that port,
> this will not work. Generally we use stunnel for that because it does not
> fiddle with HTTP. But nginx and pound are often used too.
>
> > balance roundrobin # Load Balancing algorithm
> > option httpchk HEAD /wap2/login.jsp HTTP/1.0
> > option forwardfor # This sets X-Forwarded-For
> > stats enable
> > stats realm icebreakersoftware\ Haproxy
> > stats uri /admin
> > stats auth hogan:hogan
> > stats refresh 30s
> > stats hide-version
> > cookie HTTPSSERVERID insert nocache indirect
> > appsession JSESSIONID len 52 timeout 30m mode path-parameters
> > acl image_ico path_sub .ico
> > acl image_gif path_sub .gif
> > acl image_png path_sub .png
> > acl image_jpg path_sub .jpg
> > ignore-persist if image_ico || image_gif || image_png ||
> image_jpg
> > ## Define your servers to balance
> > server server1 10.211.162.15:8280 weight 1 maxconn 15000 check
> inter
> > 2000 rise 2 fall 3 cookie A
> > server server1 10.198.9.139:8280 weight 1 maxconn 15000 check
> inter
> > 2000 rise 2 fall 3 cookie A
>
> Same comments as for the other section.
>
> > ==============================================================
> >
> > I add the ACL for ignore-persistent for images and a new 443 port to
> > listen.
> > It is the load balance for some java application servers.
> >
> >
> > do you have any suggestion for my configuration?
>
> I suggest that once it's in production, you check the logs for any line
> which has a cookie in the URL but not in the request (flags "NI"). I'd
> be very surprized if you'd find some.
>
> We did the same at a customer's who was running WAP services. If my memory
> serves me right, there was about one single client who did not send the
> cookie because he had manually reconfigured his terminal, which was quite
> old. It's interesting to see how things evolve in this area.
>
> Regards,
> Willy
>
>
