http://www.daemonnews.org/200108/benchmark.html
The Effects of Tuning a Freebsd Box for High Performance
Gilbert gong,
Introduction
A stock FreeBSD installation delivers a system which is designed to meet the needs of most users, and strives to provide the best balance of safety, reliability, and performance in a multi-user environment. It is therefore not optimized for use as a high performance Dedicated Network Server. In this Article, I Will Investigate The Effect of Tuning a freebsd for use as a deted network server.
System and methodology
The test server was a Pentium III 600 MHz with 512MB of RAM, installed in a Super Micro P6SBU motherboard. The on-board Adaptec Ultra2 SCSI adapter was connected to an IBM DNES-309170W SA30 (8GB SCSI HDD), and the network card was A 3com 3C905B-TX. All FileSystems Were Standard UFS
A Celeron 400 with 128MB of Ram Was Used As a Network Client When Needed. The Test Server Was Installed with FreeBSD 4.3-Release. The Client Was Installed with Several Versions of FreeBSD 1.
The Two Machines WERE Connected with a Cisco Catalyst 2924-XL Running At 100 Mbit / Full Duplex.
I ran three different benchmarks against the test server, in both tuned and untuned state. The benchmark results are not meant as a real world performance measurement of the system, but only a means of comparing the relative performance of the tuned and untuned state. The Benchmarks Were Http_load to Measure Http Performance, Postmark To Measure File System Performance, and Postal To Measure SMTP Performance.
TUNING
.
Recompile the kenel
Perhaps the first step in tuning a FreeBSD box is to recompile the Kernel. Remove the options not needed by your system, and increase maxusers and the NMBCLUSTERS option. A copy of the kernel config file I used is hereTurn on soft updates
.. One of the most critical steps in tuning a FreeBSD box is turning on soft updates (and here) Soft updates is a method of improving filesystem metadata update performance The following commands were entered in single user mode:
Tunefs -n enable /
Tunefs -n enable / usr
Tunefs -n enable / var
Tunefs -n enable / TMP
Sysctl
A FEW SYSCTL VARIABLES SHOULD BE TUNED For Maximum Performance. The Following Lines Were Added To /etc/sysctl.conf:
vfs.vmiodirenable = 1
Kern.ipc.somaxConn = 4096
Kern.maxfiles = 65536
MISC
A few other Tweaks include setting the "noatime" parameter on nuSt of the filesis, and paying attention to partition layout.
HTTP_LOAD RESULTS
For the http_load test, I installed apache 1.3.19 from the ports collection, making a change to set HARD_SERVER_LIMIT to 2048. The untuned configuration would not allow 2048 processes to run, so I set Apache to create 128 initial, and max 1024 processes. For the Tuned Configuration, I Set Apache to Have 2048 Processes Running At All Times.
I ran http_load against the server with different numbers of concurrent requests, varying from 10 to 1000. I configured the server to respond to 10 different IP addresses, and strobed over those 10 different IP addresses. This is the page which http_load ran against. The Results is graphed here.
The tuned configuration outperformed the untuned configuration by over an order of magnitude. The untuned configuration maxed out at around 17 fetches / sec, as a result of running out of network mbufs. The tuned configuration kept increasing in performance as the load was increased, from 333 fetches / sec to 509 fetches / sec (1800% to 2900% increase over untuned). The Tuned Configuration Also Had a Lower Percentage of Errors, as shown here.postmark Results
The postmark benchmark was run with a variety of settings. First, it was run with some of the configurations documented on the home page. Those results are reported here, including a run on the FreeBSD MFS (Memory File System) for comparison. The system was then put through a series of postmark runs with different file sizes, with initial 1000 files and 20000 files. The improvement in performance is quite drastic in all cases, and ranges from a 40% to 860% increase in performance by this benchmark.
Postal Results
For the postal benchmark, the postfix mailer was installed from the Ports collection (postfix-20010228-pl01). The postal benchmark was then run for half hour periods with a range of parallel simultaneous connection settings. Around 15000 accounts were created on the test server , and postal was given the list of accounts to send mail to. The test runs were made back to back, with only a small break between them. This means that mail which was enqueued in an earlier run may have remained enqueued for a later run , slowing things down even more. Since this is only meant as a comparative test, the results are still good indications of the performance difference between the two configurations. The results of the postal benchmark are here. The improvement ranges from a 40% increase to A 650% increase.conclusion
In conclusion, we can see that a default FreeBSD installation, while optimized for safety and integrity, is not optimized for maximum performance as a dedicated network server. Particularly in cases of serving many simultaneous connections, reliably supporting large numbers of processes, and filesystem performance ONE Needs to take Steps to Imrove The Performance of The System Over The Default Configuration. The Great CAN Be Realized from this Are Great, OFTEN At Least Doublening The Performance of The System.
-------------------------------------------------- ------------------------------
FootNotes
1 A security enhancement in 4.3 Release unintentionally slows the rate at which two servers may communicate with one another. It also does not allow a way to turn that behavior off, though a patch has been released which does allow that behavior to be changed.
