Cet article sera utile aux personnes qui ont déjà leur propre site ou qui prévoient de l'ouvrir. L'article sera particulièrement intéressant pour les webmasters ambitieux qui estiment que la meilleure heure de leur projet approche à grands pas et veulent se préparer à l'afflux de visiteurs.
Même ceux qui ne rêvent encore que de milliers d'utilisateurs sur leur site se sont probablement demandé: "Combien d'utilisateurs mon site représentera-t-il s'ils se connectent en même temps?" Je me souviens immédiatement de l'expression bien connue «Habraeffect» - le phénomène de défaillance du site, qui s'est avéré non prêt pour de nombreuses conversions vers celui-ci après l'apparition du lien sur Internet.
Supposons que le site existe déjà (ou le sera bientôt): où peut-il être localisé? Doit-il s'agir d'un hébergement classique ou d'un serveur vps? Si vps, lequel et comment est-il préférable de le configurer? Ou peut-être qu'il n'y a aucune différence et qu'il est plus facile de choisir ce qui est le moins cher? Dans cet article, nous considérerons plusieurs options et en pratique nous assurerons laquelle est la meilleure pour notre site.
Nous allons expérimenter: définir différents modes de fonctionnement du serveur et mesurer les performances. Nous simulerons la charge sur le site en utilisant le service Loaddy.com. Vous pouvez y définir le nombre d'utilisateurs, le type de charge croissant et le graphique montrera comment le serveur y répond. On pense qu'un utilisateur génère environ une demande sur le site en 10 secondes. En tant que site de test, prenez une boutique de démonstration en ligne sur cms moguta. Il sera rempli de «biens» de test qui seront affichés sur la page principale selon plusieurs critères (c'est-à-dire, lorsque la page est en cours de création, le travail est en cours avec la base de données, etc.). D'une manière ou d'une autre, cela vous permettra de comparer les modes entre eux.
En tant que site de test, nous allons créer un serveur VPS sur Ubuntu. Sa configuration sera [1 cœur, 1 Go de RAM]. Nous supposons que ce sont précisément ces serveurs d'entrée de gamme qui sont créés dans la plupart des cas pour de nouveaux projets. La version test de la boutique en ligne sera disponible à l'adresse IP
http://130.193.44.219/L'hébergement classique est également utile, pour lequel nous remplirons également la même boutique en ligne pour effectuer des tests. Vous pouvez suivre notre propre chemin et effectuer les mêmes tests sur votre projet!
Étant donné que dans la plupart des cas, avec vps, un panneau de contrôle est proposé, nous apporterons les principales modifications aux paramètres qu'il contient. Sur le serveur vps, nous avons 3 modes de fonctionnement:
- Apache
- Apache en mode CGI;
- Nginx + php-fpm (sans Apache).
Mais d'abord, testons l'hébergement:
Hébergement classique à faible coût
Le résultat est disponible
ici .
Des erreurs apparaissent lorsque le nombre de visiteurs dépasse 50 personnes. L'hébergement cesse de donner du contenu, cependant, si vous allez dans le panneau de contrôle d'hébergement, nous pouvons voir quelque chose comme ceci:
Votre site a été soumis à des restrictions au cours des dernières 24 heures. Les ressources du processeur étaient limitées pour votre site. Vous avez atteint les limites des processus d'entrée (le nombre de scripts PHP et CGI exécutés simultanément, les tâches planifiées et les sessions de console) 126 fois.
Eh bien, bien sûr, l'hébergement c'est de l'hébergement, d'autant plus bon marché. Vous pouvez bien sûr trouver un tarif qui offrira plus d'options, mais vous devez tenir compte de tout cela, trouver en quelque sorte les données exactes des restrictions et de chaque fournisseur d'hébergement.
VPS: Apache
Le prochain en ligne est notre test Air Force avec le mode Apache, qui est d'ailleurs proposé par défaut lors de l'installation du panneau de contrôle ISP.
Le résultat est disponible
ici .
Les problèmes commencent lorsque le nombre d'utilisateurs dépasse 90. Si nous allons sur notre serveur via ssh et regardons ce moment sur la liste des processus utilisant la commande top, triés en utilisant Shift + M (selon la quantité de mémoire consommée), nous verrons quelque chose comme ceci:
Nous voyons que le processus apache2 est devenu de nombreuses filiales et ils ont mangé toute la RAM de notre serveur vps.
Ici, vous devez faire une petite remarque. Le fait est qu'il existe théoriquement un mode pour le serveur Apache qui permet à la place de ce grand nombre de processus enfants pour chaque connexion de créer plusieurs soi-disant multi-threads, chacun servant à plusieurs connexions. Ce mode est appelé
travailleur , contrairement à la
pré-fourche par défaut. Mais ce n'est pas facile à installer, il est impossible de le faire dans des panneaux comme ISP, et si vous êtes perplexe et essayez de le faire via ssh, il s'avère que désactiver la préfork et activer le travailleur ne suffit pas, vous avez toujours besoin d'une version thread-safe de php. Et si des modules comme Zend ou IonCube sont utilisés, ils doivent également être thread-safe. Quoi qu'il en soit, le site officiel PHP
ne recommande pas de définir ce mode.
VPS: CGI
Voyons ce qui se passe lors de l'utilisation du mode CGI. Pour ce faire, vous devez autoriser l'utilisation de PHP en mode CGI dans le panneau de configuration du FAI, cela se fait dans la section "Comptes - Utilisateurs - Paramètres pour l'utilisateur".
Le résultat est disponible
ici .
Une image sombre s'est avérée. Le serveur refuse de distribuer du contenu déjà avec plus de 55 visiteurs, la RAM est entièrement consommée par les processus «php». Vient ensuite une tentative de restauration de la fonctionnalité, mais elle se termine toujours par un échec de presque 100%.
VPS: Nginx + PHP-FPM
Le temps est venu pour un mode dans lequel le serveur Apache n'est pas du tout utilisé, Nginx fonctionne à la place et php est traité par le module php-fpm. Si vous utilisez le panneau de configuration du FAI, vous devez activer ce mode pour l'utilisateur. Cela se fait également dans la section "Comptes - Utilisateurs - Paramètres utilisateur". De plus, ce mode doit être disponible dans la section "Paramètres - Fonctionnalités - Serveur Web (www)".
Le résultat est disponible
ici .
Ce dont vous avez besoin! Disponibilité à 100%, tandis que la vitesse de téléchargement et le temps de réponse du serveur sont à des niveaux acceptables, bien qu'ils augmentent avec l'augmentation de la charge. Néanmoins, le serveur fait face!
Regardons la table des processus au moment de la charge maximale sur le serveur:
Nous voyons que nous avons encore un approvisionnement de RAM disponible. Et les processus enfants php-fpm7.0 ne se développent pas en grand nombre, mais sont limités à 5 instances, chacune servant à plusieurs threads.
Eh bien, il semble qu'un "mode gagnant" soit défini. Voyons combien de visiteurs simultanés notre serveur peut servir dans ce mode. Mais avant cela, nous faisons un peu de «tuning». Tout d'abord, comme apache n'est pas utilisé pour une telle opération sur le serveur, il peut être complètement désactivé. Nous le ferons dans le panneau de contrôle du FAI dans la section "Système - Services". Deuxièmement, nous modifions un peu le principe de démarrage des processus php-fpm. Par défaut, il est dynamique. Cela signifie que les processus enfants resteront en mémoire même lorsqu'ils ne sont pas nécessaires. En même temps, la mémoire n'est pas libérée et, avec le temps, ces processus peuvent croître plus que nous le souhaiterions. Par conséquent, il est proposé de définir le mode «à la demande» - sur demande. Et définissez le nombre de processus enfants et le délai d'expiration pour eux.
Pour ce faire, vous devrez vous rendre sur le serveur via ssh et enregistrer ces paramètres dans le fichier de configuration php. Ceci est commodément fait dans le fichier pour l'utilisateur pour lequel le domaine a été créé dans ISP.
Il se trouve généralement dans /etc/php/7.0/fpm/pool.d
Donc:
sudo nano /etc/php/7.0/fpm/pool.d/www-root.conf
On y voit par défaut les paramètres suivants:
[www-root] pm = dynamic pm.start_servers = 1 pm.min_spare_servers = 1 pm.max_children = 5 pm.max_spare_servers = 5
Pour activer le mode sur demande, vous devez le remplacer par:
pm = ondemand pm.max_children = 5 pm.process_idle_timeout = 10s
Et redémarrez php-fpm avec la commande
sudo service php7.0-fpm restart
Après cela, les processus php-fpm7.0 seront créés à la demande (s'il y a une charge), leur nombre maximum sera = 5, et après 10 secondes d'arrêt, le processus sera tué, libérant de la RAM.
Au cas où, nous relancerons notre test pour nous assurer que toute cette activité amateur n'a pas affecté les performances du site Web:
Le résultat est disponible
ici .
Maintenant, exécutons Loaddy avec beaucoup de visiteurs pour comprendre combien de connexions notre serveur peut gérer:
Le résultat est disponible
ici .
La bonne nouvelle est que toutes les demandes ont été traitées, bien qu'avec un retard important, avec un grand nombre de demandes par seconde. Le temps de réponse du serveur approche 10 secondes avec un nombre de hits de 190+. Mais rappelons le graphique du mode Apache, où nous avons déjà reçu 4 secondes de réponse du serveur avec plus de 80 utilisateurs, tandis qu'en mode php-fpm, des décalages similaires sont observés avec 130 requêtes que nous avons spécialement allouées curseur sur le graphique ci-dessus.
Mais c'est le même VPS.
Tableau des principaux processus à la fin du test (avec 200 utilisateurs):
Notez qu'après le test, la mémoire utilisée par pfp-fpm est libérée:
Notre serveur est donc prêt pour de nouvelles charges.
Il faut se rappeler que le site fonctionne en mode nginx + php-fpm, ce qui signifie que apache2 n'est pas utilisé dans le travail et, par conséquent, .htaccess n'est pas utilisé. Cela peut ne pas sembler pratique, mais c'est l'option la plus rapide possible, et les moteurs de recherche classent mieux les sites qui fonctionnent rapidement.
Conclusion
En conclusion, un autre petit point: si vous avez configuré tout sur le serveur que vous vouliez et avez décidé de déconnecter le panneau de contrôle du FAI, ou si vous n'avez plus de licence pour celui-ci, veuillez noter que le processus «de base» de celui-ci restera suspendu sur votre serveur. Après des mois, il peut se développer, il est donc préférable de le «tuer» et de le supprimer du démarrage et de crona.
Si vous souhaitez tester indépendamment le site à l'aide de Loaddy ou d'autres méthodes, il est disponible à l'
adresse http://130.193.44.219/