PHP

Workers PHP

Les workers PHP traitent le code PHP d’un site. Cela inclut la construction des pages, le traitement des tâches de fond, l’interrogation de la base de données, etc.

Les workers PHP sont comparables aux employés d’un magasin. Chaque employé ne peut traiter qu’une seule demande à la fois. S’il y a plus de clients que d’employés, ces clients (processus) doivent faire la queue et attendre que le prochain employé disponible traite leur demande.

Les workers PHP entrent réellement en jeu lorsqu’un site ne met pas ou ne peut pas mettre en cache la majeure partie de son contenu. Plus un site est dynamique, plus il aura besoin de workers PHP. Le contenu mis en cache ne nécessite pas de worker PHP ; ils ne sont vraiment nécessaires que lorsque le site doit interroger la base de données pour obtenir ou modifier des informations.

En ce qui concerne les performances de WordPress, un plus grand nombre de workers PHP ne signifie pas automatiquement de meilleures performances ; il y a un certain nombre de facteurs que vous devez prendre en compte :

• Mise en cache : une mise en cache efficace peut réduire la charge de travail des workers PHP en servant le contenu mis en cache au lieu de le générer dynamiquement pour chaque requête. Cela peut améliorer considérablement les performances, en particulier pour les ressources fréquemment consultées.
• Matériel : Les ressources matérielles disponibles sur le serveur, telles que le processeur, la mémoire (RAM) et la vitesse du disque, ont un impact direct sur les performances des workers PHP. Des ressources insuffisantes peuvent entrainer des temps de traitement plus lents et une dégradation des performances.
• Configuration du serveur web : La configuration du serveur web et son interaction avec PHP peuvent influencer les performances du programme.
• Vitesse de la base de données : Les applications PHP récupèrent fréquemment des données dans les bases de données MySQL pour générer des contenus dynamiques. La vitesse de récupération des données est influencée par la façon dont la base de données est organisée, par l’optimisation des requêtes et par les performances du serveur de base de données. Cela a un impact direct sur le fonctionnement des applications PHP.
• Version de PHP : Les nouvelles versions de PHP permettent souvent d’améliorer les performances du worker PHP grâce à des améliorations de performances, des corrections de bogues et des mises à jour de sécurité.

Chez Kinsta, nous accordons une grande importance à la performance de votre site. C’est pourquoi nous avons mis en place plusieurs technologies visant à maximiser les performances de PHP et à minimiser les requêtes PHP :

• Nous proposons une mise en cache des pages au niveau du CDN et du serveur, avec des règles personnalisables pour garantir une efficacité maximale du cache.
• Nous utilisons des serveurs premium chez GCP (machines virtuelles C2 et C3D) équipés des CPU les plus rapides de Google Cloud pour aider les workers PHP de votre site à fonctionner plus efficacement.
• Notre infrastructure évolutive garantit que les workers PHP de votre site WordPress disposent de suffisamment de ressources CPU pour fonctionner au maximum de leurs performances.
• Nous utilisons une infrastructure réseau de premier ordre sur Google Cloud Platform (GCP) pour minimiser la latence. En tirant parti du réseau premium de GCP, nous réduisons considérablement le temps nécessaire pour que les données voyagent entre les différents composants de notre infrastructure, y compris le serveur MySQL et les serveurs web.
• Nous fournissons un serveur MySQL hautement optimisé, hébergé localement, afin de réduire la latence du réseau et d’améliorer la vitesse de récupération et de traitement des données.
• Sur le serveur MySQL, nous disposons de tampons InnoDB pour améliorer les performances de la base de données en réduisant les opérations d’E/S sur disque. Les données sont accessibles plus rapidement à partir de la mémoire plutôt que du disque, ce qui améliore l’efficacité des opérations de lecture et d’écriture et les performances globales de la base de données MySQL.
• Nous veillons à ce que la dernière version de PHP soit toujours disponible afin d’intégrer toute amélioration des performances.

Workers PHP vs limite de mémoire PHP

Il ne faut pas confondre le nombre de workers PHP avec la limite de mémoire de PHP. Les workers PHP sont des processus PHP individuels qui traitent les requêtes web entrantes, tandis que la limite de mémoire PHP spécifie la quantité maximale de mémoire (RAM) qu’un script PHP unique peut utiliser pendant l’exécution.

