Salut
J'aimerais savoir comment et ou on gères l'affluence du site en fonction des visites massives. A quel moment ça peux arriver que le site "rame" et qu'est ce qui px le faire ramer (poids des pages, visites trop nombreuses ?)
Cordialement,
Salut
J'aimerais savoir comment et ou on gères l'affluence du site en fonction des visites massives. A quel moment ça peux arriver que le site "rame" et qu'est ce qui px le faire ramer (poids des pages, visites trop nombreuses ?)
Cordialement,
Généralement c'est :
- Le manque de ram qui fait swapper le serveur sur le disque, la c'est la catastrophe assurée.
- Saturation CPU, les scripts dynamiques (PHP, ASP, Java) consoment énormément de CPU. Exemple scripts de forums, portails, etc...
- Saturation process SGBD, une variante des points précédents, c'est que le SGBD n'à pas assez de ram pour travailler, ou les tables ne sont pas optimisées (pas bien indéxés par exemple), en cas de charge lourde trop de process SGBD sont générés qui vont étouffer le serveur.
- Pour saturer la bande passante c'est presque impossible, ou il faut avoir un site multimédia (vidéos par exemple).
D'accord , merci
Mais sinon au point du vue "logiciel" ou "conception" du site , il ne peux pas avoir d'incidence sur ce point ?
Ca vient surtout au niveau matériel du serveur si j'ai bien compris (RAM,CPU,...)
Dans le cadre d'un Intranet très optimisé , le débit réseau (généralement 100Mbit/s) peux avoir une incidence ?
Il y a t'il un logiciel qui permet de savoir quelle configuration permettra la navigation maximale sur le site sans "ramer" ? ou en général un bon processeur de serveur et 512 mb de ram suffit ?
PS : il n'y a pas de gestion de vidéos , ni autre chose de ce genre.
Dans le cas de certains hébergeurs, la bande passante est limitée et donc l'accès au site peut être excessivement ralenti dans des cas de grosse affluence (cas vécu sans vidéo ni multimedia) à cause de l'étranglement au niveau de cette bande passante. Ceci arrive bien sûr plus facilement encore sur des hébergements mutualisés.Envoyé par Marc Lussac
- Au niveau conception du site, certains scripts mal écrits peuvent également rlentir le site voir le bloquer si le timeout n'a pas été augmenté.
Ca ca soit dépendre des hébergeurs, mais pas exemple un script forum ou portail aura tendance à consomer beaucoup de CPU et donc à dépasser les limites de consomations imposées par l'hébergeur dans le cas d'un mutualisé ou la capacité dans le cas d'un dédié, et la bande passante restera très majoritairement sous utilisée.
Si tu es arrivé à dépasser la bande passante d'un hébergeur sans contenu massivement multimédia ou fichier lourd, c'est que l'hébergement qui t'à été proposé est vraiment très très limité en bande passante...
Pour te donner un exemple une application forum (donc texte majoritaire) va généralement saturer rapidement des capacités CPU mais consommer à peine 1% de la bande passante disponible...
Mais évidement chaque hébergeur propose des offres différentes en ce domaine...
Oui, bien sûr. Tout dépend de ce logiciel. Si tu n'as que des pages statiques HTML et que le serveur rame, le "seul" logiciel qui peut être responsable c'est le serveur Web, mais il y a très peu de chances que ce soit ça. Généralement, les performances du serveur web dépendent de la config hardware du serveur.Envoyé par Kenshin86
Si tu as un site dynamique (ASP, PHP, J2EE, etc.), c'est évident que cette partie dynamique a une influence. Par exemple, si tu fais des tonnes de calcul, ça va pédaler. Il est donc très important d'optimiser la conception et les développements d'un site dynamique.
Pas que ça : le besoin en ressource est essentiellement déterminé par le site dynamique. Forcément, si ton appli est très consommatrice en CPU, ajouter des CPU réduira les pbs de perf, mais est-ce bien ce que tu cherches à faire ? Si tu optmises ton appli, elle pourra peut-être tourner plus vite sans ajouter de CPU.Envoyé par Kenshin86
A moins d'avoir énormément de téléchargements et une utilisation du réseau massive, non.Envoyé par Kenshin86
On ne peut absolument rien dire du style "forcément, 512 Mo de RAM c'est OK". Une fois de plus, ça dépend essentiellement de l'appli et des ressources dont elle a besoin.Envoyé par Kenshin86
Les logiciels dont tu parles existent : Load Runner (payant), JMeter (gratuit), OpenSTA (gratuit) et plein d'autres. Je ne sais plus si la famille de ces logiciels porte un nom mais en gros tu parles de faire des tests de performance ("bench" en anglais) et de montée en charge. C'est quelque chose qui doit logiquement être fait avant toute mise en production. Cela passe d'abord par l'évaluation de la charge cible de l'application (nombre d'utilisateurs connectés (authentifiés) et simultanés) et du comportement "standard" des utilisateurs (ce qu'ils font en prenant en compte les temps de lecture des infos, etc.). De là, tu en déduis un profile de charge ton application. Ensuite, tu paramètres ton logiciel de test pour simuler cette charge ainsi que le comportement attendu des utilisateurs. Ensuite, tu mets en place des traceurs/sniffeurs/analyseurs/sondes qui te permettent de mesurer les performances du réseau, du serveur (consommation mémoire, consommation CPU, utilisation disque, etc.) et de l'application (traces de performances). Enfin, tu lances le test. Dernier point : pour que le test soit concluant, il faut t'être fixé des valeurs acceptables de temps de réponse. Par exemple, tu vas dire "si la page met plus de 2 secondes pour s'afficher, c'est mort".
Non 500 Mo de de ram ca ne suffit pas forcément, ca dépend des logiciels qui tournent, si tu fait tourner oracle 500 Mo de ram ca ne suffira pas, ca va swapper à mort.
Et meme si tu utilises Mysql par exemple, tu peu vouloir mettre un paquet de ram pour avoir du cache RAM et accélérer les requetes SGBD.
Tu peu même décider si ta base est pas trop grosse d'avoir toute ta base de données en cache ram pour avoir les réponses aux réquetes quasi instantanémenent, c'est à dire pas d'accès disques, sauf pour les écritures (c'est qe qu'on fais nous sur le forum )
Eh oui, c'est pas facile, les performances d'une appli. Y a en qui en font leur métier, c'est pour dire !
D'accord.
Je vais regarder de plus près les logiciels de tests.
Merci a tous!
Tu as un fichier de paramétrage de MySQL, dans ce fichier tu lui alloue beaucoup de RAM, et il va utiliser cette RAM pour le cache en lecture.
Si le cache RAM est supérieur à la taille de base de données, toutes les lectures seront en RAM, et il fera des accès disques que pour les insertions et éditions.
Tu as même un écran de monitoring avec mySQL qui te donne des stats complète, le nombre de lecture en cache, etc...
Pour en savoir plus :
FAQ et tutoriels MySQL
Forum MySQL
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager