Tudo depende muito do seu site. Fazer benchmarks off-line e on-site não vai doer. Mas, o que ajustar e como testar?
Se você está servindo principalmente conteúdo estático ou algum conteúdo dinâmico simples muito e fazendo isso a uma taxa insana, então ajustes no tempo limite do Apache / nível do kernel fazem sentido.
Se você tiver um site dinâmico, os ajustes muito em breve se tornarão uma besta diferente. Claro, fazer todas essas otimizações no nível do kernel e do Apache ainda é uma coisa sensata a ser feita, mas não seja enganado e espelhado por elas.
Quando se trata de ajustes / testes de desempenho, sempre primeiro cuide das partes mais lentas. Com um site dinâmico, o gargalo real é provavelmente 1) o banco de dados ou 2) os scripts que seu site está executando.
Se a parte mais lenta for o banco de dados, não faz sentido ajustar o desempenho do seu Apache antes que você possa tornar seu banco de dados mais rápido. Além disso, você precisará ter certeza de ter as técnicas de cache adequadas e executar o memcached ou semelhante, se possível.
Então, foi sobre o que avaliar e ajustar. Agora, como é o benchmark?
Eu gosto de executar dois tipos de benchmarks. Se os números já são conhecidos - digamos, um site está recebendo uma reformulação, para que você conheça visitantes únicos, carregamentos de página e estatísticas semelhantes do site antigo -, eu executo um benchmark realista com taxa semelhante ao site atual. Eu também o benchmark com uma taxa similar * 2 para ver se ele pode suportar um pouco do crescimento futuro.
O outro tipo de referência que gosto de usar é fumar e queimar o site. Vou apenas torturar o inferno fazendo benchmark o mais rápido possível com quantidades insanas de solicitações simultâneas. Se puder aguentar, ótimo, se não puder, acho qual é o ponto de ruptura.
Ferramentas que eu gosto: ab, siege, JMeter.