Les workers PHP gèrent la concurrence en traitant plusieurs requêtes simultanément, tandis que la limite de mémoire PHP gère l’allocation des ressources en limitant l’utilisation de la mémoire par les scripts individuels. Cela permet d’éviter qu’un seul script n’utilise toute la mémoire disponible du serveur.

Les limites de mémoire de PHP sont importantes pour les scripts nécessitant beaucoup de mémoire, tels que ceux qui exécutent des requêtes de base de données volumineuses, qui gèrent des téléchargements de fichiers volumineux ou qui exécutent des calculs complexes. Si vous rencontrez des erreurs de limite de mémoire sur votre site, l’augmentation du nombre de workers PHP ne résoudra pas le problème. Vous devez plutôt vérifier votre limite de mémoire et, si nécessaire, l’augmenter ou acheter un module de limitation de la mémoire.

WordPress et les workers PHP

Une requête non mise en cache sur un site WordPress se déroule généralement de la manière suivante :

1. Un visiteur se rend sur une page ou effectue une action sur une page (par exemple, ajouter quelque chose à un panier, envoyer un formulaire, etc.)
2. Le serveur web (Nginx chez Kinsta) reçoit cette requête.
3. Nginx transmet la requête à PHP.
4. PHP interroge la base de données MySQL et obtient les informations dont il a besoin ou effectue les mises à jour nécessaires.
5. PHP utilise ensuite les fichiers PHP de votre thème (et les fichiers des extensions le cas échéant) pour générer une page HTML.
6. PHP renvoie la page HTML rendue au serveur web.
7. La page est servie au visiteur.

Dans le processus décrit ci-dessus, l’étape 4 est celle qui demande le plus de temps et de ressources (CPU et RAM). Un site bien optimisé, avec un code PHP et des requêtes de base de données efficaces, traitera cette étape assez rapidement.

En revanche, un code PHP mal écrit ou non optimisé et/ou un grand nombre de requêtes de base de données inefficaces prendront beaucoup plus de temps pour franchir l’étape 4. Les requêtes qui prennent plus de temps à traiter monopolisent les workers PHP pendant plus longtemps.

Estimation du nombre de workers PHP nécessaires

Le nombre de workers nécessaires à un site dépend de plusieurs facteurs, tels que : la dynamique du site, l’optimisation du code du site (rapidité de traitement des requêtes) et le type de trafic que reçoit le site. Un site optimisé traite les requêtes rapidement, libérant ainsi des workers PHP pour la requête suivante dans la file d’attente.

Les sites dynamiques tels que les boutiques de commerce électronique, les forums, les sites d’apprentissage et les sites d’adhésion ont généralement besoin de plus der workers PHP que les sites statiques de type brochure. De même, plus un site est fréquenté, plus il aura besoin de workers PHP.

Plans Kinsta et workers PHP

Le tableau suivant montre combien de workers PHP sont inclus dans chaque plan chez Kinsta :

Nous proposons également des plans personnalisés dans lesquels vous pouvez indiquer le nombre de workers PHP dont vous avez besoin. Pour plus d’informations, contactez notre équipe commerciale.

Workers PHP, CPU et RAM

Lors de l’ajout de workers PHP, les ressources CPU et RAM doivent être prises en compte. Si vous augmentez le nombre de workers PHP, mais que le serveur a besoin de plus de CPU et de RAM pour supporter ces workers, cela créera un goulot d’étranglement car les requêtes ne seront pas traitées efficacement.

Chez Kinsta, nos conteneurs LXD personnalisés sont configurés avec beaucoup de ressources CPU et RAM. De plus, en utilisant des machines virtuelles C2 et C3D optimisées pour le calcul et équipées des CPU les plus rapides de Google Cloud, nous aidons les workers PHP de votre site à fonctionner plus efficacement. Notre infrastructure évolutive garantit que les workers PHP de votre site WordPress disposent de suffisamment de ressources CPU pour fonctionner de manière optimale.

Identifier les problèmes de performance liés aux workers PHP

Si trop de requêtes s’empilent dans la file d’attente en raison d’un afflux important de requêtes, de processus de longue durée ou d’une combinaison des deux, le site peut rencontrer des problèmes de performance qui peuvent se traduire par des erreurs 502 ou 504.

