Le serveur répond à la demande différemment
Je crois que comme ci-dessus hébergé localement, le long délai vert est en fait la page d'accueil du site. Puis-je savoir ce qui cause ces retards? Magento est un monstre très gourmand en ressources processeur, est-ce dû au fait qu’il attend que le serveur réponde en raison d’un manque de puissance du processeur?
Avant d’étudier le fonctionnement du serveur, j’avais déjà chargé des tests sur différents sites Web, car j’étais novice en matière d’hébergement et d’optimisation de serveurs. Personnellement, j’utilise Amazon et j’ai bien conscience qu’Amazon a ses limites, j’ai testé mon stress test sur serveur et il réagirait en 0,5 seconde avec 30 utilisateurs simultanés, Micro instance, Apache, Varnish, Js et img compressés, des images provenant de S3 (CDN) et le temps de chargement ne prend que 0,5 seconde à 1 minute! au 31ème utilisateur simultané. Pourquoi le tournage a-t-il lieu? Il semble que cela ne peut pas prendre les utilisateurs quand c'est stressé.
Alors que l’autre site que j’ai testé, l’image ci-dessus en est un exemple. Peu importe le stress qu’elle subit, le temps de chargement de 20-50 + utilisateurs est de 1 min (connexion étrangère), j’ai testé ses 30 secondes au niveau local.
J'ai aussi consulté d'autres sites Web, certains sont hébergés sur l'hébergement de partage, et ils sont capables de supporter le stress et de fonctionner lorsqu'ils sont surchargés. Il réagit en 1 minute, pour mon cas, Amazon, il peut même atteindre 3 à 4 minutes quand il est stressé.
Puis-je savoir comment puis-je avoir ce "temps de chargement maximum, quel que soit le stress, pas de question, mais dans une plus large mesure" Que devrais-je regarder? * PS si j'augmente mon instance Micro en Petite instance, cela ne peut prendre que 10 utilisateurs simultanés supplémentaires, ce qui n'est pas une grande différence, mais quand il s'agit de coûter cher, c'est vraiment une différence énorme.
Toute autre connaissance serait totalement appréciable, je suis ici pour apprendre et aider à l’avenir. Merci pour cette plateforme.
Cordialement, Jonathan
Le délai avant le premier octet est déterminé par le temps nécessaire à l'application pour renvoyer des informations. Vous auriez besoin de fournir plus d'informations sur le système que vous utilisez pour les détails, mais je regarderais d'abord la configuration de l'application plutôt que l'hébergement pour l'optimisation.
Par exemple, Magento peut être une application très "lourde" sans mise en cache. Le temps nécessaire pour charger toutes les pages et exécuter les requêtes associées peut entraîner une très longue réponse Time to First Byte. De même, une installation très complexe de Wordpress peut prendre un certain temps pour s'exécuter et renvoyer l'octet de la première page.
Recherchez des efficacités et des optimisations dans le code si cela est possible et explorez également une solution de mise en cache appropriée pour votre application.
Un test utile consiste à télécharger un fichier HTML très simple et à vérifier le délai jusqu'au premier octet.
Cette longue attente initiale a probablement lieu pendant que le serveur interroge une base de données et prépare sa réponse. La page demandée est donc dynamiquement créée pour chaque demande.
Les requêtes suivantes concernent des fichiers statiques JavaScript et CSS. La réponse est beaucoup plus rapide car tout ce que le serveur Web doit faire est de rechercher ces fichiers et de les envoyer. Aucun traitement n'est requis. Et comme ces fichiers sont probablement souvent demandés, ils se trouvent probablement déjà dans la mémoire cache du serveur, ce qui accélère encore le temps de réponse.
Vous ne pouvez simplement pas comparer les deux en termes de temps de réponse. Le contenu statique ne nécessite que de la bande passante et éventuellement une recherche de disque. Le contenu dynamique peut également nécessiter des requêtes de base de données coûteuses et des calculs complexes.
Le problème est que vous utilisez une instance t1.Micro. Ces instances ne sont pas conçues pour une charge importante. Ils sont conçus pour de courtes rafales, mais normalement des instances inactives. Pour vous donner une idée, ces serveurs ont 2 ECU d'énergie en rafale. Si cette rafale est maintenue pendant 1 minute, les ressources de vos serveurs sont limitées et vous n'utilisez pratiquement pas de ressources processeur. Je recommande de ne pas utiliser ces serveurs pour autre chose que des idées de prototypage. Pour plus d'informations sur les micro-instances, voir this cet article d'Amazon.
Les performances d'une petite instance ne disposent que de 1 ECU de puissance, raison pour laquelle vous ne voyez qu'une légère différence dans le nombre d'utilisateurs que vous pouvez gérer. Pour être honnête, il semblerait que vous deviez passer plus de temps à essayer d’améliorer les performances de votre application au lieu de la placer simplement sur un serveur plus puissant. Amazon n'est pas limité en termes de puissance de calcul, mais il est parfois plus coûteux si tout ce que vous voulez faire est d'héberger un simple serveur Web.