5000 CPS for haproxy
hello, we have deployed the Haproxy on amazon cloud. its working fine we would like to do testing 5000 CPS . Please suggest the way to test Thanks Appasaheb
Re: session stickyness with or without serverid
On Fri, 29 Jul 2011 09:11:38 +0200, Willy Tarreau wrote: Hi Julien, On Thu, Jul 28, 2011 at 07:16:32PM -0400, Julien Vehent wrote: Hey guys, We've been happy users of haproxy in front of our tomcat farm for some time now, except for one thing: when we want to put a backend in maintenance mode, via hatop, we have to deal with users coming back a few hours later with a SERVERID cookie and being routed to that backend. If it's in maintenance mode, it should not receive any traffic. I suspect you just changed its weight to zero, which means it's not elected for LB but will still serve persistent requests. Please double-check, because if you're certain that you're getting that, then you've spotted a bug. Hey Willy, You're right, I do set the weight at zero first, and then after a couple of hours, put the server in maintenance mode. What I'm trying to reduce is the time between setting a server's weight to zero, and seeing no connections on it. With maxlife 1h, I get a decent compromise. After one hour from setting the server to zero, I would probably only disconnect 0.001% of obsessive users, so it's fine. I initially configured haproxy to balance based on a SERVERID cookie, essentially because I didn't know if the JSESSIONID would provide the appropriate persistence, but now I'm thinking that it might be a good idea to remove the SERVERID cookie and do all the work on the JSESSIONID. The goal would be to reduce the time between putting a server in maintenance and not seeing any traffic on it at all (ie. all sessions are expired). So my question is: what are the pros and cons of using a SERVERID cookie vs a JSESSIONID ? Cookie insertion is more reliable and more determinist since there are no tables to learn and maintain. Also, with recent versions, we now have features such as force-persist and ignore-persist which make it a lot easier to perform maintenance on live service without the user noticing and with the ability for the admin to check what he's going to put online before doing so. All these are good reasons to use a SERVERID cookie instead of learning a JSESSIONID cookie. I fail to see how ignore-persist can help me in this case... As I understand it, ignore-persist will force haproxy to ignore the persistence cookie and load balance the request to any available backend. In my case, it would mean redirect the user with an active session to another backend, effectively disconnecting it. Am I correct ? Maybe I'm not seeing the use case properly here. Thanks, Julien
Re: session stickyness with or without serverid
On Mon, Aug 01, 2011 at 12:14:48PM -0400, Julien Vehent wrote: You're right, I do set the weight at zero first, and then after a couple of hours, put the server in maintenance mode. OK. What I'm trying to reduce is the time between setting a server's weight to zero, and seeing no connections on it. With maxlife 1h, I get a decent compromise. After one hour from setting the server to zero, I would probably only disconnect 0.001% of obsessive users, so it's fine. Yes that's the right method. However, if you want to ensure that nobody will connect to your server during the operations, you can force the server to enter the maintenance mode (using the stats socket or stats web interface). Cookie insertion is more reliable and more determinist since there are no tables to learn and maintain. Also, with recent versions, we now have features such as force-persist and ignore-persist which make it a lot easier to perform maintenance on live service without the user noticing and with the ability for the admin to check what he's going to put online before doing so. All these are good reasons to use a SERVERID cookie instead of learning a JSESSIONID cookie. I fail to see how ignore-persist can help me in this case... As I understand it, ignore-persist will force haproxy to ignore the persistence cookie and load balance the request to any available backend. In my case, it would mean redirect the user with an active session to another backend, effectively disconnecting it. Am I correct ? Exactly. Different people proceed in different ways. For instance, there are some who would use ignore-persist to match a cookie value (that of the server you're putting offline). But with the maintenance mode, this is no longer necessary. Regards, Willy
maintenance mode and server affinity
I have a number if instances using tcp mode, and a stick-table on src ip for affinity. When a server is in maintenance mode, clients with an existing affinity will still connect to the disabled server, and only be re-dispatched if the connection fails (and error responses from the backend are still successful tcp connections). I've done a few things to stop this traffic when needed: - drop the packets on the load balancer with a null route or iptables. - block the packets with the firewall on the backend server, and let the clients get re-dispatched. - shutdown the services that could response from the backend, and re-dispatch. Have I missed any configuration in haproxy that will completely stop traffic to a backend? I have no problem managing this as-is myself, but having fewer pieces involved makes delegating administration responsibilities easier. Willy, is a block server option (or maybe a drop table to get rid of affinity sessions), something that could be implemented? Thanks, -jim
Re: acl using path_beg
well, is it not redirecting. just die there with a 404 status any other hint? regards On Sun, Jul 31, 2011 at 7:01 PM, Baptiste bed...@gmail.com wrote: Hi, The wp-admin page of wordpress is a 302 redirecting to wp-login.php. Have you tried to browse the backend directly? I guess it should not work. There are some parameters on Wordpress to tell him on which URL it will be hosted. By default, it may be /, in your case you should turn this parameter to /blog :) cheers On Sun, Jul 31, 2011 at 11:46 PM, Gabriel Sosa sosagabr...@gmail.com wrote: Hello folks I'm trying to send all the traffic that starts with /blog to a specific backend and I'm using *path_beg* for that. here is a snip of my config file: defaults log global timeout client 6 timeout server 3m timeout connect 15000 retries 3 option redispatch frontend http mode http log global option httplog option forceclose option httpclose bind XXX.XXX.XXX.XXX:80 # com 80 acl blog_acl path_beg /blog use_backend blog_backend if blog_acl default_backend farm80 For some reason, if I browse http://www.example.com/blog everything works just fine, but if I browse http://www.example.com/blog/wp-admin/ (as you can guess I'm using wordpress) I get a 404 status. AFAIK, the acl path_beg /blog should match /blog/ or /blog/wp-admin basically anything after /blog/ should be sent to that backend. do you have any idea why that could be not working as expected? Best regards -- Gabriel Sosa Si buscas resultados distintos, no hagas siempre lo mismo. - Einstein -- Gabriel Sosa Si buscas resultados distintos, no hagas siempre lo mismo. - Einstein
Best way to find the version
Hi All, Just wondering what is the best way to find the haproxy version. This is rightscale AMI so I was not the one who installed it. Eithor yum list installed|grep haproxy or rpm -qa|grep haproxy helped. Anyhelp would be great. Also keep the awesome work guys! -Habeeb
Re: Best way to find the version
Hi, Just wondering what is the best way to find the haproxy version. haproxy -v - craig
Re: acl using path_beg
Got it working. the issue was a lot chained acls that were catching up the rule I was just adding. Thank you all for your help. On Mon, Aug 1, 2011 at 5:05 PM, Gabriel Sosa sosagabr...@gmail.com wrote: well, is it not redirecting. just die there with a 404 status any other hint? regards On Sun, Jul 31, 2011 at 7:01 PM, Baptiste bed...@gmail.com wrote: Hi, The wp-admin page of wordpress is a 302 redirecting to wp-login.php. Have you tried to browse the backend directly? I guess it should not work. There are some parameters on Wordpress to tell him on which URL it will be hosted. By default, it may be /, in your case you should turn this parameter to /blog :) cheers On Sun, Jul 31, 2011 at 11:46 PM, Gabriel Sosa sosagabr...@gmail.com wrote: Hello folks I'm trying to send all the traffic that starts with /blog to a specific backend and I'm using *path_beg* for that. here is a snip of my config file: defaults log global timeout client 6 timeout server 3m timeout connect 15000 retries 3 option redispatch frontend http mode http log global option httplog option forceclose option httpclose bind XXX.XXX.XXX.XXX:80 # com 80 acl blog_acl path_beg /blog use_backend blog_backend if blog_acl default_backend farm80 For some reason, if I browse http://www.example.com/blog everything works just fine, but if I browse http://www.example.com/blog/wp-admin/ (as you can guess I'm using wordpress) I get a 404 status. AFAIK, the acl path_beg /blog should match /blog/ or /blog/wp-admin basically anything after /blog/ should be sent to that backend. do you have any idea why that could be not working as expected? Best regards -- Gabriel Sosa Si buscas resultados distintos, no hagas siempre lo mismo. - Einstein -- Gabriel Sosa Si buscas resultados distintos, no hagas siempre lo mismo. - Einstein -- Gabriel Sosa Si buscas resultados distintos, no hagas siempre lo mismo. - Einstein