L’utilisation d’outils tels que l’outil APM de Kinsta et l’extension Query Monitor peut vous aider à identifier les problèmes de performance et les requêtes lentes. Nous vous recommandons également de travailler avec un expert en performance qualifié pour diagnostiquer les problèmes.

Limite du nombre de workers PHP

Vous pouvez accéder au tableau de la limite de worker PHP dans MyKinsta > Sites WordPress > nom du site > Analyses > Performance > Limite de worker PHP. Si un worker PHP n’a rien à faire pendant 10 secondes continues, le processus du worker PHP se terminera automatiquement. Dès qu’il est à nouveau nécessaire, le processus de worker sera recréé instantanément. Ce graphique vous montre combien de fois le nombre maximum de workers alloués a été atteint sur votre site.

Par exemple, si vous avez un plan Business 1, vous avez droit à un maximum de 4 processus PHP. Si 3 processus PHP sont en cours d’utilisation et qu’une autre requête est faite sur votre site qui nécessite un processus PHP, lorsque le processus PHP est créé, il atteint le nombre maximum de 4 processus PHP et est enregistré comme un incident où la limite de processus PHP est atteinte.

Cela ne vous donne qu’une image partielle de l’activité de vos workers PHP, car cela n’enregistre que le nombre de fois où la limite de workers PHP est atteinte et non la durée d’utilisation de tous les workers PHP.

Par exemple, si votre site connaît une forte augmentation de trafic, tous les workers PHP peuvent rester occupés pendant une heure entière, sans aucun temps mort, et ne se terminent donc pas du tout pendant cette heure. La limite de workers PHP n’est alors atteinte qu’une seule fois, et il peut sembler que les workers PHP n’ont pas été occupés pendant cette heure, alors qu’en fait, ils étaient tous actifs pendant toute la durée de l’heure. Au bout de 30 minutes, si le trafic diminue et qu’un worker PHP reste inactif pendant 10 secondes, il s’arrête automatiquement. Toutefois, si le worker PHP est à nouveau sollicité dans une minute, le nombre maximal de workers PHP sera à nouveau atteint, ce qui entrainera l’enregistrement d’une autre limite de workers PHP.

Si vous étudiez les performances d’un site web et déterminez si votre site utilise continuellement ses workers PHP, vous pouvez surveiller l’activité des workers PHP à l’aide d’outils dans une session SSH. Par exemple, la commande personnalisée suivante permet de surveiller le nombre de serveurs PHP actifs toutes les 0,3 secondes :

watch -n 0.3 "ps aux | awk '$(NF-2) ~ /php-fpm/ && $(NF-1) ~ /pool/ && $8 ~ /R/ { print $0 }' | wc -l"

Pour quitter cette commande, appuyez sur CMD + C ou CTRL + C, puis relâchez les deux touches.

Analyse du cache

La section d’analyse du cache dans MyKinsta cache analytics peut être utilisée pour voir le nombre total de requêtes en cache de votre site et les principaux contournements de cache.

Réduisez et optimisez l’utilisation du worker PHP

Mise en cache

La mise en cache est votre meilleur ami lorsqu’il s’agit d’optimiser votre site et de réduire le nombre de workers PHP nécessaires. Rappelez-vous que les workers PHP ne sont pas nécessaires pour le contenu mis en cache, donc mettez en cache tout ce que vous pouvez.

Mise en cache des pages

Chez Kinsta, nous nous occupons de la mise en cache des pages pour vous ; tous les sites utilisent le module de cache FastCGI de Nginx pour des performances ultra-rapides.

Mise en cache d’objets

L’ajout d’un cache d’objet persistant comme Redis devant votre base de données peut augmenter les performances et réduire le besoin de workers PHP. Sans cache d’objets, les requêtes de la base de données MySQL sont exécutées à chaque requête, même s’il s’agit de la même requête et des mêmes résultats.

Redis stocke les résultats des requêtes de base de données dans la mémoire vive, de sorte que PHP puisse récupérer ces résultats sans avoir à exécuter à nouveau la requête. La suppression des requêtes répétitives sur la base de données permet aux workers PHP d’économiser les ressources et de répondre aux requêtes plus efficacement.

