Fedora provides a graphical interface to the sysctl command in system-config- proc. It's still a beta-quality application, and it must be launched from the command line. The interface itself is unremarkable, and it does not provide a means to manipulate all the possible values, but it does offer useful help for the kernel variables it addresses.
If you find that a particular setting is useful, you can enter it into the /etc/sysctl.conf file. The format is as follows, using the earlier example:
net.ipv4.tcp_retries 2=20
Of more interest to kernel hackers than regular users, sysctl is a potentially powerful tool that continues to be developed and documented.
The kernel does a good job of balancing performance for graphical systems, so there's not a great deal you can do to tweak your desktop to run faster.
Both GNOME and KDE are 'heavyweight' desktop systems: They are all-inclusive, all-singing, and all- dancing environments that do far more than browse your file system. The drawback to this is that their size makes them run slowly on older systems. On the flip side, Fedora also comes with the Xfce desktop, which is a great deal slimmer and faster than the other two. If you find GNOME and KDE are struggling just to open a file browser, Xfce is for you.
Alternatively, if you simply cannot live without GNOME or KDE, take a look in the /usr/share/autostart directory, where you will see a list of files that are started when your graphical system boots. If you do not need any of them, just move them out of there and into somewhere safe in case you ever need them again.
Apache
Despite being the most popular web server on the Internet, Apache is by no means the fastest. Part of the problem is that Apache has been written to follow every applicable standard to the letter, so much of its development work has been geared toward standards-compliancy rather than just serving web pages quickly. That said, with a little tweaking you can convert a $1,000 Dell server into something capable of surviving the Slashdot Effect.
Slashdot.org is a popular geek news website that spawned the
The first target of your tuning should be the httpd.conf file in /etc/httpd/conf, as well as the other files in /etc/httpd/conf.d. The more modules you have loaded, the more load Apache is placing on your server — take a look through the LoadModule list and comment out (start the line with a #) the ones you do not want. Some of these modules can be uninstalled entirely through the Add or Remove Packages dialog.
As a rough guide, you are almost certain to need mod_mime and mod_dir, and probably also mod_log_config. The default Apache configuration in Fedora is quite generic, so unless you are willing to sacrifice some functionality you might also need mod_negotiation (a speed killer if there ever was one), and mod_access (a notorious problem). It's possible to configure both of those last two modules so that they work with little or no performance decrease, but all too often they get abused and just slow things down.
Whatever you do, when you are disabling modules ensure you leave either mod_deflate or mod_gzip enabled, depending on your Apache version. Your bottleneck is almost certainly going to be your bandwidth rather than your processing power, and having one of these two compressing your content will usually turn 10Kb of HTML into 3Kb for supported browsers (most of them).
Next, ensure keepalives are turned off. Yes, you read that right: Turn keepalives off. This adds some latency to people viewing your site because they cannot download multiple files through the same connection. However, it in turn reduces the number of simultaneous open connections and so allows more people to connect.
If you are serving content that does not change, you can take the extreme step of enabling MMAP support. This allows Apache to serve pages directly from RAM without bothering to check whether they have changed, which works wonders for your performance. However, the downside is that when you do change your pages you need to restart Apache. Look for the EnableMMAP directive — it is probably commented out and set to off, so you need to remove the comment and set it to On.
Finally, you should do all you can to ensure that your content is static: Avoid PHP if you can, avoid databases if you can, and so on. If you know you are going to get hit by a rush of visitors, use plain HTML so the speed with which Apache can serve pages is limited only by your bandwidth.
Some people, when questioned about optimizing Apache, recommend you tweak the HARD_SERVER_LIMIT in the Apache source code and recompile. Although we agree that compiling your own Apache source code is a great way to get a measurable speed boost if you know what you are doing, you should need to change this directive only if you are hosting a huge site.
The default value, 256, is enough to handle the Slashdot Effect — and if you can handle that, you can handle most things.
MySQL
Tuning your MySQL server for increased performance is exceptionally easy to do, largely because you can see huge speed increases simply by getting your queries right. That said, there are various things you can tune in the server itself to help it cope with higher loads as long as your system has enough RAM.
The key is understanding its buffers—there are buffers and caches for all sorts of things, and finding out how full they are is crucial to maximizing performance. MySQL performs best when it makes full use of its buffers, which in turn places a heavy demand on system RAM. Unless you have 4GB of RAM or more in your machine, you do not have enough capacity to set very high values for all your buffers — you need to pick and choose.
Measuring Key Buffer Usage
When you add indexes to your data, it enables MySQL to find data faster. However, ideally you want to have these indexes stored in RAM for maximum speed, and the variable key_buffer_size defines how much RAM MySQL can allocate for index key caching. If MySQL cannot store its indexes in RAM, you experience
