Bonjour,
Je m'occupe d'un serveur hébergeant un site spip consacré aux séismes sur la Côte d'Azur et la Ligurie: http://www.azurseisme.com
C'est un serveur dédié avec 200 Mbits/sec, 4 Go de RAM et un processeur I3. D'habitude, tout va très bien sauf événement très exceptionnel comme le séisme qui a touché la région niçoise il y a une semaine. De la centaine d'utilisateurs quotidiens, on est passé à 15 000 en quelques minutes. Le site s'est révélé très lent avec une pointe à 24 Mbits/sec et des centaines d'occurence d'apache simultanées mais là n'est pas le véritable soucis. Le rédacteur du site voulait ajouter un article consacré à l'actualité puis l'enrichir mais lui aussi était pris dans le trafic et chaque action comme aller dans l'espace rédacteur, charger des images, prévisualiser était d'une lenteur extrême.
Aussi, je me demande s'il n'y aurait pas moyen de favoriser le ou les rédacteurs via son @ IP au détriment des centaines ou milliers de lecteurs simultanés ? Peut-être faut t'il un autre serveur avec une autre @IP pour mettre à jour la base ?
Je sais bien qu'il s'agit d'une situation absolument exceptionnelle car le plus gros séisme ressenti depuis 30 ans mais je préfère prévoir l'avenir.
Merci de vos retours,
au niveau d'apache, rien ne permet à priori d'avoir une priorité entre un hit et un autre. Donc la seule solution que je voie consisterait a ajouter un serveur genre nginx, à le faire écouter sur un autre port, et à jouer du nice dessus.
Ceci dit, si le serveur s'est retrouvé complètement engorgé comme ça, le facteur limitant était probablement le disque dur plutôt que le CPU ou la RAM. Le cas échéant, la solution au dessus n'a aucun intérêt ...
Seule solution simple dans ce genre de cas: passer temporairement les différentes pages qui sont la cible des visiteurs en pages statiques: ça soulagera sacrément la bouzine car elles seront stockées en ram ( cache du système ).
Je refais ma réponse à la liste avec une précision supplémentaire je
viens de m'apercevoir que j'ai répondu à l'auteur seulement.
Le 14/04/2014 14:39, Jean-Max Reymond a écrit :
Bonjour,
Je m'occupe d'un serveur hébergeant un site spip consacré aux séismes
sur la Côte d'Azur et la Ligurie: http://www.azurseisme.com
C'est un serveur dédié avec 200 Mbits/sec, 4 Go de RAM et un processeur
I3. D'habitude, tout va très bien sauf événement très exceptionnel comme
le séisme qui a touché la région niçoise il y a une semaine. De la
centaine d'utilisateurs quotidiens, on est passé à 15 000 en quelques
minutes. Le site s'est révélé très lent avec une pointe à 24 Mbits/sec
et des centaines d'occurence d'apache simultanées mais là n'est pas le
véritable soucis.
Passer sur un hébergement de type "Cloud" dont on peut moduler la
puissance instantanément ? le genre de serveur que l'on paye à la
ressource par seconde auquel on peut dire "je veux 4 coeurs tous les
matins de 8h30 à 10h00 et 1 seul le reste de la journée" ?
Je fais pas de pub mais des trucs genre GandiFlex
(VPS et Cloud pour l'Infra-as-Code - Gandi.net) ou OVH
(http://www.ovh.com/fr/cloud/ressources-a-la-demande.xml).
En plus cela permet de s'affranchir du matériel en lui-même, de payer
moins quand c'est calme et de booster quand la terre tremble !
Ça me concerne, j'ai senti le tremblement de terre ici à Grenoble au
6ème étage, impressionnant, heureux d'apprendre que Spip est derrière
tout ça, pour le site je veux dire, m'étonnerait que l'écureuil fasse
trembler la terre, la noisette est trop grosse
Précision: la puissance/ressources peuvent même augmenter
automatiquement sur des seuils:
Le rédacteur du site voulait ajouter un article
consacré à l'actualité puis l'enrichir mais lui aussi était pris dans le
trafic et chaque action comme aller dans l'espace rédacteur, charger des
images, prévisualiser était d'une lenteur extrême.
Aussi, je me demande s'il n'y aurait pas moyen de favoriser le ou les
rédacteurs via son @ IP au détriment des centaines ou milliers de
lecteurs simultanés ? Peut-être faut t'il un autre serveur avec une
autre @IP pour mettre à jour la base ?
mais cela nécessite d'ouvrir l'accès à la base depuis un autre serveur,
à controler je pense. Sans parler du fait qu'il mettra à jour la base
qui sera peut-être de ttes façons à genoux elle aussi. Le serveur qui
grossit me parait mieux ... surtout que la commande se fait au travers
du panel Gandi/OVH donc indépendamment du serveur lui-même !
Je sais bien qu'il s'agit d'une situation absolument exceptionnelle car
le plus gros séisme ressenti depuis 30 ans mais je préfère prévoir
l'avenir.
Merci de vos retours,
au niveau d'apache, rien ne permet à priori d'avoir une priorité entre
un hit et un autre. Donc la seule solution que je voie consisterait a
ajouter un serveur genre nginx, à le faire écouter sur un autre port, et
à jouer du nice dessus.
Ceci dit, si le serveur s'est retrouvé complètement engorgé comme ça, le
facteur limitant était probablement le disque dur plutôt que le CPU ou
la RAM. Le cas échéant, la solution au dessus n'a aucun intérêt ...
il me semblait que spip avait un système de cache assez élaboré évitant la fabrication systématique d'une page si les éléments n'avaient pas changé. Avec ce cache, on sert des pages déjà toutes faites donc avec mes 4 Go de RAM, je suis certain de servir des pages en RAM mais peut-être que je me trompe. Je vais faire des tests avec JMeter pour en avoir le cœur net
Seule solution simple dans ce genre de cas: passer temporairement les
différentes pages qui sont la cible des visiteurs en pages statiques: ça
soulagera sacrément la bouzine car elles seront stockées en ram ( cache
du système ).
hélas, le tremblement de terre ne prévient pas et sans doute que pendant des années, il ne se passera plus rien d'important. Fait aggravant, le tremblement de terre frappe à toute heure du jour et de la nuit. A 21h30 en semaine comme lundi dernier, c'est quasiment l'idéal pour un webmaster mais ça peut ne pas être aussi rose (quoique c'est nuit blanche assurée).
De plus, la préfecture des Alpes-Maritimes compte bien utiliser tous les moyens possibles dont ce site pour donner des informations en cas de séisme avec des dommages matériels importants et donc bien plus de trafic en prespective.
il me semblait que spip avait un système de cache assez élaboré évitant la fabrication systématique d'une page si les éléments n'avaient pas changé. Avec ce cache, on sert des pages déjà toutes faites donc avec mes 4 Go de RAM, je suis certain de servir des pages en RAM mais peut-être que je me trompe. Je vais faire des tests avec JMeter pour en avoir le cœur net
-> Oui, spip possède un système de cache assez élaboré. Ceci dit, le cache fonctionne si je ne m'abuse en stockant les différents éléments inclus dans un squelette dans des fichiers différents. Chaque fichier contenant non pas du html statique correspondant à une page, mais du code PHP correspondant a un include. Donc lors d'un accès à une page en cache qui contient 10 includes, 11 fichiers seront lus sur le disque et évalués par le module php. Ce n'est pas la même chose que d'envoyer une page statique sans se poser de questions.
Toujours à vérifier mais il me semble que le cache est géré par rapport à une date globale. Donc si un pélo fait un commentaire ou si un article est modifié ou publié, l'intégralité du cache est invalidée...
Autre point intéressant dans ce genre de cas: avoir un domaine pour le dynamique servi par du apache ( si nécessaire ), et avoir un domaine pour le statique ( images, docs, css, js ) avec un serveur léger genre nginx qui dépote bien. C'est pas la panacée, mais ça limite le nombre de process apache joufflus sollicités par secondes.
hélas, le tremblement de terre ne prévient pas et sans doute que pendant des années, il ne se passera plus rien d'important. Fait aggravant, le tremblement de terre frappe à toute heure du jour et de la nuit. A 21h30 en semaine comme lundi dernier, c'est quasiment l'idéal pour un webmaster mais ça peut ne pas être aussi rose (quoique c'est nuit blanche assurée).
De plus, la préfecture des Alpes-Maritimes compte bien utiliser tous les moyens possibles dont ce site pour donner des informations en cas de séisme avec des dommages matériels importants et donc bien plus de trafic en prespective.
Hmm, dans ce cas, comme le disait Zapilou, les solutions "encloudées" sont indiquées car elles permettent des montées en charge rapide. Mais niveau prix, ce n'est pas la même
il me semblait que spip avait un système de cache assez élaboré
évitant la fabrication systématique d'une page si les éléments
n'avaient pas changé. Avec ce cache, on sert des pages déjà toutes
faites donc avec mes 4 Go de RAM, je suis certain de servir des pages
en RAM mais peut-être que je me trompe. Je vais faire des tests avec
JMeter pour en avoir le cœur net
-> Oui, spip possède un système de cache assez élaboré. Ceci dit, le
cache fonctionne si je ne m'abuse en stockant les différents éléments
inclus dans un squelette dans des fichiers différents. Chaque fichier
contenant non pas du html statique correspondant à une page, mais du
code PHP correspondant a un include. Donc lors d'un accès à une page en
cache qui contient 10 includes, 11 fichiers seront lus sur le disque et
évalués par le module php. Ce n'est pas la même chose que d'envoyer une
page statique sans se poser de questions.
Toujours à vérifier mais il me semble que le cache est géré par rapport
à une date globale. Donc si un pélo fait un commentaire ou si un article
est modifié ou publié, l'intégralité du cache est invalidée...
bingo, on a eu plus de 200 commentaires sur les 24 heures dont une centaine dans le premier quart d'heure au moment même où des milliers d'internautes visualisaient les pages. C'est sans doute cela qui a provoqué la forte charge machine en invalidant le cache à chaque commentaire.
Autre point intéressant dans ce genre de cas: avoir un domaine pour le
dynamique servi par du apache ( si nécessaire ), et avoir un domaine
pour le statique ( images, docs, css, js ) avec un serveur léger genre
nginx qui dépote bien. C'est pas la panacée, mais ça limite le nombre de
process apache joufflus sollicités par secondes.
Bonne idée, je vais investiguer cette solution.
hélas, le tremblement de terre ne prévient pas et sans doute que
pendant des années, il ne se passera plus rien d'important. Fait
aggravant, le tremblement de terre frappe à toute heure du jour et de
la nuit. A 21h30 en semaine comme lundi dernier, c'est quasiment
l'idéal pour un webmaster mais ça peut ne pas être aussi rose (quoique
c'est nuit blanche assurée).
De plus, la préfecture des Alpes-Maritimes compte bien utiliser tous
les moyens possibles dont ce site pour donner des informations en cas
de séisme avec des dommages matériels importants et donc bien plus de
trafic en prespective.
Hmm, dans ce cas, comme le disait Zapilou, les solutions "encloudées"
sont indiquées car elles permettent des montées en charge rapide. Mais
niveau prix, ce n'est pas la même
oui et comme précisé plus haut, je ne sais pas prévoir le moment où la grande charge arrivera contrairement à un site marchand qui peut prévoir une période de soldes, de promotion, etc
Hmm, dans ce cas, comme le disait Zapilou, les solutions "encloudées"
sont indiquées car elles permettent des montées en charge rapide. Mais
niveau prix, ce n'est pas la même
oui et comme précisé plus haut, je ne sais pas prévoir le moment où la
grande charge arrivera contrairement à un site marchand qui peut prévoir
une période de soldes, de promotion, etc
Il faut lire ma précision: vous pouvez dormir sur vos 2 oreilles,
GandiFlex peut augmenter lui-même sa puissance sur des déclenchements de
seuils (passage au-dessus d'une certaine valeur pour un paramètre
pendant un temps pré-déterminé), vous prévenir ensuite par
email/IRC/ICQ/... donc pas besoin de réellement "prévoir", sauf à ce que
le compte soit approvisionné
Quant au prix, je suis à peu près sûr que c'est bcp moins cher qu'un
dédié carrément surdimensionné en temps normal et malheureusement
sous-dimensionné en temps de crise, un dédié c'est forcément un
compromis. Si l'on factorise là-dedans le temps d'admin (sur 30 ans il
va falloir migrer ce dédié combien de fois ... sans parler du fait que
le cloud vous isole des pbms matériels) ...
Les prix varient de 7,46 €HT/mois (1 coeur, 256mb RAM, 3go de DD) à 220
€HT/mois (12 coeurs, 16go de RAM, 1to de DD), tout est modulable
finement, ça me parait tout à fait dans la lignée des prix de dédiés ...
Je précise, je ne suis pas de chez Gandi, j'ai eu un Gandiflex que j'ai
abandonné pour des VPS, mais cela me semble vraiment adapté à votre besoin.
Quant au prix, je suis à peu près sûr que c'est bcp moins cher qu'un dédié carrément surdimensionné en temps normal et malheureusement sous-dimensionné en temps de crise, un dédié c'est forcément un compromis.
-> Tout est affaire de compromis finances/puissance, de goûts, et de ce que l'on fait tourner dessus
Si l'on factorise là-dedans le temps d'admin (sur 30 ans il va falloir migrer ce dédié combien de fois ...
-> Faire des projections en informatique sur une échelle de temps aussi grande me parait quelque peu sportif: les technos évoluent sacrément vite.
Ceci étant dit, je ne crache pas dans la soupe, l'option gandi flex ou équivalent peut être séduisante pour ce genre de cas, même si in fine, elle saturera également au bout d'un moment. Visiblement, ils ont prévu le coup ceci dit: ils permettent de mettre en place un load balancer basé sur varnish qui fait du cache et envoie sur une ferme de serveurs derrière. Mais fatalement, ça augmente les coûts et la complexité de l'ensemble.
En passant, je n'ai pas idée des performances en matière d'I/O de leurs solutions. S'il y a un filer derrière, elles peuvent sacrément varier selon la charge des vm qui tapent dessus. Avant d'arrêter un choix, il faut à mon avis bien jouer du bench ...
bingo, on a eu plus de 200 commentaires sur les 24 heures dont une centaine dans le premier quart d'heure au moment même où des milliers d'internautes visualisaient les pages. C'est sans doute cela qui a provoqué la forte charge machine en invalidant le cache à chaque commentaire.
Hmmm, je crains que ce ne soit qu'un élément parmi d'autres. Lors d'un coup de chaud de ce type, j'aime bien sous linux faire appel à la commande 'dstat': ça permet d'avoir au vol un état complet de la machine. C'est pratique pour trouver les goulets d’étrangement en temps réel.
A plus grosse échelle de temps, il est également intéressant de mettre en place un système de collecte de données sur la santé de l'hôte et de "grapher" les données collectées. Un graphe représentant la charge système, un pour le cpu, un pour la ram et un pour les hits apache par exemple. En mettant tout en parallèle, on peut ainsi voir ce qui sature en premier.
Autre point intéressant dans ce genre de cas: avoir un domaine pour le
dynamique servi par du apache ( si nécessaire ), et avoir un domaine
pour le statique ( images, docs, css, js ) avec un serveur léger genre
nginx qui dépote bien. C'est pas la panacée, mais ça limite le nombre de
process apache joufflus sollicités par secondes.
Bonne idée, je vais investiguer cette solution.
Deux options pour cela: soit avoir un nginx sur le port 80 qui sers les requêtes sur le domaine statique et fait proxy vers apache situé sur un autre port pour le domaine principal. Soit avoir deux ip et un serveur sur chaque.