Consultez nos modules premium pour en savoir plus sur l’ajout du cache Redis à votre site.

Optimisation du code

Assurez-vous que le code de votre site est optimisé afin qu’il soit le plus efficace possible. Cela s’applique au code personnalisé, au code du thème et au code du plugin. En cas de doute, nous vous recommandons de demander à un développeur d’examiner le code de votre site.

Code personnalisé

Si votre site web contient des extraits de code personnalisé dans des extensions ou dans votre thème, assurez-vous qu’ils sont vraiment nécessaires et bien écrits.

Plugins

Examinez attentivement les extensions utilisées sur votre site et assurez-vous qu’ils sont vraiment nécessaires, qu’ils ne font pas double emploi et qu’ils constituent la meilleure option pour le besoin auquel ils répondent. Si certaines extenbsions ne sont pas compatibles avec la dernière version de WordPress et de PHP, il est peut-être temps d’envisager d’autres options. Si vous avez des plugins sur votre site qui ne sont pas utilisés, il est recommandé de les supprimer.

Thème

Utilisez un thème léger et performant. Évitez les thèmes qui contiennent des fonctionnalités qu’il est préférable de mettre en œuvre à l’aide d’extensions distinctes (par exemple, le référencement, le filtrage des recherches, les champs personnalisés, les diaporamas d’images, etc.) ou qui ne sont pas nécessaires pour votre site.

Mettez PHP à jour

Utilisez la dernière version de PHP pour des performances plus rapides. Les benchmarks PHP montrent que chaque version de PHP est plus rapide que la précédente.

Activez le CDN de Kinsta

L’activation du CDN de Kinsta permet d’améliorer encore l’efficacité et l’optimisation de votre site. Le CDN de Kinsta est notre CDN HTTP/3 haute performance alimenté par Cloudflare, qui vous est fourni sans frais supplémentaires. S’il est activé, votre site sera en mesure de servir des ressources statiques à partir d’emplacements situés dans le monde entier.

Consultez un expert en performances

Si vous êtes familiarisé avec l’optimisation des sites, cette étape est facultative. Un expert peut vous aider à analyser tous les aspects de votre site, à identifier les goulets d’étranglement et à mettre en œuvre des solutions.

Redémarrer PHP

Si PHP tombe en panne, notre système l’enregistre automatiquement pour que notre équipe d’administration des systèmes (sysadmin) puisse le vérifier. Cependant, vous pouvez redémarrer manuellement PHP pour n’importe lequel de vos sites web individuellement avec un simple clic d’un bouton depuis MyKinsta.

Comment redémarrer PHP manuellement

Pour redémarrer PHP sur votre site WordPress, suivez les étapes ci-dessous.

1. Connectez-vous à MyKinsta.
2. Allez sur Sites WordPress et sélectionnez le site sur lequel vous souhaitez redémarrer PHP.
3. Allez dans l’onglet Outils et trouvez la section Redémarrer PHP.
4. Cliquez sur le bouton Redémarrer PHP.

Veuillez noter que le redémarrage de PHP prendra environ 5-10 secondes. Vous recevrez une notification en bas de l’écran lorsque le redémarrage sera terminé.

Note : Vous devrez également supprimer le cache de votre site pour voir les changements.

Limites de PHP

En tant que service WordPress infogéré, Kinsta dispose des réglages PHP optimaux configurés pour fonctionner au mieux avec les sites WordPress. Si vous avez des besoins spécifiques en PHP, n’hésitez pas à contacter notre équipe de support pour en discuter.

Kinsta propose PHP 8.1, 8.2 et 8.3. Ce sont les réglages par défaut de PHP :

• memory_limit = 256M
• post_max_size = 128M
• upload_max_filesize = 128M
• max_input_vars = 10000
• max_execution_time = 300

Vous pouvez augmenter ces valeurs si nécessaire. Veuillez contacter notre équipe d’assistance pour connaitre les options qui s’offrent à vous.

Limite de mémoire PHP

La limite de mémoire PHP par défaut de Kinsta est de 256 Mo, ce qui est plus que suffisant pour la plupart des extensions et sites WordPress. Cette limite existe pour empêcher les scripts PHP de consommer trop de mémoire. Si vous fixez la limite trop haut, un script mal configuré ou cassé peut causer de sérieux problèmes en consommant trop de mémoire.

