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 !).

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.

 

Apple met à disposition (pour 99€ par an) un espace de stockage de 10Go afin de permettre le partage de fichiers, nommé iDisk. Figurez-vous que payer 99€ par an pour 10Go me pose un problème, car je paye déjà un serveur dédié chez OVH. Il y a quelques temps j’avais essayé de faire une sorte de iDisk mais ça n’avait rien donné…

La semaine dernière on m’a parlé d’un module pour Apache : WebDav qui permet justement de faire une sorte de Disque Dur externe distant. Mon oeil a tout de suite brillé. J’ai tout de suite vu la bonne idée !

Après quelques jours de bidouillage, de configuration, WebDav est enfin opérationnel. Même si des problèmes de multi-utilisateurs sont encore présent, mais on verra plus tard quand j’aurais le temps !
Tous les systèmes d’exploitations sont compatibles. Depuis Windows il suffit d’ajouter un Favoris réseau, depuis Mac de faire Pomme + K depuis le Finder et sur Linux…bien évidemment !

J’ai donc monté sur mon dédié WebDav ce qui me permet d’avoir un disque dur externe à distance de grande capacité, disponible de n’importe quel ordinateur dans le monde et doté d’une connexion très rapide.

Vous voulez vous aussi utiliser WebDav sur vore serveur ? Lisez donc ces pages :

• Wikipedia
  
• Si vous partez d’un serveur sous Plesk
• Comment accèder à votre disque dur depuis Windows, Mac, Linux
• La gestion des droits (assez complexe)
• Gestion des droit, version plus complète