Cette page contient diverses informations sur la configuration du serveur apache.

Il y a 3.600 secondes dans une heure. Soit pour 24H ⇒ 86.400 secondes.

Si on compte une moyenne de une requête par seconde, cela donnerait alors moins de 100.000 requêtes par jour.

10 requêtes par seconde ⇒ 1.000.000 de requêtes par jour

100 requêtes par seconde ⇒ 10.000.000 de requêtes par jour

Pour une page web, on peut compter facilement une dizaine de requêtes: le html, le CSS, le Javascript, les images, etc…

Le serveur apache doit être configuré pour faire face à la popularité des sites hébergés.

1.000 pages par jour ⇒ site personnel

10.000 pages par jour ⇒ site public

100.000 pages par jour ⇒ site commercial

1.000.000 pages par jour ⇒ site portail

Si on compte une moyenne de 30 requêtes par page (HTML + CSS + Javascript + JPG + PNG + SWF + FLV + etc…)

Le serveur apache doit être configuré pour faire face à la popularité des sites hébergés.

30.000 requêtes par jour ⇒ 1.000 pages par jour ⇒ site personnel

300.000 requêtes par jour ⇒ 10.000 pages par jour ⇒ site public

3.000.000 requêtes par jour ⇒ 100.000 pages par jour ⇒ site commercial

30.000.000 requêtes par jour ⇒ 1.000.000 pages par jour ⇒ site portail

Le problème des sites populaires, c'est qu'il y a souvent des événements qui provoquent des pics de fréquentation.

On peut ainsi voir de 10% à 30% des visiteurs totaux du site en même temps, si ce n'est pire…

Ainsi pour un site commercial (disons 100.000 visites par jour), on peut avoir 10.000 à 30.000 visites en même temps. (Vive les Soldes :P )

Si votre serveur apache peut gérer 100 requêtes par seconde, cela revient à une dizaine de visiteurs, soit environ 600 visiteurs en une minute. On met pour le moment de côté les aspects de streaming vidéos…

Pour être complètement robuste, il faudrait pouvoir gérer 10.000 visiteurs en une minute, soit autour de 2.000 requêtes par seconde! Il vaut mieux alors répartir la charge sur plusieurs serveurs.