Si votre site est correctement configuré chez Kinsta, vous ne devriez pas rencontrer d’erreur de limite de mémoire. Si vous rencontrez cette erreur, nous vous recommandons de vérifier les paramètres de WordPress pour vous assurer que la limite n’a pas été fixée accidentellement à un niveau trop bas.

Si vous souhaitez augmenter la limite de mémoire PHP d’un site, vous pouvez acheter un module de limite de mémoire PHP. Ce module augmente la limite de mémoire de 256Mo à 512Mo pour un cout de 50 $ par site et par mois.

Pour acheter ce module, dans MyKinsta, allez dans Sites WordPress > nom du site > Modules, et sous Mémoire PHP, cliquez sur Modifier.

Une nouvelle fenêtre s’ouvre avec les informations tarifaires ; cliquez sur Ouvrir la discussion pour démarrer une disciussion, avec notre équipe de gestion des comptes, qui configurera le module pour vous.

Vous pouvez également contacter l’équipe de gestion des comptes via le chat en direct dans le tableau de bord MyKinsta ou en nous envoyant un e-mail à [email protected].

Si vous supprimez la limite de mémoire PHP et que vous êtes dans les 30 premiers jours de votre plan d’hébergement WordPress, des frais proportionnels pour le module seront ajoutés à votre prochaine facture pour la période pendant laquelle il a été activé. Si votre plan d’hébergement WordPress est actif depuis plus de 30 jours, vous recevrez un crédit au prorata des frais d’extension sur votre solde de compte pour les jours restants de la période de facturation en cours. Le crédit est automatiquement utilisé pour compenser l’argent dû à Kinsta sur votre prochaine facture. Pour plus d’informations, reportez-vous à notre Garantie de remboursement de l’hébergement WordPress.

Vérifier et modifier votre limite de mémoire PHP

Pour vérifier votre limite de mémoire PHP pour WordPress, connectez-vous au tableau de bord WordPress de votre site et naviguez vers Outils > Santé du site.

Allez dans l’onglet Info et cliquez sur l’icône en forme de flèche à côté de la section Serveur pour développer cette section et voir votre limite de mémoire PHP.

Si la limite de mémoire est inférieure à 256M, vérifiez votre fichierwp-config.php pour voir si le WP_MEMORY_LIMIT a été modifié et ajustez-le si nécessaire.

Si la limite de mémoire est de 256M, mais que vous avez des problèmes avec la mémoire PHP, nous vous recommandons de vérifier et de tester les extensions et les thèmes. Vous pouvez utiliser un environnement de staging pour désactiver et réactiver en toute sécurité les extensions et les thèmes afin d’identifier la source de l’utilisation de la mémoire.

Si l’erreur persiste et que vous ne pouvez pas identifier la source, vous pouvez ouvrir une nouvelle discussion avec notre équipe de support pour vérifier les journaux et exclure tout problème du côté du serveur.

Mise à jour de PHP

Nous avons rendu la mise à jour de la version PHP de votre site aussi facile que possible dans MyKinsta.

Dans MyKinsta, vous pouvez mettre à jour la version PHP pour un ou plusieurs sites, y compris les sites de test, simultanément depuis la page Sites WordPress. Cochez les cases à côté des sites pour lesquels vous souhaitez mettre à jour la version PHP, cliquez sur Actions, et choisissez Changer la version PHP.

Sélectionnez la version que vous souhaitez mettre à jour et cliquez sur Changer la version de PHP.

Une fois la procédure terminée, un message de réussite s’affiche.

Vous pouvez également mettre à jour la version de PHP pour un seul site dans Sites WordPress > nom du site > Outils. Sous Moteur PHP, cliquez sur la liste déroulante et sélectionnez la version de PHP que vous souhaitez mettre à jour pour votre site.

Dans la fenêtre Modifier la version de PHP qui apparait, cliquez sur le bouton Modifier la version de PHP pour confirmer le changement.

À la fin de la mise à jour, votre moteur PHP sera redémarré et le backend (tableau de bord WordPress) de votre site pourra être indisponible pendant quelques secondes. La partie avant du site restera accessible et les visiteurs ne subiront aucun temps d’arrêt.

