那么，是什么使得一台服务器的性能表现的好或者坏呢？这确实是由它的子系统（CPU、内存、磁盘和网络输入/输出等）集成的性能所决定的。我们可以将这些子系统进一步分解为附加的Web特定部件，包括 HTTP 守护进程、TCP/IP协议栈、文件系统、数据库和诸如CGI、NSAPI或者ISAPI这类服务器上的程序等。
HTTP守护进程是任何Web服务器的核心，因为它提供了将内容推到浏览器的引擎。经过适当调节的HTTP守护进程的性能可以是从来没被调节过的守护进程性能的10倍。所以，如果你不调节你的引擎，你就不可能让你的站点发挥其全部潜在的能力。大多数Web服务器，包括Apache、Netscape和微软的Web服务器，他们都提供了调节子系统。在许多情况下你还需要在操作系统级别进行调节。
为了提高性能，理解不同的Web服务器的体系结构是很重要的。例如，一些Web服务器为每个 HTTP 请求发起（fork）新进程。这就严重影响了性能，因为这种方式消耗可观的系统资源。
但是有个好消息，目前最具有“艺术性”的Web服务器充分利用了所谓的多线程技术，也就是将每个HTTP请求都放在其自身的线程中。线程是一种轻度的进程，它要求的资源仅仅是真实进程负载的很小一部分。最后的结果就是使用同样数量的处理器和内存资源却可以管理更多的连接。最新的Netscape公司的Enterprise Server和微软公司的IIS Web服务器就采用了多线程。对比之下，NCSA 服务器则继续采用预先分配进程的方式。
HTTP守护进程可以通过一些参数进行调节，你的站点上安装的默认配置通常并没有进行优化。所以你确实要进行调节来满足你的环境需要。
例如, 如果你正在使用一个Netscape公司的Enterprise Server 1.1这样的非线程类型的Web服务器，那么你需要保证服务器守护进程的数目要设置为与你的系统上的内存相匹配。默认值是最大32、最少16个守护进程。对大多数站点建筑者来说，一个更好的解决方案是将最大值设置到128，然后，增加运行的守护进程的数目，同时周期性检查错误记录文件来找出适当的最小值。
这样做的目的是为了将运行的各个守护进程的生命期和效率都最大化。因为每个守护进程都要耗费内存和处理器的时间，所以你不想让太多的守护进程无事可做。你设置的守护进程数越大，你要防止过度启动和停止守护进程所做的工作就越多，过多的的启动和停止守护进程对服务器的性能具有负面影响。
虽然HTTP守护进程看起来似乎对服务器的性能具有的影响力最大，但是，其他子系统也同样具有这方面的作用。例如，TCP/IP协议栈的效率能在很大程度上决定HTTP连接的性能，而文件系统则决定着把内容从磁盘移到引擎（守护进程）的速度和效率。大多数Web服务器采用了缓冲子系统来阻止服务器为同样的内容而再三地存取磁盘。
最后，CGI、NSAPI和ISAPI程序在其将动态内容推向浏览器时消耗了可观的部分资源，所以对这些程序也必须优化。
提高TCP/IP 性能的方法包括增加TCP侦听backlog。经验表明，如果Web服务器在处理较重负载时停止接受新的连接，那么这个时候就是增加backlog的恰当时机。这项任务通常使用服务器自带的TCP/IP 软件或者经由操作系统来完成。
例如，假设你的服务器使用 Solaris 2.4操作系统，那么，你首先必须让服务器程序使用更高的backlog参数来调用listen()函数。然后你必须同时增加系统级最大侦听backlog参数。
listen()函数的backlog参数（对类似Solaris 2.4这样基于Unix 的操作系统而言）-管理着已接受连接的最大数目，这些连接由TCP针对侦听套接字（代表堆栈侦听网络的进程，例如 Winsock）进行排队。
除了与侦听backlog打交道以外，你可能还要调节TCP的重发次数。大量的TCP重发意味着与你的地点建立联接的浏览器正在变得速度越来越慢或者出现错误的连接。重传这些连接消耗了本可以分配给新连接的带宽。
以上的调节工作其实就是一个使用系统工具（例如Unix系统的 netstat - s命令）监控重传次数的过程。如果重传比率高于40%，那么你就应该降低TCP重发率。这样做的结果使你断开了连接情况不良的用户（这些连接消耗了大量的系统资源），也为那些不需要太多重传次数的良好连接释放了资源。
其他调节Web服务器的窍门还包括禁用反向DNS查找，这样，服务器就不会为记录文件（带来显著的网络负载）确定主机名称而引起延迟。此外，站点建设者还需要做些务实的工作，比如，确保Web服务器的供应商用最新而且最具功能性的编译器编译其服务器。