Le logiciel Citizen*Web [http://citizen-web.com] permet très simplement de créer un site “miroir”.

Il suffit ensuite d'ajouter un plugin sur le site principal pour rediriger une partie des requêtes vers les serveurs miroirs. L'utilisation de plusieurs serveurs n'est pas gênant pour le référencement avec Google.

Pour les images, il convient d'utiliser des sous-domaines pour que Google ne classe pas votre site en “HotLink” (…parasite qui utilise le contenu des autres sites… ). Google pourrait alors pénaliser le Page Rank de votre site.

Pour les ressources comme JS ou CSS, Google les considère comme ressources techniques et donc ne les prend pas en compte pour le référencement. A noter que les images utilisées par le CSS devraient être sur le même serveur que le fichier CSS pour plus de simplicité de gestion…

Si vous voulez exploiter tous les sous-domaines, vous allez commencer par placer une “wildcard” ou “CATCH ALL” pour que les sous-domaines qui n'existent pas soient renvoyées sur un site par défaut.

Ensuite quand vous allez rajouter des sites particuliers pour un sous-domaine, vous allez rajouter leur définition comme serveur virtuel sous apache. Il faut alors que le sous-domaine générique soit déclaré en dernier. Si vous utilisez un fichier .conf pour chaque sous-domaine, cela signifie généralement commencer les sous-domaines particuliers par un chiffre comme 000 et le domaine générique par zzz.

Cette technique devient vite incontournable pour se simplifier la vie…

http://httpd.apache.org/docs/2.0/misc/rewriteguide.html

URL_Rewrite

Note:

Dans les règles d'URL Rewriting, on peut lancer une requête en mode proxy sur le même serveur. Pour que cela fonctionne, il faut que le serveur apache ait activé son module proxy et proxy_http.

Pour améliorer la robustesse des services, il faut jouer avec

• le Round Robin au niveau du DNS en réduisant le TTL
• et le Reverse Proxy pour le serveur Apache.

http://www.linux-nantes.org/Deux-serveurs-web-chez-soi-Reverse.html

http://www.simplefailover.com/outbox/dns-caching.pdf

http://dedibox-news.com/t4040-Deux-pour-meme-site.html

Attention!

Par contre, en posant un serveur proxy en front-end au code PHP, on perd l'utilité de la variable $_SERVER['REMOTE_ADDR'] qui contient alors la valeur IP du proxy!

Il faut avoir la bonne configuration apache pour qu'il ajoute dans le header l'information HTTP_X_FORWARDED_FOR, qui contient la liste des IPs successives des proxies (s'ils sont transparents et ont bien voulu renseigner cette valeur…)

function get_ip_list() {
    $tmp = array();
    if  (isset($_SERVER['HTTP_X_FORWARDED_FOR']) && strpos($_SERVER['HTTP_X_FORWARDED_FOR'],',')) {
        $tmp +=  explode(',',$_SERVER['HTTP_X_FORWARDED_FOR']);
    } elseif (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
        $tmp[] = $_SERVER['HTTP_X_FORWARDED_FOR'];
    }
    $tmp[] = $_SERVER['REMOTE_ADDR'];
    return $tmp;
}

ce bout de code est extrait de http://fr.php.net/getenv

installation

Architecture_Serveurs_Web

Des exemples pour augmenter la performance de son serveur apache:

http://ftp.traduc.org/doc-vf/gazette-linux/html/2006/123/lg123-D.html

Les performances du serveur web peuvent être évaluées avec un outil installé avec apache2: ab (pour apache bench)

http://httpd.apache.org/docs/2.0/programs/ab.html

ab -c 10 -n 100 -v 4 http://microwebagency.com/

• L'option c paramètre le nombre de requêtes lancées en parallèle (en même temps)
• L'option n paramètre le nombre total de requêtes lancées en tout
• L'option v change les informations affichées pour l'utlisateur

Le rapport final donne plusieurs mesures… Dont les temps minimum et maximum de réponse. Il faut aussi regarder le nombre de requêtes qui ont échoué: cela donne la limite de charge acceptable pour le serveur web. Au delà, apache peut bloquer… Et il faut alors stopper les processus et ensuite les relancer.

apachectl -k stop
sleep 10
apachectl-k restart

Il faut tester plusieurs charges progressivement pour évaluer les limites.

http://httpd.apache.org/docs/2.0/misc/perf-tuning.html

Avec apache bench, on peut évaluer la performance du serveur web seulement en demandant une image ou un document html statique.

Ensuite, on peut éavluer l'impact de PHP avec une URL demandant un script PHP.

Enfin, on peut évaluer l'impact de PHP + MySQL en utilisant l'installation par défaut d'un CMS comme WordPress ou Joomla.

ab -c 10 -n 100 http://microwebagency.com/

ab -c 20 -n 200 http://microwebagency.com/

ab -c 30 -n 300 http://microwebagency.com/

ab -c 40 -n 400 http://microwebagency.com/

ab -c 50 -n 500 http://microwebagency.com/

etc… jusqu'à obtenir les premières “Failed Requests”

Il est possible pour apache de changer l'utilisateur qui exécute la requête courante. Cela permet de restreindre l'accès à un dossier si il y a plusieurs sites hébergés sur le serveur.

http://httpd.apache.org/docs/2.0/suexec.html

http://httpd.apache.org/docs/2.0/mod/mod_suexec.html#suexecusergroup

Il faut aussi combiner le suexec de apache avec les paramètres open_basedir et disable_functions et disable_classes de PHP qui permet de vérifier que toutes les fonctions PHP n'utiliseront que des fichiers délimités à une arborescence déterminée.

Ces valeurs ne se modifient pas dans un fichier .htaccess (car elles sont définies avec php_admin_value ou sont seulement modifiables dans le php.ini)

http://fr.php.net/manual/fr/ini.list.php http://fr.php.net/manual/fr/configuration.changes.php#configuration.changes.apache

open_basedir fonctionne dans le fichier conf d'un virtual Host

php_admin_value open_basedir /chemin/de/la/racine/du/site/web/

Fonctionne dans le php.ini ou bien dans un fichier .ini sous /etc/php5/apache2/conf.d/

disable_functions = "proc_open, popen,disk_free_space, diskfreespace, set_time_limit, leak,tmpfile, exec, system, shell_exec, passthru"

Il faut utiliser une version de apache spéciale “apache2-mpm-itk”

http://www.howtoforge.com/running-vhosts-under-separate-uids-gids-with-apache2-mpm-itk-on-ubuntu-9.04