Tutoriel pour apprendre à installer et à optimiser Apache2

Quentin Busuttil

Apache2 c'est un peu le dinosaure du web. Le serveur de la fondation du même nom n'a plus à être présenté. Moderne, hyper configurable, puissant, quoi qu'on en dise, il reste un incontournable et répond à la plupart des besoins. Voyons tout de même en détail comme l'installer et l'optimiser.

Mesdames, Messieurs, oui, j'ai bien dit l'optimiser. On a l'habitude d'installer Apache avec un simple coup d'apt-get et puis s'en vont. Or s'il est vrai que la configuration par défaut suffit à bien des usages, il ne fait aucun mystère qu'une config plus fine apportera sécurité, rapidité et scalabilité.

Pour réagir à ce tutoriel, un espace de dialogue vous est proposé sur le forum. Commentez

- Titre : Tutoriel pour apprendre à installer et à optimiser Apache2

- Auteur : Quentin Busuttil

- Parution : 25 septembre 2017

- Licence : Copyright ® 2017 Quentin Busuttil. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Installation

- II. Configuration

- II-A. Création des VirtualHosts

- II-A-1. VirtualHost et ServerName

- II-A-2. DocumentRoot

- II-A-3. Directory

- II-B. SSL/TLS et HTTP/2

- II-C. Les modules complémentaires

- II-C-1. deflate pour les performances

- II-D. Les fichiers de log

- II-E. Sécurité

- II-E-1. Les CHMOD

- II-E-2. Le fichier de configuration security

- II-E-3. Empêcher de parcourir les fichiers

- II-E-4. Les modules complémentaires relatifs à la sécurité

- II-F. Optimisation des performances

- III. Note de la rédaction de Developpez.com

I - Installation

Toutes les commandes exécutées ci-après sont exécutées en root. Pensez donc à passer en root avec sudo su ou à faire précéder vos commandes de sudo.

Le serveur Apache est bien entendu disponible dans les dépôts de Debian et d'Ubuntu. Pour l'installer, nous pouvons nous contenter d'un :

apt-get install apache2

Cependant, si l'on veut profiter des dernières fonctionnalités telles que le http2, il va falloir installer une version plus moderne que celle proposée dans les dépôts.

add-apt-repository ppa:ondrej/apache2
apt-get update
apt-get install apache2

On a ici au préalable ajouté un dépôt « ppa » non officiel contenant les dernières versions d'Apache. Ce dernier dépôt est maintenu par le mainteneur de PHP des dépôts Debian. On peut donc s'y fier sans trop de craintes. Je n'ai pas vérifié, mais ça marche normalement aussi sur Debian.

C'est tout pour l'installation. Entrez maintenant l'adresse IP de votre serveur dans un navigateur, si tout s'est bien déroulé, vous devriez obtenir ce message :

It works!

This is the default web page for this server.

The web server software is running but no content has been added, yet.

Le dossier dans lequel se trouvent les fichiers HTML par défaut se situe dans /var/www et le texte que vous venez de lire est tout simplement ce qui est contenu dans /var/www/index.html.

II - Configuration

Bien qu'on puisse utiliser Apache out of the box, en plaçant simplement nos fichiers html dans le dossier www, nous allons explorer les options de configuration les plus courantes.

II-A - Création des VirtualHosts

L'hébergement virtuel (virtual hosting) est une méthode que les serveurs tels que serveurs Web utilisent pour accueillir plus d'un nom de domaine sur le même ordinateur, parfois sur la même adresse IP.

Wikipedia

Vous pouvez grâce à cette technique, héberger plusieurs sites sur le même serveur Apache. Attention cependant, pour qu'Apache puisse savoir vers quel site il doit vous rediriger, il faut que vous y accédiez via un nom de domaine, c'est grâce à ce dernier qu'il sera en mesure de vous présenter le bon site. Ceci ne marchera donc pas si vous entrez directement l'adresse IP du serveur dans votre navigateur. Néanmoins, pour les besoins de tests, vous pouvez modifier votre fichier hosts pour simuler une résolution DNS.

Apache possède deux répertoires dans /etc/apache2/ dans lesquels on place nos VHosts : sites-available et sites-enabled. Le premier regroupe tous les sites disponibles, tandis que le second concerne les sites actifs.

