Quand on est intéressé par l’achat d’un serveur dédié, l’une des choses primordiales qui rentre en compte est bien entendu le fait qu’il tienne le choc face à la demande des visiteurs.

Il m’arrive souvent de lire que certain serveur dédié sont des serveurs low-cost et qu’ils ne tiendront pas face à un afflux important de visiteurs. Je parle particulièrement des offres KimSufi d’OVH. J’ai bien conscience que les KimSufi font partis de la catégorie bas de gamme vu les autres serveurs proposés, mais il faut arrêter de dire qu’avec un KimSufi on ne fait rien. Je le lis souvent et on me l’a trop souvent dit.

 

Prenons un exemple qui j’espère vous fera changer d’avis sur ces serveurs, qui selon moi sont d’un ratio qualité/prix imbattable. Enfin je dis ça mais depuis le récent changement d’offre OVH, c’est moins vrai…Pour information j’ai un KimSufi XXL.

Il y a deux jours, Oshin.fr a connu un “buzz” ce qui a permis de monter (pendant une journée ) jusqu’à un nombre de visiteurs uniques de plus de 10000 et environ 18000 pages vues et tout ça sur du Wordpress (réputé pour être gourmand) sans optimisation. Avec une bonne configuration, le serveur n’a pas dépassé un taux d’utilisation de 50% (en crête) et avait une moyenne de 30%.

Certains, que je connais un peu, vont venir me voir et me dire qu’avec toute la bonne volonté du monde, leur serveur ne tient pas les 2000 visiteurs. Moi c’est ce qui m’arrivait avant que je découvre et remplace Apache par Lighttpd. Une merveille !

 

Alors je vous en conjure, arrêtez de gueuler sur le hardware et configurez votre machine autrement qu’avec les pieds (ou du Apache !).

Durant cette période d’examen je n’ai pas énormément le temps de bloguer mais je voudrais quand même partager avec vous une trouvaille (pour moi ) que j’ai faites la semaine dernière lors d’une montée en charge très violente sur mon serveur. Ainsi Apache2 ne savait plus où donner de la tête et il fallait le rebooter toutes les 15 minutes si je voulais ne pas remplir mon swap et faire planter tout le bordel…

Ainsi après avoir essayé de brider au minimum Apache je me suis motivé à installer LightTPD dont j’avais d’ailleurs parlé dans un précédent post.

Avec ma chance légendaire j’installe une version non à jour qui présente un bug un peu génant dit “memory leak” qui à l’instar de FireFox cannibalisait encore plus vite la mémoire vive qu’Apache. Bref ça n’avançait pas !
Mais en mettant à jour tout le bouzin plus de problèmes ! C’est presque magique.

Depuis le passage d’Apache2 vers LightTPD 1.4, je n’ai plus de problème de plantage, mon swap est à 0Ko (ça fessait longtemps !), la vitesse de chargement des pages est aussi rapide (voir plus dans certains cas). Je dors enfin sereinement !
Pour finir ce post très “j’ai enfin trouvé comment ne plus faire tomber mes sites” je voulais juste dire que Lighty (de son petit nom !) porte bien son slogan : Security, speed, compliance, and flexibility. Un soft qui mérite une meilleure place sur le marché des serveurs web (PDM d’environ 1.5%).

A part des utilisations très spécifiques (dont très peu de monde a besoin !) Apache peut (et doit ) être remplacé par LightTPD. En effet tout ce qui est présent sous Apache l’est aussi sur Lighty. Le seul petit truc gênant est la non utilisation des fichiers .htaccess. Donc pour votre URLRewriting il faudra directement le mettre dans le fichier de configuration de Lighty.

Alors vous passez quand à LightTPD ?

Quand on met en place Apache sur un serveur, il faut savoir le configurer pour avoir de bonnes performances. Mais il faut prendre en considération les pics. Personnellement je calcule comme ça :

• Une page vue équivaut à environ 15 requêtes HTTP (css, images de fond, images, javascript et contenu dynamique).

Donc si vous avez 100 000 pages vues par mois cela fait 1 500 000 requêtes HTTP ce qui fait moins de 1 requête par seconde en moyenne ce qui est tout à fait supportable. Mais cette moyenne prend en compte la nuit, moments où pas grand chose se passe. Et donc il peut y avoir des crêtes dues aux horaires de fréquentation du site ou à cause d’un lien réalisé par un site à fort trafic. Et là c’est la découverte de la “cata Apache”, le serveur va tenir 20, 50 voire 150 requêtes simultanées puis “BOOM !”, un reboot salvateur sera généralement nécessaire jusqu’à la prochaine fois. Il est possible de retarder l’échéance avec deux trois artifices mais paradoxalement l’effet sera aggravé !

Donc même avec 8 cores et 32Go de Ram (j’exagère mais c’est l’idée !), vous ne pourrez pas avoir enormément de requêtes par secondes. Même si Apache est bien configuré.

Pour ceux qui seraient tenté de dire que le navigateur met en cache les données et ne les redemandent pas au serveur c’est vrai mais pour cela Apache crée quand même un processus avec un code 304 (content not modified). Donc on tourne en rond…

Une solution souvent utilisé est d’utiliser Apache pour le contenu dynamique et Lighttpd pour le statique. Oui mais..pourquoi utiliser deux logiciels alors que Lighttpd permet de faire du PHP ?

Je suis donc actuellement entrain de tester Lighttpd pour le contenu statique et dynamique (PHP5 via FastCGI). Je vous en dirais plus bientôt ! Mais d’après les premières constatations Lighttpd tient bien mieux qu’Apache.