Nginx est ni plus ni moins qu’un serveur web (d’origine russe), à l’instar d’Apache, lighttpd ou encore IIS. Et c’est avec ce jeu de mot sorti de mon imaginaire florissant (cf le titre du post) que je vais vous parler de ma récente découverte d’Nginx.

Tout d’abord la genèse. Si vous suivez ce que j’écris depuis un moment, vous savez certainement que j’étais passé sur Lighttpd. Il répondait à mes besoins jusqu’à ce qu’il soit touché par un bug (connu mais non résolu) de fuite de mémoire (memory leak). C’est tout de même assez embêtant pour un serveur web d’avoir des fuites de mémoire, surtout en phase de production…Puis je suis passé sur un nouveau serveur (il faudrait que je vous parle de la virtualisation d’ailleurs !). Et j’ai écouté le côté obscure de la force qui m’a dit qu’Apache2 c’était très bien (je ne dénoncerai pas la personne !). Mais la catastrophe. Ram bouffée en quelques heures. Je me suis (vraiment) arraché les cheveux, stressé pendant de longs jours, configuré de tous les côtés. Mais rien. Au mieux j’arrivais à reculer l’inévitable (up d’Apache de 26h maximum…). La Ram devenait pleine et le serveur freezait.

C’est à ce moment là que j’ai commencé à entendre parlé de Nginx. Je me suis renseigné, lu la documentation, on m’en a reparlé. Et j’ai décidé de sauter le pas. Depuis ? Depuis le serveur est stable.

Avant je me demandais comment Apache2 arrivait à manger autant de RAM. Maintenant je me demande comment Nginx fait pour en utiliser aussi peu. C’est vraiment hallucinant.

Pour information, Nginx sert en moyenne (sur 24h) 2 requêtes par seconde. Ce qui est beaucoup pour certains et peu pour d’autres (phrase profonde !).

Pour plus d’information je vous encourage fortement à regarder par ici. Je ferai un autre post avec des notions plus techniques sur Nginx d’ici quelques jours (et quand j’aurai du temps !).

Comme disait la pub : « Quand y’en a marre, ya Malabar ».

 

Cette après midi je m’aperçois que mon serveur est tombé. C’est là que la merde commence ! Je remet tout en place, je regarde mes logs et je me rend compte du nombre de requête hallucinantes que j’ai par seconde sur un site sécurisé, protégé des visiteurs (ceux qui connaissent comprendront ) et non référencé. Déjà je ne comprends pas…Mais après je vois que ces IPs viennent exclusivement de Chine. J’ai donc pris une décision sans appel. Mais là n’est pas le problème car maintenant c’est résolu !

 

Je me penche donc profondément sur mes logs access. Et là je vois un nombre irréel de hit venant de site de warez. Ce qui se passe c’est que ces sites utilisent directement mes images pour illustrer leurs liens de téléchargement…

Et quand je dis que j’ai un nombre impressionnant de hit c’est que j’ai plus d’un site de warez par seconde qui fait une requête sur mon serveur…avec bien entendu les plus grands en premier comme wawa-mania…Et à part me faire un annuaire de site warez ça me fait assez chier, surtout que ça m’apporte aucun visiteur étant donné qu’il n’y a pas de lien vers mon site.

 

Donc d’après ce que dit wikipedia c’est illégal. Je suis donc partie dans l’optique de mettre en place un système qui affiche l’url de mon site à la place des images hotlinkées. Ce système serait simple à mettre en place car j’autoriserais que mes sites à pouvoir les utiliser, les autres sites prendraient une image par défaut avec une belle url ! Mon problème est au niveau du référencement. Est-ce que si je fais ça Google va me pénaliser/va s’en rendre compte. Car j’ai pas mal de visite venant de Google images.

 

Si vous aussi vous avez eux un problème similaire merci de m’éclairer un peu !

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.