Et surtout prendre en compte le fait qu'il nous faut un vrai backup.
Qu'entends-tu exactement par là ?
ça peut nous revenir moins chère de prendre une offre groupée Hebergement + Backup chez le même fournisseur plutôt que de prendre les deux séparément.
Ah, pour l'espace de stockage, pas pour la solution elle-même.
Si tu vas chez Dédibox, y'a par défaut 100 Go offerts avec tout serveur physique. Pour les autres, je ne sais pas.
Pour Kimsufi, il n'y a plus de backup comme l'on a chez Online.
A noter (comme je l'ai dit dans le sujet sur le backup), qu'il n'y a pas besoin d'organiser une AG pour faire un achat, surtout si cela devient urgent (le temps de trouver une date, de respecter le délai de 15 jours). A la limite, une réunion de CA est moins lourde à organiser. Après, si vous voulez en faire une, pas de soucis, mais il faut prendre le délais en compte 
Je ne crois pas que le sujet soit assez urgent pour devoir migrer dans le mois qui suit et on dispose déjà d'un backup local. Donc pour moi on a pas besoin d'être en situation d'urgence.
L'erreur serait de se précipiter et de faire des mauvais choix. Raison pour laquelle je pense que si quelqu'un est motivé, faire un beau tableau comparatif des offres du marché. Une fois que ça sera fait, la solution apparaitra toute seule devant nos yeux.
Petite mise à jour. Version : v1.4b/cc11366
url : http://zestedesavoir.com/
Temps de chargement coté back-end : 0.942 sec
url : http://zestedesavoir.com/forums/
Temps de chargement coté back-end : 2.988 sec
url : http://zestedesavoir.com/forums/communaute/bug-suggestions/
Temps de chargement coté back-end: 3.256 sec
url : http://zestedesavoir.com/forums/sujet/273/les-petits-pixels/?page=3
Temps de chargement coté back-end : 3.528 sec
url : http://zestedesavoir.com/tutoriels/433/debuter-sur-adobe-photoshop/
Temps de chargement coté back-end : 1.397 sec
url : http://zestedesavoir.com/tutoriels/229/la-3d-pour-le-jeu-video-avec-blender/
Temps de chargement coté back-end: 2.021 sec
url : http://zestedesavoir.com/articles/57/ouverture-officielle-de-zeste-de-savoir/
Temps de chargement coté back-end : 2.887 sec
PS : ces stats on été réalisés à 16h 10
ça n'a pas l'air de s'améliorer et la perte de performance me semble être due a l'augmentation d'utilisateurs.
Oui, enfin des chiffres comme ça sans aucun contexte, ça ne veut strictement rien dire.
Je ne nie pas qu'on a des améliorations à faire et des questions à se poser niveau perfs ; mais ce genre de stats ne sert strictement à rien, parce qu'elles ne prouvent rien et ne permettent de tirer aucune conclusion fiable.
Un analyse des stats Munin serait déjà plus pertinente.
Mon contexte (assez flou je l'accorde) c'est l'après midi.
Ce que montre les stats c'est juste que le serveur met de 1 à 3 secondes à répondre à une requête http. ce n'est certes pas précis, mais ça permet de poser un chiffre sur un sentiment de lenteur.
Quand "un topic" s'affiche en plus de 3 secondes (ce qui n'est pas mon ressenti), est-ce par engorgement côté IO, par un nombre de requêtes trop important, par un temps de calcul trop important?
C'est vrai que les stats munin ont l'intérêt de présenter dans un graphe ce qui est vraiment problématique et quelles sont les pages qui engorgent.
Quand "un topic" s'affiche en plus de 3 secondes (ce qui n'est pas mon ressenti), est-ce par engorgement côté IO, par un nombre de requêtes trop important, par un temps de calcul trop important?
Aucune idée, tout ce que je sais, c'est que le serveur prend souvent 3 secondes à me répondre sur un topic et ça peut dépendre de pleins de facteur. Je ne sait pas lire les données munin et donc j'aurai du mal à les consolider. mais s'il y'a des gens plus calé dans la salle qui arrivent à l'expliquer, ça serait top
Mon contexte (assez flou je l'accorde) c'est l'après midi.
Non mais ça ne sert quand même à rien.
Étais-tu connecté ?
Quelle était la charge serveur à ce moment là (peut-être que tu tombes pendant une attaque sans le savoir) ?
Qu'est-ce que tu considères comme "page chargée" ?
Où le temps est-il passé, si tu mesures autre chose que le temps de réaction du serveur (entre l'envoi de la requête et la réception du 1er octet) ?
Les exemples choisis sont-ils représentatifs ?
Les chiffres obtenus sont-ils reproductibles ?
Avec quelle variabilité ?
Sans toutes ces informations, tes chiffres ne servent à rien parce qu'il n'est pas possible de les interpréter et encore moins d'en tirer des conclusions comme "la perte de performance me semble être due a l'augmentation d'utilisateurs".
Vraiment firm1, j'apprécie que tu t'inquiètes des performances ; mais là tu perds ton temps (et celui de ceux qui répondent).
Edit : par exemple selon les graphes Munin, tu es tombé en plein dans un pic de lag de la BDD. Enfin, je pense, parce que sans vraies stats disque, c'est dur à dire.
Ajoute au fait que toutes la journée d'hier, notre hébergeur a décidé que le cache disque ça ne servait à rien, et qu'on avait des IOwait débiles toutes la journée…
SpaceFox : Peut-être qu'il serait intéressant de documenter toute cette manipulation pour pouvoir récupérer des statistiques avec un contexte à chaque fois et éviter aux autres de perdre du temps pour ça (ici firm1). Je ne sais pas si c'est possible mais si en plus, on peut récupérer ça de manière automatique, ça serait top.
Bah le plus simple pour les corrélations, ce serait peut-être un module qui ajoute ces URLs fonctionnelles aux stats Munin. À voir si c'est simple à faire et si ça ne parasite pas trop les autres stats.
PS : je vais essayer de mettre ça en place : https://github.com/munin-monitoring/contrib/blob/master/plugins/apache/http-response-times
@firm1, tu penses que ton set d'URLs est représentatif ?
Étais-tu connecté ? Quelle était la charge serveur à ce moment là (peut-être que tu tombes pendant une attaque sans le savoir) ? Qu'est-ce que tu considères comme "page chargée" ? Où le temps est-il passé, si tu mesures autre chose que le temps de réaction du serveur (entre l'envoi de la requête et la réception du 1er octet) ? Les exemples choisis sont-ils représentatifs ? Les chiffres obtenus sont-ils reproductibles ? Avec quelle variabilité ?
Normalement le premier post de ce topic l'explique plus ou moins. Les chiffres sont relevés en étant connecté. Ceux que je viens de posté on été pris à 16h 10 (j'avais l'impression depuis quelques jours que le site est devenu lent).
Quand je marque "temps de chargement coté back-end" c'est le nombre de secondes entre le moment ou le serveur reçoit la requête http et le moment ou il répond (premier octet envoyé). En gros ça prend en compte uniquement les performances coté back end.
Des exemples représentatif ? Je prend un exemple de topic, de big tuto, de mini tuto, etc. J'ignore s'il sont représentatif, mais ce sont les même que je prend à chaque fois, donc ça donne une idée au fil des versions.
Les chiffres ne sont pas reproductible au poil de cul, mais le temps de chargement d'une page, malgré plusieurs essais ne descend jamais en dessous de 2.9 sec.
Vraiment firm1, j'apprécie que tu t'inquiètes des performances ; mais là tu perds ton temps (et celui de ceux qui répondent).
Considère ça comme une façon de dire, ça fait longtemps que je viens sur ZdS, et j'ai l'impression que depuis quelques semaines, ça a ralenti. 
Mais en attendant qu'on ait ces stats de manière automatique dans munin, voilà les seuls infos dont je dispose pour étayer mon sentiment.
La surveillance est mise en place sur les URLs données par firm1, à l'aide de ce plugin : https://github.com/munin-monitoring/contrib/blob/master/plugins/http/wget_page
A noter que donc ça prends en compte le chargement des pages sans les ressources, en local, et en mode déconnecté.
PS : y'a pas en préprod à cause du contrôle d'accès (la flemme de voir si on peut passer outre).
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