Ainsi, Apache n'ira pas regarder les VHosts contenus dans sites-available. Cela permet donc de faire des tests, de temporairement retirer un site, de préparer un nouveau site ou une migration, etc. Lorsque tout est prêt, il suffit de faire un lien symbolique depuis sites-available vers sites-enabled. Apache fournit même une commande spécialement à cet effet : a2ensite nom_du_vhost ainsi que son pendant inverse a2dissite nom_du_vhost.

Créons maintenant notre premier VHost dans /etc/apache2/sites-available/buzut.conf.

1. # Apache doit écouter sur le port 80 pour le http

2. # il est aussi possible de répondre à des requêtes sur des ports non standards

3. # ou même de ne pas définir de port spécifique en utilisant "*"

4. <VirtualHost *:80>

5. # nom d'hôte que le serveur utilise

6. ServerName buzut.fr

8. # noms alternatifs que le serveur utilise pour servir le même contenu

9. ServerAlias www.buzut.fr blog.buzut.fr

11. # email de contact de l'administrateur

12. # apache l'affiche sur certaines pages d'erreurs

13. ServerAdmin adresse@mail.com

15. # path de la racine du contenu à servir

16. DocumentRoot /var/www/buzut/

18. # ces règles s'appliquent à la racine

19. # et à tous les répertoires et fichiers descendants

20. <Directory /var/www/buzut/>

21. # interdiction de lister les fichiers dossier

22. # au cas où pas de page index présente

23. # suivre les liens symboliques (gain de performance)

24. Options -Indexes +FollowSymLinks

26. # .htaccess peut redéfinir ces paramètres [All|None]

27. # on gagne en performance à mettre à none

28. # on perd néanmoins en souplesse de configuration

29. AllowOverride None

31. # on précise que tous les utilisateurs ont accès au dossier web

32. # ainsi, en cas de maintenance, on peut s'autoriser uniquement soi-même

33. Order allow,deny

34. Allow from all

35. </Directory>

37. # on peut néanmoins les redéfinir ou les compléter pour un répertoire particulier

38. <Directory /var/www/buzut/>

39. Options Indexes

40. </Directory>

41. </VirtualHost>

II-A-1 - VirtualHost et ServerName

Nous avons configuré ce VirtualHost pour répondre à toutes les requêtes sur le port 80 : *:80. Il est également possible de préciser une IP, mais cela ne fait sens que dans le cas où le serveur sert des sites sur plusieurs IP publiques distinctes.

Par ailleurs, qu'il s'agisse d'IP ou de port, la directive VirtualHost ne modifie en aucun cas la configuration dictée par la directive Listen. Donc si le serveur n'est pas configuré pour écouter sur un port donné, le VHost mentionnant ce port ne sera d'aucune utilité.

En outre, le fait que ce VHost commence par *:80 ne signifie pas qu'il gère toutes les requêtes vers ce serveur sur ce port. Apache utilise le VirtualHost le plus spécifique correspondant à une requête pour y répondre. Pour configurer un autre VHost, il suffit de spécifier un autre bloc avec un ServerName différent. D'ailleurs, si vous n'avez qu'un VHost, ou pour en utiliser un par défaut, vous pouvez tout à fait omettre la directive ServerName.

Notez bien qu'un fichier de configuration de VHost peut contenir autant de directives VirtualHost que vous le souhaitez, donc autant de sites ou domaines différents. Mais il est tout de même recommandé de séparer les configurations de sites n'ayant rien à voir dans des fichiers différents. Cela vous permettra en outre de les activer et désactiver indépendamment les uns des autres.

II-A-2 - DocumentRoot

DocumentRoot concerne la racine du site à servir. En théorie, Apache ne servira rien qui soit en dehors de ce path, et tout chemin défini dans l'URL est relatif à cette racine. Si j'emploie le terme en théorie, c'est parce qu'il est possible avec les liens symboliques et avec la directive Alias de dire à Apache de servir des éléments se trouvant hors de la racine.

Revenons-en à notre root. Si celle-ci est définie à /var/www/buzut/ et que l'URL accédée est https://buzut.fr/wp-content/themes/buzut-theme/img/logo.jpg, Apache ira chercher logo.jpg sur le serveur dans /var/www/buzut/wp-content/themes/buzut-theme/img/logo.jpg.