Pendant le processus de mise à jour, vous pouvez naviguer vers d’autres parties de MyKinsta, mais certaines actions, comme la gestion du cache, seront indisponibles jusqu’à ce que le moteur PHP ait redémarré.

Une fois la mise à jour terminée (généralement en 3 minutes ou moins), vous recevrez une notification dans MyKinsta vous indiquant que la mise à jour est terminée.

Constantes PHP

Les constantes PHP stockent des valeurs fixes qui restent les mêmes sur l’ensemble de votre site. Elles sont automatiquement globales, ce qui est idéal pour les valeurs qui doivent être accessibles à plusieurs endroits.

Si vous utilisez une configuration non standard de WordPress, comme Bedrock ou Trellis, Kinsta peut ne pas être en mesure de localiser la variable DB_PASSWORD et, par conséquent, ne peut pas mettre à jour le mot de passe de la base de données lorsque vous :

• Ajoutez un nouveau site en clonant un environnement existant
• Ajoutez un environnement de staging en clonant un environnement existant
• Poussez l’environnement de staging vers l’environnement de production
• Restaurez une sauvegarde
• Modifiez le mot de passe de la base de données dans MyKinsta

Pour résoudre ce problème, Kinsta fournit la constante PHP SERVER_SECRET_DB_PASSWORD à utiliser sur les serveurs Kinsta. Lorsque vous définissez cette constante dans le fichier config.php, MyKinsta l’utilise pour identifier le mot de passe de la base de données de votre site. Vous pouvez la définir comme suit :

define('DB_PASSWORD', defined('SERVER_SECRET_DB_PASSWORD') ? SERVER_SECRET_DB : 'asdijfhkjasdbfkjhbajiksd' );

Vous pouvez définir les constantes PHP suivantes à utiliser avec les serveurs Kinsta :

• SERVER_SECRET_DB_USER
• SERVER_SECRET_DB_PASSWORD
• SERVER_SECRET_DB_HOST
• SERVER_SECRET_DB_NAME

Par exemple, vous pouvez définir les constantes dans le fichier config.php comme suit :

define('DB_NAME', defined('SERVER_SECRET_DB_NAME') ? SERVER_SECRET_DB_NAME : 'newsitetest');
define('DB_USER', defined('SERVER_SECRET_DB_USER') ? SERVER_SECRET_DB_USER : 'newsitetest');
define('DB_PASSWORD', defined('SERVER_SECRET_DB_PASSWORD') ? SERVER_SECRET_DB : 'asdijfhkjasdbfkjhbajiksd' );
define('DB_HOST', defined('SERVER_SECRET_DB_HOST') ? SERVER_SECRET_DB_HOST : 'localhost');

Vous pouvez également définir les constantes comme suit :

define('DB_NAME',SERVER_SECRET_DB_NAME);
define('DB_USER',SERVER_SECRET_DB_USER);
define('DB_PASSWORD',SERVER_SECRET_DB_PASSWORD);
define('DB_HOST',SERVER_SECRET_DB_HOST);

Modules PHP

Les modules PHP suivants sont installés par défaut sur votre site WordPress sur Kinsta :

• bcmath
• bz2
• calendar
• Core
• ctype
• curl
• date
• dom
• exif
• FFI
• fileinfo
• filtre
• ftp
• gd
• gettext
• hash
• iconv
• igbinary
• imagick
• imap
• intl
• json
• libxml
• mbstring
• mysqli
• mysqlnd
• openssl
• pcntl
• pcre
• PDO
• pdo_mysql
• Phar
• posix
• readline
• redis
• Réflexion
• session
• shmop
• SimpleXML
• savon
• sockets
• sodium
• SPL
• standard
• sysvmsg
• sysvsem
• sysvshm
• tokenizer
• xml
• xmlreader
• xmlwriter
• xsl
• Zend OPcache
• zip zlib

ionCube n’est pas installé par défaut mais peut être activé si votre site utilise PHP 8.1, 8.2, ou 8.3 dans MyKinsta > Sites WordPress > nom du site > Outils > ionCube Loader > Activer.

Si vous avez des questions sur un module PHP spécifique qui n’est pas inclus dans la liste ci-dessus, contactez l’équipe de support de Kinsta.