Originally Posted by parityboy
So, in a scenario where a machine is under heavy load (web serving, databases etc) are you saying a vanilla kernel will perform out of the box nearly as well as a tuned/patched kernel?
It depends on the type of load really. What you've described could generate a whole plethora of different bottlenecks depending on the specific hardware set up, the daemons running / their config and the type of incoming requests.
For example, website serving static content would have the following potential bottlenecks:
- bandwidth (obviously); what's you're physical bandwidth? are you sending compressed or uncompressed data?
- storage access speed (depending on the size of the static content and the number of files - for smaller, fewer files, Linux will cache the data),
- your kernel's TCP/IP configuration (time outs, stack size, etc)
- your web daemon config (eg Apache). (Are you running keep-alive? what's your connection limit and thread limit? what's your threading model? (different threading models can affect the speed new TCP/IP sockets are opened)
- and -obviously- the number of simultaneous requests
- your physical infrastructure (switches, firewalls, number of hops within your datacenter, etc)
- additional software running (are folding on your web server lol?, running XWindows on a headless box, etc)
However when you throw a database into the equation, you're then adding the following variables:
- database throughput (which is dependent on the complexity of SQL queries (number of joins, record calculations, nested sub-queries, etc), table optimizations (indexing etc), table storage engines, size of the data to return, if a different box then the hardware the database is running on (eg RAID controllers, etc) and so on.
- server side language and APIs used (even in the case of Perl, mod_perl massively out performs FastCGI as mod_perl uses Apache APIs directly instead of interfacing with a "go-between" interface (namely CGI).
- optimizations in your code (bad code will naturally run slower)
- web server config (again); as some languages can be further performance tuned for in the http daemon
- is your db server and web server the same box? and if not, what's their link speed?
And on top of that there's additional tweaks you can perform:
- reducing output file sizes by "minifying" source code (eg removing white space from CSS, JS and HTML) and using shorter variable names
- reducing the number of HTTP requests per page (eg using rewrites instead of redirects, having image clips (i think they're called) which have multiple "slides" per image and thus you have fewer images to download but each image is then sliced by JS / CSS when rendered. I've explained that very badly though.
- clever use of domain names to reduce the number of DNS look ups on the client side (this is purely tuning to make the clients page load faster, you wouldn't see any impact on the server load)
- or going the other way and having more domain names two bypass web browsers parallel download per domain name limit - thus allowing a webpages resources to load quicker (as above, this wouldn't impact server load but it would make a difference on the client side).
...and out of all of them, only one of those items is relating to the kernel.
So while you could make some kernel tweaks (eg like the ones suggested here
) to squeeze a little more performance out of your web servers, there are so many bigger bottlenecks to account for. And by the time you reach the point where the make-or-break of performance is down to kernel tweaks, then that's the time you really need to invest in a few more boxes in your web farm.
I think where kernel tweaks really come into their own is when building ultra-low latency real time systems. But in those cases a server OS may not be the best fit anyway; which again depends massively on the specific set up and it's requirements.
Originally Posted by parityboy
(love your avatar by the way
Is that your cat?)
. No, it's not mine, but my two cats (particularly the youngest) are just as bonkers so it does remind me of them Edited by Plan9 - 11/13/12 at 11:12am