Re: minimum requirements and explanation about stats

2009-12-19 Thread Willy Tarreau
Hi Gabriel,

On Fri, Dec 11, 2009 at 02:13:12AM -0200, Gabriel Sosa wrote:
 Hola!
 
 Currently our haproxy is setup over a Intel Pentium D 930 with 2gb 667
 RAM, we are in a test stage. Running a Centos 5.3 64bits kernel 2.6
 
 haproxy was compiled with TARGET=linux26
 
 - How can I know if this is a good hardware for this. I didn't found
 any about this in the documentation.

A pentium D 3 GHz should be able to sustain about 15-2 connections/s.
With 2 GB of RAM you can support between 1 and 4 concurrent
connections depending on build options and TCP tuning.

 - How can I calculate the maximum number of connection based on that
 hardware/OS/kernel

It's easy. Haproxy uses two buffers per connection. Each of them is 16 kB
per default (I'm used to build at 8kB). So you have 32 kB of RAM used by
haproxy per connection. Now the system also uses buffers for TCP sockets.
Two buffers per socket = 4 buffers per haproxy connection. The minimum
size is 4 kB, though the default is larger (check the middle parameter
in the tcp_rmem and tcp_wmem sysctls). So in theory, with default settings,
2 GB of RAM can support 2GB/(32kB+4*4kB) = 41000 concurrent connections.
Of course this is wrong since it does not take into account that the system
needs some RAM to work. In practice, the TCP stack's memory is limited to
what you can find in tcp_mem (in 4kB pages). If your machines will only
run haproxy, you can safely set those parameters to half of your system's
memory. That way you'll be limited to 1 GB for the TCP stack alone = 65536
connections, and 1 GB for haproxy alone = 32768 connections. If you rebuild
it with 8kB buffer size, you'll reach 65536 connections. Once again, you
should consider that not all of this memory will be dedicated to network
buffers, and that if you limit yourself to 40k conns, it will be OK.

 In the other hand, how is a session considered ? I mean: If I have a
 page with 4 images (for example) should I consider this like a 5
 different sessions or just one session with 5 elements?

Without keepalive, these will be 5 short sessions. With keepalive,
these will be 1-3 long sessions, depending on how the browser
decides to parallelize the fetches.

 there is any
 documentation about how should I read the stats?

Not much in fact. There are just minor explanations in the config manual
but that's all.

 I really enjoy this piece of software, there is any other way (like
 IRC) to have good talks ?

There's an IRC channel on freenode, though I don't know if it's regularly
active or not. You'll find the link in the Contacts section of the home
page.

Regards,
Willy




Re: minimum requirements and explanation about stats

2009-12-11 Thread XANi
Dnia 2009-12-11, pią o godzinie 02:13 -0200, Gabriel Sosa pisze:

 Hola!
 
 Currently our haproxy is setup over a Intel Pentium D 930 with 2gb 667
 RAM, we are in a test stage. Running a Centos 5.3 64bits kernel 2.6
 
 haproxy was compiled with TARGET=linux26
 
 - How can I know if this is a good hardware for this. I didn't found
 any about this in the documentation.
 - How can I calculate the maximum number of connection based on that
 hardware/OS/kernel
 
 In the other hand, how is a session considered ? I mean: If I have a
 page with 4 images (for example) should I consider this like a 5
 different sessions or just one session with 5 elements? there is any
 documentation about how should I read the stats?
 
 I really enjoy this piece of software, there is any other way (like
 IRC) to have good talks ?
 
 thank you!
 
 
 
 


Tbh best way to check it is just u fire some light http servers and run
benchmarks
U might want to tune ur system a bit, like turn off connection tracking
(as it can eat lots of RAM/CPU), get new kernel (so tcp splicing will
work) and get good network cards. From my experience haproxy perfomance
is as fast as kernel can put it on the wire ;]


-- 
Mariusz Gronczewski (XANi) xani...@gmail.com
GnuPG: 0xEA8ACE64
http://devrandom.pl


signature.asc
Description: To jest część  wiadomości podpisana cyfrowo