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