En outre, si l'URL tente d'accéder à un répertoire, Apache tentera de servir le fichier défini par la directive DirectoryIndex (en général index.html, .php, .pl, ou .cgi).

Cette configuration par défaut peut bien entendu être modifiée au niveau du VHost : DirectoryIndex landing.html. Par ailleurs, si aucun de ces fichiers n'est présent, Apache tentera d'afficher un listing du répertoire si l'option Indexes est présente.

Vous l'aurez peut-être noté, mais si par défaut Indexes est désactivé dans notre racine (-Indexes), c'est que cette option permet de parcourir les fichiers et répertoires du serveur (dans la limite de ce qui est accessible publiquement). À moins que cela soit explicitement recherché, il n'y a pas lieu de laisser quiconque naviguer dans notre arborescence.

II-A-3 - Directory

Il semble que les explications fournies ci-dessus en commentaires sont assez explicites. Cette directive permet de définir les règles qui s'appliquent à un répertoire, ses fichiers et sous-répertoires.

Comme expliqué, il est possible d'appliquer un comportement particulier à un sous-répertoire en définissant de nouvelles règles dans une directive Directory plus spécifique.

Le AllowOverride dont il est fait mention permet à un fichier .htaccess de redéfinir les règles s'appliquant à un répertoire directement depuis celui-ci. Il suffit pour cela de placer les règles s'appliquant à Directory dans un fichier nommé .htaccess que l'on place dans le répertoire en question.

S'il est fait mention de performances, c'est que si cette option est activée, Apache doit vérifier pour chaque répertoire si un fichier .htaccess est présent. Dans le cas d'arborescences profondes, cela peut générer un travail supplémentaire non négligeable pour Apache.

II-B - SSL/TLS et HTTP/2

SSL/TLS, je ne pense pas avoir besoin de l'expliquer. Mais HTTP/2, qu'est-ce que c'est ? Tout simplement la dernière version du protocole de la norme HTTP. Cette version apporte de nombreux avantages dont un sérieux gain en performances.

Réduction de la latence pour améliorer les temps de chargement des navigateurs web notamment via :

- la compression de données des en-têtes HTTP ;

- le nouveau mécanisme de push de HTTP/2 permettant au serveur d'envoyer au client des données nécessaires, mais qu'il n'a pourtant pas encore sollicitées ;

- le nouveau mécanisme de pipelining des requêtes, comparable à ce qui se fait pour les processeurs ;

- résolution de problèmes propres à HTTP 1.x (voir HTTP pipelining ou head-of-line blocking) ;

- multiplexage de plusieurs requêtes au travers d'une seule connexion TCP.

Wikipedia

HTTP/2 ne fonctionne qu'en TLS. De toute façon, avec l'émergence de Let's Encrypt et ses certificats TLS gratuits, nous n'avons plus aucune excuse pour ne pas offrir une connexion sécurisée à nos sites.

Pour installer un certificat Let's encrypt, je vous laisse entre les mains de la doc officielle.

Vous voilà en possession de vos certificats, voyons donc à quoi ressemble notre VHost TLS et HTTP/2.

1. # on redirige le http vers le https

2. <VirtualHost buzut.fr:80>

3. ServerName buzut.fr

4. ServerAdmin adresse@mail.com

5. Redirect permanent / https://buzut.fr/

6. </VirtualHost>

8. # le port par défaut du https est 443, on pense donc bien à le spécifier

9. <VirtualHost buzut.fr:443>

10. # on active le http/2 avec fallback vers le http/1.1

11. # tous les navigateurs ne sont pas compatibles

12. Protocols h2 http/1.1

13. ServerName buzut.fr

15. ServerAdmin adresse@mail.com

16. DocumentRoot /var/www/buzut

18. ErrorLog ${APACHE_LOG_DIR}/error.log

19. CustomLog ${APACHE_LOG_DIR}/access.log combined

21. # on active le ssl/tls et on renseigne les certificats

22. SSLEngine on

24. # et on renseigne les path vers les certificats

25. #

26. # Fichier de données contenant le certificat X.509 du serveur codé en PEM

27. SSLCertificateFile /etc/letsencrypt/live/buzut.fr/cert.pem

29. # Fichier contenant la clé privée du serveur codée en PEM

30. SSLCertificateKeyFile /etc/letsencrypt/live/buzut.fr/privkey.pem

