http://kb.linuxvirtualserver.org/api.php?action=feedcontributions&user=Dogonthesun&feedformat=atomLVSKB - User contributions [en]2024-03-29T02:29:07ZUser contributionsMediaWiki 1.26.2http://kb.linuxvirtualserver.org/wiki?title=Performance_and_Tuning&diff=6189Performance and Tuning2012-01-26T11:37:51Z<p>Dogonthesun: /* Connection Hash Table Size */</p>
<hr />
<div>== Performance Measurement ==<br />
<br />
=== Tools ===<br />
<br />
* testlvs: simple throughput testing tool for LVS from Julian, see [http://www.ssi.bg/~ja/#testlvs the testlvs page]<br />
* ab: apache benchmark<br />
* httperf: a tool for measuring web server performance from HP, see [http://www.hpl.hp.com/research/linux/httperf/ the httperf homepage]<br />
* Tsung: an open-source multi-protocol distributed load testing tool, see [http://tsung.erlang-projects.org/ Tsung project homepage]<br />
* specweb: web server benchmark by spec.org, it is now [http://www.spec.org/web2005/ specweb2005]. <br />
* webbench: a licensed benchmark program that measures the performance of Web servers, developed by VeriTest.<br />
<br />
== Performance Tuning ==<br />
<br />
=== Connection Hash Table Size ===<br />
<br />
The IPVS connection hash table uses the chaining scheme to handle<br />
hash collisions. Using a big IPVS connection hash table will greatly<br />
reduce conflicts when there are hundreds of thousands of connections<br />
in the hash table.<br />
<br />
Note the table size must be power of 2. The table size will be the<br />
value of 2 to the your input number power. The number to choose is<br />
from 8 to 20, the default number is 12, which means the table size<br />
is 4096. Don't input the number too small, otherwise you will lose<br />
performance on it. You can adapt the table size yourself, according<br />
to your virtual server application. It is good to set the table size<br />
not far less than the number of connections per second multiplying<br />
average lasting time of connection in the table. For example, your<br />
virtual server gets 200 connections per second, the connection lasts<br />
for 200 seconds in average in the connection table, the table size<br />
should be not far less than 200x200, it is good to set the table<br />
size 32768 (2**15).<br />
<br />
We can configure the size of IPVS connection hash table before compiling the Linux kernel. Here are the IPVS configurations in the 'make menuconfig' menu:<br />
<br />
<pre><br />
Networking Options --><br />
Network packet filtering framework (Netfilter) ---><br />
IP: Virtual Server Configuration --><br />
[*] IPv6 support for IPVS <br />
[ ] IP virtual server debugging <br />
(20) IPVS connection table size (the Nth power of 2) <br />
*** IPVS transport protocol load balancing support *** <br />
[*] TCP load balancing support <br />
[*] UDP load balancing support <br />
[*] ESP load balancing support <br />
[*] AH load balancing support <br />
*** IPVS scheduler *** <br />
<M> round-robin scheduling <br />
<M> weighted round-robin scheduling <br />
<M> least-connection scheduling <br />
<M> weighted least-connection scheduling <br />
<M> locality-based least-connection scheduling <br />
<M> locality-based least-connection with replication scheduling <br />
<M> destination hashing scheduling <br />
<M> source hashing scheduling <br />
<M> shortest expected delay scheduling <br />
<M> never queue scheduling <br />
*** IPVS application helper *** <br />
<M> FTP protocol helper <br />
</pre><br />
<br />
=== Netfilter Connection Track ===<br />
<br />
[[IPVS]] uses its own simple and fast connection tracking for performance reasons, instead of using netfilter connection tracking. So, if you don't use firewalling feature at [[load balancer]] and you need an extremely fast load balancer, do not load netfilter conntrack modules into you system, because there is no need to do double tracking. Note that [[LVS/NAT]] should work too without the conntrack modules.<br />
<br />
Julian compared the performance of IPVS with ip_conntrack and without ip_conntrack. See http://archive.linuxvirtualserver.org/html/lvs-users/2001-12/msg00141.html<br />
<br />
== Some Performance Data ==<br />
<br />
While the [[LVS/DR]] cluster was pushing out 9.6Gbps traffic, the LVS [[load balancer]] was<br />
doing a negilgable ammount of work, which seems to indicate that LVS<br />
could push a great deal more traffic given sufficient real-servers and<br />
end-users.<br />
<br />
* http://archive.linuxvirtualserver.org/html/lvs-users/2005-11/msg00266.html<br />
<br />
== External Links ==<br />
<br />
* [http://www.kegel.com/c10k.html The C10K problem] written by Dan Kegel, good notes on how to configure operating systems and write code to support 10K clients on a single server<br />
<br />
[[Category:LVS Handbook]]</div>Dogonthesunhttp://kb.linuxvirtualserver.org/wiki?title=Performance_and_Tuning&diff=6188Performance and Tuning2012-01-26T11:36:45Z<p>Dogonthesun: /* Connection Hash Table Size */</p>
<hr />
<div>== Performance Measurement ==<br />
<br />
=== Tools ===<br />
<br />
* testlvs: simple throughput testing tool for LVS from Julian, see [http://www.ssi.bg/~ja/#testlvs the testlvs page]<br />
* ab: apache benchmark<br />
* httperf: a tool for measuring web server performance from HP, see [http://www.hpl.hp.com/research/linux/httperf/ the httperf homepage]<br />
* Tsung: an open-source multi-protocol distributed load testing tool, see [http://tsung.erlang-projects.org/ Tsung project homepage]<br />
* specweb: web server benchmark by spec.org, it is now [http://www.spec.org/web2005/ specweb2005]. <br />
* webbench: a licensed benchmark program that measures the performance of Web servers, developed by VeriTest.<br />
<br />
== Performance Tuning ==<br />
<br />
=== Connection Hash Table Size ===<br />
<br />
The IPVS connection hash table uses the chaining scheme to handle<br />
hash collisions. Using a big IPVS connection hash table will greatly<br />
reduce conflicts when there are hundreds of thousands of connections<br />
in the hash table.<br />
<br />
Note the table size must be power of 2. The table size will be the<br />
value of 2 to the your input number power. The number to choose is<br />
from 8 to 20, the default number is 12, which means the table size<br />
is 4096. Don't input the number too small, otherwise you will lose<br />
performance on it. You can adapt the table size yourself, according<br />
to your virtual server application. It is good to set the table size<br />
not far less than the number of connections per second multiplying<br />
average lasting time of connection in the table. For example, your<br />
virtual server gets 200 connections per second, the connection lasts<br />
for 200 seconds in average in the connection table, the table size<br />
should be not far less than 200x200, it is good to set the table<br />
size 32768 (2**15).<br />
<br />
We can configure the size of IPVS connection hash table before compiling the Linux kernel. Here are the IPVS configurations in the 'make menuconfig' menu:<br />
<br />
<pre><br />
Networking Options --><br />
Network packet filtering framework (Netfilter) ---><br />
IP: Virtual Server Configuration --><br />
<M> virtual server support (EXPERIMENTAL)<br />
[ ] IP virtual server debugging<br />
(12) IPVS connection table size (the Nth power of 2)<br />
--- IPVS scheduler<br />
<M> round-robin scheduling<br />
<M> weighted round-robin scheduling<br />
<M> least-connection scheduling scheduling<br />
<M> weighted least-connection scheduling<br />
<M> locality-based least-connection scheduling<br />
<M> locality-based least-connection with replication scheduling<br />
<M> destination hashing scheduling<br />
<M> source hashing scheduling<br />
<M> shortest expected delay scheduling<br />
<M> never queue scheduling<br />
--- IPVS application helper<br />
<M> FTP protocol helper<br />
</pre><br />
<br />
=== Netfilter Connection Track ===<br />
<br />
[[IPVS]] uses its own simple and fast connection tracking for performance reasons, instead of using netfilter connection tracking. So, if you don't use firewalling feature at [[load balancer]] and you need an extremely fast load balancer, do not load netfilter conntrack modules into you system, because there is no need to do double tracking. Note that [[LVS/NAT]] should work too without the conntrack modules.<br />
<br />
Julian compared the performance of IPVS with ip_conntrack and without ip_conntrack. See http://archive.linuxvirtualserver.org/html/lvs-users/2001-12/msg00141.html<br />
<br />
== Some Performance Data ==<br />
<br />
While the [[LVS/DR]] cluster was pushing out 9.6Gbps traffic, the LVS [[load balancer]] was<br />
doing a negilgable ammount of work, which seems to indicate that LVS<br />
could push a great deal more traffic given sufficient real-servers and<br />
end-users.<br />
<br />
* http://archive.linuxvirtualserver.org/html/lvs-users/2005-11/msg00266.html<br />
<br />
== External Links ==<br />
<br />
* [http://www.kegel.com/c10k.html The C10K problem] written by Dan Kegel, good notes on how to configure operating systems and write code to support 10K clients on a single server<br />
<br />
[[Category:LVS Handbook]]</div>Dogonthesun