Re: could a single ha proxy server sustain 1500 requests per second
On Thu, Feb 07, 2013 at 11:34:43AM -0500, S Ahmed wrote: > Thanks Willy. > > On the same note you said not to run anything on the same machine, to lower > costs I want to run other things on the haproxy front-end load balancer. > > What are the critical things to watch for on the server so I can be > notified at what point having 2 things on the server are becoming a problem? First, you need to ensure that the machine never ever swaps. This is absolutely critical. The second important point to consider is that you don't want another process to use a lot of CPU on the same machine, or you want to dedicate some CPUs to other processes. And last point is that you don't want other processes to harm the network stack (eg: eat all the source ports by doing nasty things such as connecting and closing as a client, rendering the source port unusable for doing real work for 2 minutes). There are people who live very well with their LB doing several things, but the ones who do it without taking much care can really regret it. After all, the LB is the point where *all* your traffic passes, you certainly don't want it to slow down because a stupid process was started on it by accident. And some web sites can lose so much per minute of failure that they don't want to risk mixing workloads to save a $500 machine ! Regards, Willy
Re: could a single ha proxy server sustain 1500 requests per second
Thanks Willy. On the same note you said not to run anything on the same machine, to lower costs I want to run other things on the haproxy front-end load balancer. What are the critical things to watch for on the server so I can be notified at what point having 2 things on the server are becoming a problem? On Wed, Dec 5, 2012 at 2:00 AM, Willy Tarreau wrote: > On Tue, Dec 04, 2012 at 02:19:30PM -0500, S Ahmed wrote: > > Hi, > > > > So 500 Mbits is 1/2 usage of a 1 Gbps port (haproxy and the back-end > > servers will have 1 Gbps connections). > > No, the traffic goes in opposite directions and the link is full duplex, > so you can effectively have 1 Gbps in and 1 Gbps out at the same time. > > > How does latency change things? e.g. what if it takes 90% clients 1 > second > > to send the 20K file, while some may take 1-3 seconds. > > it's easy, you said you were counting on 1500 req/s : > >- 90% of 1500 req/s = 1350 req/s >- 10% of 1500 req/s = 150 req/s > > 1350 req/s are present for one second => 1350 concurrent requests. > 150 req/s are present for 3 seconds => 450 concurrent requests. > => you have a total of 1800 concurrent requests (with one connection >each, it's 1800 concurrent connections). > > What we can say with such numbers : > - 1500 connections/s is light, even if conntrack is loaded and correctly > tuned, you won't notice (we're doing twice this on a 500 Mbps Geode > running on 1 watt). > > - 1800 concurrent connections is light too, multiply that by 16 kB, it's > 30MB of RAM for the kernel-side sockets, and twice that at most for > haproxy, so less than 100 MB of RAM. > > - 250 Mbps in both directions should not be an issue either, even my > pc-card realtek NIC does it on my 8-years old pentium-M. > > At only 1800 concurrent connections, the latency will probably be mostly > related to the NIC's interrupt rate. But we're speaking about hundreds of > microseconds here. > > If you're concerned about latency, use a correct NIC, don't run any other > software on the machine, and obviously don't run this in a VM ! > > Hoping this helps, > Willy > >
Re: could a single ha proxy server sustain 1500 requests per second
On Tue, Dec 04, 2012 at 02:19:30PM -0500, S Ahmed wrote: > Hi, > > So 500 Mbits is 1/2 usage of a 1 Gbps port (haproxy and the back-end > servers will have 1 Gbps connections). No, the traffic goes in opposite directions and the link is full duplex, so you can effectively have 1 Gbps in and 1 Gbps out at the same time. > How does latency change things? e.g. what if it takes 90% clients 1 second > to send the 20K file, while some may take 1-3 seconds. it's easy, you said you were counting on 1500 req/s : - 90% of 1500 req/s = 1350 req/s - 10% of 1500 req/s = 150 req/s 1350 req/s are present for one second => 1350 concurrent requests. 150 req/s are present for 3 seconds => 450 concurrent requests. => you have a total of 1800 concurrent requests (with one connection each, it's 1800 concurrent connections). What we can say with such numbers : - 1500 connections/s is light, even if conntrack is loaded and correctly tuned, you won't notice (we're doing twice this on a 500 Mbps Geode running on 1 watt). - 1800 concurrent connections is light too, multiply that by 16 kB, it's 30MB of RAM for the kernel-side sockets, and twice that at most for haproxy, so less than 100 MB of RAM. - 250 Mbps in both directions should not be an issue either, even my pc-card realtek NIC does it on my 8-years old pentium-M. At only 1800 concurrent connections, the latency will probably be mostly related to the NIC's interrupt rate. But we're speaking about hundreds of microseconds here. If you're concerned about latency, use a correct NIC, don't run any other software on the machine, and obviously don't run this in a VM ! Hoping this helps, Willy
Re: could a single ha proxy server sustain 1500 requests per second
Using multiplication: 1500 req/s * 20KBytes * 8 (bits in a Bytes) = 2,4 * 10^8, which is around 250 Mbits for one way. This traffic is the traffic from the clients to HAProxy, so you'll have it twice, since you'll have the same from HAProxy to the servers. So in total, around 500 Mbits. cheers On Fri, May 4, 2012 at 5:39 PM, S Ahmed wrote: > how can I calculate if this will work in theory? > > > On Thu, May 3, 2012 at 5:30 PM, Baptiste wrote: >> >> Hi, >> >> You'll need one gig interface (two looks better, one for the frontend >> and one for the backend servers), but it should work without any >> issues. >> >> cheers >> >> On Thu, May 3, 2012 at 9:35 PM, S Ahmed wrote: >> > I have a service where people will be http posting documents that will >> > be 20 >> > KB in size. >> > The rate at which these documents will be http posted is 1500 requests >> > per >> > second. >> > >> > There will be backend web servers that will be parsing and load the data >> > into a database (ignore this part but just giving the whole picture). >> > >> > What I want to know is, could a single HA proxy server handle this high >> > rate >> > of requests, seeing as the payload is fairly large (it isn't like a >> > simple >> > http get request). > >
Re: could a single ha proxy server sustain 1500 requests per second
how can I calculate if this will work in theory? On Thu, May 3, 2012 at 5:30 PM, Baptiste wrote: > Hi, > > You'll need one gig interface (two looks better, one for the frontend > and one for the backend servers), but it should work without any > issues. > > cheers > > On Thu, May 3, 2012 at 9:35 PM, S Ahmed wrote: > > I have a service where people will be http posting documents that will > be 20 > > KB in size. > > The rate at which these documents will be http posted is 1500 requests > per > > second. > > > > There will be backend web servers that will be parsing and load the data > > into a database (ignore this part but just giving the whole picture). > > > > What I want to know is, could a single HA proxy server handle this high > rate > > of requests, seeing as the payload is fairly large (it isn't like a > simple > > http get request). >
Re: could a single ha proxy server sustain 1500 requests per second
Hi, You'll need one gig interface (two looks better, one for the frontend and one for the backend servers), but it should work without any issues. cheers On Thu, May 3, 2012 at 9:35 PM, S Ahmed wrote: > I have a service where people will be http posting documents that will be 20 > KB in size. > The rate at which these documents will be http posted is 1500 requests per > second. > > There will be backend web servers that will be parsing and load the data > into a database (ignore this part but just giving the whole picture). > > What I want to know is, could a single HA proxy server handle this high rate > of requests, seeing as the payload is fairly large (it isn't like a simple > http get request).