32. # Fichier contenant les certificats de CA du serveur codés en PEM

33. SSLCertificateChainFile /etc/letsencrypt/live/buzut.fr/chain.pem

35. # on active HSTS pour 6 mois pour le domaine et les sous-domaines

36. # on autorise aussi l'ajout du site dans les listes préchargées

37. Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"

38. </VirtualHost>

Pour activer TLS, il faut donc trois choses :

- définir le port d'écoute à 443 ;

- activer le support de tls avec SSLEngine on ;

- définir les chemins vers les différents certificats et clefs.

Par ailleurs, les modules permettant le support du TLS et de http2 ne sont pas forcement activés. Pour ce faire, on fera simplement un petit coup de a2enmod :

a2enmod ssl && a2enmod http2
service apache2 restart

Si vous souhaitez en savoir plus sur le HSTS, je vous laisse avec l'article Wikipedia qui est bien détaillé.

II-C - Les modules complémentaires

Selon les besoins de votre site, il vous faudra peut-être activer des modules supplémentaires. Par exemple, si vous utilisez l'URL-rewriting, il faudra activer le module mod_rewrite :

1. a2enmod rewrite

2. Enabling module rewrite.

3. To activate the new configuration, you need to run:

4. service apache2 restart

Il nous est dit qu'il faut redémarrer le serveur : To activate the new configuration, you need to run: service apache2 restart. Alors, redémarrez-le.

Apache possède de très nombreux modules qui viennent élargir ses fonctionnalités. Vous trouverez sur le site officiel la liste de tous les modules disponibles.

Puisque nous parlons des modules, nous allons aussi en désinstaller quelques-uns dont nous n'avons pas l'utilité. Une bonne politique dans la gestion d'un serveur est que tout ce qui ne sert pas peut être désactivé et supprimé. D'une part ceci nous permet d'économiser des ressources (les modules d'Apache prennent de la place en mémoire), d'autre part, ce sont autant de failles potentielles que l'on supprime.

En ce qui me concerne, je ne vire que le mod CGI (et il sera utile pour ceux utilisant PHP-FMP), la plupart de ceux préactivés servent souvent.

Vous utiliserez pour désactiver les mods la commande a2dismod suivie du nom du mode à désactiver. Ex. : a2dismod autoindex. Il peut être judicieux de ne pas tous les supprimer d'un coup et de tester après chaque désactivation si tout marche bien. Vous pouvez aussi utiliser la commande apache2ctl configtest qui vérifie la syntaxe de vos fichiers de config. Ça peut s'avérer intéressant si par exemple vous désactivez un mod dont vous avez besoin et auquel vous faites appel dans vos fichiers dans /etc/apache2/sites-enabled.

Note : je dis supprimer, mais n'allez pas supprimer ensuite le fichier du module, ça ne sert à rien pour le peu d'espace que vous allez gagner, et si vous en avez besoin pour une raison x ou y plus tard, vous serez content de n'avoir qu'à le réactiver.

Au besoin, vous trouverez dans mon article regroupant les commandes Linux les plus utiles, une partie web qui reprend l'ensemble des commandes Apache utiles.

Par ailleurs, si vous souhaitez exécuter du PHP, il va falloir installer le paquet du même nom. Sans lui, notre serveur Apache servira vos fichiers de code PHP tels quels. Admettons-le, c'est moyen…

II-C-1 - deflate pour les performances

Petite digression concernant deflate. Ce module, activé par défaut, permet de compresser avec gzip ou deflate - of course - les fichiers servis par Apache. Dans 99 % du temps, vous n'avez rien à faire. Cependant, il y a un type de média non compressé par défaut et qui peut pourtant avantageusement en profiter, il s'agit des images svg.

Pour permettre à Apache de les configurer à la volée, rendez-vous dans le fichier de configuration dudit module : /etc/apache2/deflate.conf

1. <IfModule mod_deflate.c>

2. <IfModule mod_filter.c>

3. # these are known to be safe with MSIE 6

4. AddOutputFilterByType DEFLATE text/html text/plain text/xml

6. # everything else may cause problems with MSIE 6

7. AddOutputFilterByType DEFLATE text/css

8. AddOutputFilterByType DEFLATE application/x-javascript application/javascript applic$

9. AddOutputFilterByType DEFLATE application/rss+xml

10. AddOutputFilterByType DEFLATE application/xml

12. # j'ai ici ajouté le type MIME du svg

13. AddOutputFilterByType DEFLATE image/svg+xml

14. </IfModule>

15. </IfModule>

On recharge ensuite la configuration avec un savant coup de service apache2 reload et en voiture Simone !

II-D - Les fichiers de log

Par défaut, Apache écrit ses logs dans /var/log/apache2. Il y a trois fichiers distincts :

- le error.log, qui regroupe toutes les erreurs d'Apache ainsi que de ces modules (c'est donc là que vous retrouverez par exemple les erreurs de PHP) ;

- l'access.log, qui regroupe les logs d'accès au serveur principal ;

- le other_vhosts_access.log, qui logue les accès des autres VHosts.

En réalité, la définition du fichier de log des accès se fait dans le VHost. Si vous voulez écrire vos logs dans le access.log au lieu du other_vhosts_access.log, ou même définir vous-même le nom de fichier de log, il va vous falloir ajouter une ligne dans le VHost.

CustomLog ${APACHE_LOG_DIR}/access.log combined

Vous pouvez remplacer access.log par le nom qui vous plaît si vous voulez en changer. Quant à combined, cela concerne le format des logs. Pour en savoir plus à ce sujet, je vous invite à aller consulter la doc.

Petit point de détail cependant, si vous ne spécifiez pas explicitement le access.log dans votre VHost, les logs iront automatiquement dans other_vhosts_access.log. Ce comportement peut ne pas convenir.

Nous pourrions par exemple vouloir ne pas activer les logs d'accès (pour des questions de performances par exemple). Dans ce cas, il va falloir désactiver une configuration. Laissez-moi donc introduire la commande a2disconf. Vous l'aurez deviné, elle va de pair avec a2enconf. Pour désactiver le other_vhosts_access.log, il faut donc exécuter :

a2disconf other-vhosts-access-log

Enfin, pour activer ce petit VHost, nous allons désactiver le site default, et activer le nôtre. Pour ce faire, nous allons utiliser deux commandes :

- a2dissite, qui permet de désactiver un vhost ;

- a2ensite, qui, à l'inverse, permet de les activer.

1. a2dissite default

2. Site default disabled.

3. To activate the new configuration, you need to run:

4. service apache2 reload

6. a2ensite mon_site

7. Enabling site default.

8. To activate the new configuration, you need to run:

9. service apache2 reload

11. service apache2 reload

12. * Reloading web server config apache2

13. ...done.

Le serveur nous spécifie la commande à effectuer pour que les modifications soient prises en compte. Il n'est pas ici nécessaire de redémarrer Apache, un simple rechargement avec la commande service apache2 reload suffit.

II-E - Sécurité

II-E-1 - Les CHMOD

Afin de bien sécuriser son serveur, il ne s'agit pas simplement de « balancer » les fichiers sur le serveur. Il faut accorder une vigilance toute particulière aux droits que possèdent ces fichiers.

La base consiste à donner le moins de droits possible aux fichiers et répertoires. Ainsi, le CHMOD devra être à 555 pour les répertoires et à 444 pour les fichiers. Si le propriétaire des répertoires et fichiers est le compte du développeur et non le serveur web, il peut être pratique de passer à respectivement 755 et 744. De cette manière, vous pourrez éditer vos fichiers sans passer en root.

J'ai écrit un article détaillé au sujet des CHMOD dans le contexte de l'hébergement web. N'hésitez pas à vous y référer pour plus de détails.

II-E-2 - Le fichier de configuration security

Il existe un fichier de configuration relatif à la sécurité d'Apache : /etc/apache2/conf-available/security. Les réglages qu'il apporte ne sont en réalité pas déterminants pour la sécurité de notre serveur. Voyons néanmoins les paramètres qu'il contient :

- ServerTokens : envoie des informations relatives à l'OS et la version d'Apache dans l'en-tête serveur ;

- ServerSignature : donne des informations en bas de page créées par le serveur (page d'erreur, 404, etc.) ;

- TraceEnable : la méthode TRACE est réservée pour le débogage.

On va donc placer ServerTokens à Prod, ServerSignature à Off et TraceEnable à Off. C'est tout pour ce fichier.

II-E-3 - Empêcher de parcourir les fichiers

Au niveau de la configuration de votre site, il est prudent de préciser quelques paramètres concernant la racine de fichiers :

1. <VirtualHost *:80>

2. ServerAdmin contact@monsite.fr

3. DocumentRoot /var/www

5. <Directory />

6. # empêche un fichier .htaccess de redéfinir ces paramètres

7. AllowOverride None

9. # empêche de parcourir le système de fichiers

10. # il faudra donc bien placer cette directive à allow

11. # dans le(s) répertoire(s) contenant votre/vos site(s)

12. Order allow,deny

13. deny from all

14. </Directory>

16. <Directory /var/www/monsite/>

17. …

18. </directory>

19. </VirtualHost>

II-E-4 - Les modules complémentaires relatifs à la sécurité

Parmi les modules d'Apache, certains permettent d'améliorer la sécurité. Je n'expliquerai pas ici leur fonctionnement, parce que cela nécessiterait un article complet, mais je vais vous donner les liens qui vont bien :

- Mod_security est une sorte de firewall pour Apache [en] ;

- Mod_evasive, qui protège des floods et attaque DDoS.

Pour ma part, je ne les utilise pas. Vous pouvez installer fail2ban pour améliorer la sécurité de votre serveur. Le pare-feu iptables, vous permet de bien vous prémunir contre les attaques DDoS.

II-F - Optimisation des performances

On parle beaucoup de Nginx dès lors que l'on mentionne les performances dans le web. Je dédie d'ailleurs moi-même un article à ce sujet. Cependant, Apache reste un serveur extraordinaire et qui sait se montrer très performant.

On commence rapidement par vérifier quel est le module MPM utilisé, à savoir, prefork ou worker. Si vous avez installé sans compiler, ne cherchez pas plus loin, par défaut, vous êtes en prefork.

# affiche les modules disponibles
apache2ctl -M

Nous ne traiterons pas ici des réglages spécifiques au MPM worker. Sachez juste que prefork est aussi performant tout en consommant un peu plus de RAM que worker. Il est également légèrement plus stable.

Parmi les optimisations que nous allons aborder, la plupart se trouvent dans /etc/apache2/apache2.conf ou httpd.conf sur Debian. En revanche, celles qui s'appliquent au module MPM se trouvent directement dans le fichier de conf du module, /etc/apache2/mods-enabled/mpm_prefork.conf pour le MPM prefork.

MaxRequestWorkers

1. Permet de déterminer le nombre maximal de requêtes pouvant être traitées simultanément. Au-delà, toutes les requêtes iront dans une file d'attente. Pour le prefork, cela correspond au nombre maximum de processus enfants qui pourront être lancés. Pensez que cette valeur est limitée par ServerLimit. Il vous faudra donc l'augmenter si vous voulez fixer un nombre de workers plus grand.
Enfin, pour calculer cela, c'est assez simple : (RAM totale - RAM utilisée par les autres processus) / taille moyenne d'un processus Apache. Munissez-vous de top et ps aux pour cette mission ! Et si vous être vraiment des gros flemmards, j'ai la formule magique qu'il vous faut pour calculer le poids moyen d'un process Apache :

1. # grep apache pour Ubuntu / grep httpd pour Debian

2. ps aux | grep apache | awk '{print $6/1024;}' | awk '{avg += ($1 - avg) / NR;} END {print avg " MB";}'

3. 38.1419 MB

MaxConnectionsPerChild

1. Fixé par défaut à 0 (infini), cette directive permet de faire « mourir » un processus après qu'il a servi un certain nombre de requêtes. Cela peut-être intéressant dans le cas de fuites mémoire. Par exemple, avec PHP, si les processus ont tendance à avoir une empreinte mémoire qui grossit indéfiniment, on pourra les limiter à un certain nombre de requêtes et un nouveau prendra la relève. Comme la création de nouveaux processus consomme du CPU, il s'agit de trouver le juste équilibre.

StartServers

1. Cette directive, qu'on utilise en général conjointement avec MinSpareServers et MaxSpareServers, spécifie le nombre de processus enfants qu'Apache doit lancer au démarrage.
La création et l'arrêt de processus sont dynamiques. Cependant, dans le cas de sites à très fort trafic, il peut être judicieux de démarrer directement avec de nombreux processus pour pouvoir affronter la charge sans un temps de warm up. Aussi, on jouera avec les directives (min|max)SpareServers afin de :

1. toujours avoir un minimum de processus enfants prêts à réceptionner des requêtes ;

2. ne pas tuer des processus lors d'une baisse momentanée de trafic alors qu'une autre vague risque d'arriver, obligeant une coûteuse opération de killing/re-creation.

KeepAlive & KeepAliveTimeout

1. Cette option offerte par le HTTP/1.1 permet de servir plusieurs requêtes dans la même connexion TCP. Ainsi, on garde littéralement ouverte une connexion TCP afin de pouvoir servir de nouvelles requêtes en évitant de perdre du temps en refaisant un handshake TCP. C'est particulièrement utile pour servir tous les assets d'une page sans ouvrir 10 000 connexions (typiquement JS, CSS, images).
C'est bien beau tout cela, mais notre petit KeepAlive bousille littéralement la capacité d'Apache de faire face à la charge. On l'a vu, Apache est limité par MaxRequestWorkers, or si on conserve les connexions ouvertes, forcement, on peut moins en servir en même temps…
KeepAlive permet quand même d'améliorer l'expérience utilisateur sur les connexions à forte latence (mobile et connexions géographiquement éloignées Europe/USA par exemple). De même, cela permet d'améliorer les performances dans le cas de polling Ajax.
Néanmoins, l'intérêt baisse quelque peu avec le HTTP/2, car il permet le multiplexache et le pipelining. Faites vos calculs, mais si vous avez un peu de charge, il est conseillé de clairement abaisser les 30 secondes par défaut.

FollowSymLinks

1. Nous l'avons déjà mentionné plus haut, mais il vaut mieux préciser cette option. En son absence, ou dans le cas où il est explicitement indiqué de ne pas les suivre, Apache devra faire des appels système supplémentaires afin de vérifier si le pointeur est un lien symbolique ou non. De plus, dans la mesure où les résultats ne sont pas mis en cache par Apache, c'est le bingo à chaque requête.

AllowOverride

1. Nous l'avons déjà mentionné aussi. Cette directive permet d'activer les fichiers .htaccess, grande spécificité d'Apache. Ces petits fichiers de configuration permettent une grande souplesse, car ils offrent la possibilité de configurer le comportement de sous-répertoires directement depuis ces derniers.
Ainsi, il est possible de laisser les utilisateurs ou les développeurs gérer eux-mêmes le comportement des répertoires dont ils sont responsables (rewriting, etc.). Dans une équipe où développeurs et administrateurs ont des rôles bien différents, cela laisse plus de latitude aux développeurs.
Néanmoins, c'est au sacrifice d'un peu de performances puisque Apache devra vérifier dans chaque répertoire la présence ou non d'un fichier de config, et le lire le cas échéant.

DirectoryIndex

1. Cette directive permet de spécifier le fichier à servir par défaut lors de la requête d'un répertoire. Typiquement la racine d'un site par exemple : buzut.fr et non pas buzut.fr/index.php. Apache sert donc automatiquement index.php lorsqu'on requête ce répertoire.
Il est possible - et on le voit souvent - de ne spécifier que le nom de base sans l'extension index. Cela permet à Apache de servir index.php, index.html, index.pl, etc. On gagnera en performances à spécifier les types, et il est possible d'établir une liste. Dans ce cas, les fichiers à gauche seront servis en priorité sur ceux à droite dans la liste.

DirectoryIndex index.php index.html index.pl

Sachant tout cela, après avoir laissé tourner le serveur quelque temps, il peut être judicieux de lancer un script qui analysera la config et différents paramètres afin de vous fournir quelques voies d'optimisations. Le script en question s'appelle apache2buddy et pour le lancer, rien de plus simple :

curl -L http://apache2buddy.pl/ | perl

On en a fini avec la configuration d'Apache. Je vous laisse quand même avec la doc officielle (qui est bien conçue et en français), au cas où vous voudriez creuser certains points.

III - Note de la rédaction de Developpez.com

Nous tenons à remercier Quentin Busuttil qui nous a aimablement autorisés à publier son tutoriel : Installer et optimiser Apache2. Nous remercions également Winjerome pour la mise au gabarit et Claude Leloup pour la relecture orthographique.