Pour exécuter du code, PHP consomme du processeur et de la mémoire. Quand une requête HTTP arrive, un processus php-fpm lui est dédié. Mais ces ressources sont limitées. Et, même dans Le Cloud ou en serverless, scaler prend du temps et les coûts s’envolent !
Savez-vous combien de CPU et de RAM votre application réclame ? Et pendant quelle durée ? Si non ou sans comprendre « pourquoi », difficile de développer efficacement et de dimensionner un hébergement pérenne ! Peut-être que ça marche… Sur votre poste. Ou pendant un moment, en gaspillant de l’argent et des ressources. Mais l’expérience prouve que, tôt ou tard, ces questions vous rattraperont.
Cycle de vie de PHP, communication entre nginx et php-fpm, approche shared-nothing, compilation et cache d’opcodes, gestion interne de la mémoire ou même architecture logicielle et debugging… Pour qu’une application réponde aux attentes de son public, nous devons comprendre comment PHP fonctionne !
_ Merci, bonjour tout le monde. Nous allons parler de PHP sans surprise. Mais avant, je vais commencer par une histoire. Une histoire vécue. C'est une histoire qui date d'il y a bien longtemps. C'est loin. Plus efficace qu'un café. Le DSI entre dans notre bureau. Alarme. Le site ne répond plus. Les développeurs dont je faisais partie, nous commençons à investiguer. Nous connaissions les Ops. Ils n'avaient pas de machine à café de leur côté du bâtiment. Ils venaient dans nos bureaux. Nous avons commencé à échanger sur IRC, échanger des messages sur Dashboard. Le DSI nous ordonne d'aller bosser dans le bureau des Ops. Nous nous regardons et nous visitons. C'est notre VN+3, VN+4. Nous nous levons et nous partons. Il reprend : Prenez vos PC. Nous bossions avec des PC fixes. Une tour, un écran, une souris, un câble Ethernet, un câble d'alimentation, beaucoup de choses. Le débranchement tout cela, nous allons chercher un chariot et nous revenons, nous prenons tout le bordel avec le chariot, et nous traversons tout le bâtiment. Le DSI nous a suivis et ordonne aux Ops: trouvez-leur des câbles d'alimentation, tout ce dont ils ont besoin. Merci, le DSI s'en va, nous avons discuté cinq minutes entre Dev et Ops. La prod est repartie. Nous n'avons pas branché les PC. Nous avons perdu du temps. Avant de continuer, j'aimerais vous poser une question. Dans la salle, qui se définit comme DEV ? Qui se définit comme Ops ? Je peux balancer des blagues sur les Ops aujourd'hui ? Et si nous arrêtions aujourd'hui de se dire DEV ou Ops ? Et que nous travaillions un peu ensemble ?
Si je reviens à l'anecdote que je donnais juste avant, elle n'est pas complètement liée à mon talk. Le principe de démonter des PC fixes et de les amener à l'autre bout du bâtiment où il n'y a pas de café, c'était absurde et peu efficace. Mais l'idée de travailler ensemble, ce n'était pas une mauvaise idée.
Je m'appelle Pascal Martin. Je suis Principal Engineer chez Bedrock. Je joue beaucoup sur les sujets de performance, de scalabilité. Nous développons une plate-forme que nous vendons à des broadcasters européens. Vous nous connaissez pour 6play et Salto.
Qu'est-ce que c'est PHP ? C'est un langage de formation Open Source. La première action de PHP est sortie le 8 juin 1995. Publiée par Rasmus Lerdorf. En 98, on fait une réécriture majeure. Je commence avec PSP 3. Vous allez entendre Zend plusieurs fois pendant ce talk. Les deux outils marquent un tournant pour PHP. Il se professionnalise. PHP commence à répondre aux besoins de notre communauté. Mais depuis quelques années, nous ne parlions plus vraiment de PHP. Nous ne disions pas que nous développions avec PHP. Mais nous travaillons avec lui et son écosystème. Depuis 2010, il a un cycle de release, les versions documentées, la dernière version de langage est sortie en 2020. Quand vous travaillez avec PHP, vous sortez par un composant qui sait interpréter vos requêtes. Et les transmettre au moteur de PHP. Ça permet au moteur d'être utilisé dans différentes conditions. Avec un serveur Web ou un autre. En ligne de commande. Ce composant s'appelle un Server-API.
Le moteur de PHP a un cycle de vie avec différentes étapes. Quand nous lançons PHP, nous commençons par MINIT. Ensuite, nous passons à la phase RINIT. Nous utilisons des choses qui peuvent servir à la requête. Nous pensons à la mémoire qu'on va utiliser pour stocker la requête. On crée la requête. Quand la requête est terminée, RSHUTDOWN pour éliminer la mémoire. MSHUTDOWN, l'extinction du moteur de PHP. Le schéma que vous avez sous les yeux représente l'exécution d'une requête. Quand vous lancez PHP. Mais lancer encore et encore le point PHP, ça prend du temps et des ressources. Pour éviter cela, pour optimiser, une approche était d'intégrer le moteur de PHP dans un serveur Web. Il y a un peu plus de 10 années, nous faisions cela avec Apache 2. Depuis PHP 5,3, beaucoup ont arrêté de travailler avec API. Une autre API plus évoluée. Php-fpm. Elle embarque sa propre gestion de plusieurs pools de processus.
Je reviens sur le schéma. Avec php-fpm. Nous avons toujours MINIT et RINIT, et nous pouvons traiter plusieurs requêtes. Pour chaque requête, nous avons RINIT et RSHUTDOWN. Nous le faisons encore et encore jusqu'à la fin du processus php-fpm. Si nous voulons paralléliser et traiter plusieurs requêtes à la fois, le processus worker va traiter plusieurs fois. J'ai un processus Master qui va recevoir les requêtes et les dispatcher sur plusieurs processus worker. Le nombre de processus qu'on a vus, trois façons différentes.
La façon dynamique. C'est bien de l'adapter si on veut héberger sur un seul serveur plusieurs points d'application. Ils auront leur pic de charge à plusieurs moments différents.
Quand nous hébergeons plusieurs applications qui ont peu de trafic. Ce qui est statique, un nombre de processus fixes.
Quand on héberge dans Kubernetes ou Pods, on utilise php-fpm en mode static. Nous le faisions déjà avant Kubernetes. Avant, c'était une application par machine. Elles ont une quantité CPU fixe.
Nous avons dit toujours de faire quelque chose de visible au bureau. Je me rattrape en conférence. Php-fpm est un serveur. On peut imaginer que les utilisateurs font des requêtes. Mais les utilisateurs parlent en http. Mais php-fpm parle en CGI. Ils peuvent pas communiquer.
Nous intercalons un serveur Web. Nginx. Apache 2, autre. Ce serveur Web peut parler en http avec l'utilisateur. Il sait parler en CGI avec php-fpm. Nous complexifions, mais ça marche.
Si PHP, c'est cool, c'est extensible. On peut ajouter des fonctions. Les extensions PHP sont écrites en C ou dans un autre langage compilé compatible. Une autre conférence vous expliquera comment comptabiliser les extensions. Elles qui peuvent être compilées dans PHP au plus souvent, nous les compilons sous forme de bibliothèques partagées qu'on charge dynamiquement. Si je reviens sur mon joli schéma ici, au démarrage, et à l'arrêt d'un processus PHP...
(coupure de son)
... Chacune de nos extensions. Si nous installons beaucoup d'extensions PHP sur notre serveur en disant qu'un jour, ça va servir, vous allez bouffer des ressources si elles n'ont pas optimisé RSHUTDOWN. Et RINIT.
Les extensions PHP, nous les utilisons tous les jours. De nombreuses fonctionnalités de PHP sont fournies par des extensions. Ces extensions peuvent faire partie du code de PHP. C'est le répertoire X du projet PHP. D'autres ont leurs propres versions, ils sont hébergés ailleurs. Beaucoup d'extensions sont uniquement de la glu vers des bibliothèques système. Gmagick. Quand vous râlez sur PHP, c'est un langage bête.
Le code PHP, dans mes souvenirs, ça ressemble à ça. Mon serveur, mon processeur ne comprend pas cela. À la place, il va exécuter des opcodes. La première étape de l'exécution du code PHP, c'est de compiler le code PHP en opcodes. Ces opcodes, ce sont des *destructions simples. Ça ressemble à du langage assembleur. C'est exécuté par le moteur de PHP, le Zend. Chacun peut correspondre à une centaine ou un millier de lignes de code. Ici, vous avez l'opcode Zend_ ECHO. Il n'est pas trop long. Passé le premier moment d'horreur, c'est assez compréhensible. On arrive à lire et à comprendre ce qui se passe. Nous avons des parenthèses, des accolades. C'est comme le langage PHP. Ça marchera presque avec PHP. Allez lire le code source de PHP. Vous verrez que ça ressemble un peu. Nous arrivons À comprendre des comportements. Et mettez à jour la documentation après.
Vos applications, elles consomment des ressources. Quand nous pensons ressources, nous pensons serveur, processeur. La compilation du code de PHP, de la gauche à la droite, si c'est fait à chaque fois qu'un script PHP va être exécuté. Si vous recevez 1 million de requêtes HTTP par jour sur votre serveur, vous allez compiler 1 million de fois le truc de gauche dans le truc de droite. Je parie ou j'espère que votre code ne change pas 1 million de fois par jour. Sinon, vous tapez très vite. Vous avez beaucoup de CPU à faire 1 million de fois. La même chose. Heureusement, nous pouvons l'éviter.
Le plus évident, c'est suite à quoi vous avez pensé en premier, vous avez dû brûler du CPU. Ça dépend de ce que vous avez écrit comme code. Si vous utilisez des calculs cryptographiques ou du redimensionnement d'image en PHP, ça brûle du CPU. Ça consomme des ressources.
DSP, c'est un composant qui fait de la glue entre d'autres composants. Il fait des requêtes. Il attend les réponses et les assemble. Quand PHP attend les requêtes. Il ne consomme pas ou très peu de CPU. À l'inverse, quand votre application a besoin de beaucoup de CPU parce qu'elle effectue des calculs, un fichier YAML gigantesque, elle actualise dans Json quelque chose que vous ne devriez pas envoyer à vos clients, si PHP n'a pas assez de CPU à sa disposition, ça rame. Ne pas avoir assez de processeur, ça arrive. CPU, ça coûte cher.
Même si PHP consomme un CPU chaque fois pour les requêtes, n'oublions pas que nous lançons plein de processus PHP en parallèle pour réussir à traiter plusieurs requêtes à la fois. Ces multiples processus PHP peuvent se partager les quelques cœurs CPU que nous avons sur nos machines.
Une autre ressource limitée. La mémoire. Dans un serveur, nous n'avons pas une quantité infinie de mémoire. Nous en utilisons. Par exemple, pour les variables dans lesquelles vous stockez des choses. Le simple fait d'avoir un processus PHP consomme de la mémoire. Si vous en avez plusieurs parallélisés, vous consommez plus de mémoire. Même s'il arrive à mutualiser les choses, ça amène à une plus grande composition de mémoire de toute façon. Juste en travaillant, PHP consomme de la mémoire. La compilation du code PHP en opcodes, il est stocké en mémoire. Avec des applications modernes, un Framework énorme et la moitié Kubernetes en dépendance, vous allez en bouffer beaucoup de la mémoire. Dans le pire des cas, vous consommez plus de mémoire que le serveur en avait. Que OS était prêt à vous en donner. Il va tuer votre programme avec un OOMKill. Mais le système existe pour se protéger. Ce n'est pas Linux ou Kubernetes les qui sont méchants. Ces outils jouent leur rôle. Pour éviter que votre application apporte la machine dans sa chute.
On ne s'arrête pas à CPU et à la RAM. Ce serait trop facile. Les ressources critiques, il y en a plein d'autres. J'ai déjà vu une application souffrir horriblement parce qu'il stockait des données énormes en cache dans Redis sur d'autres serveurs. Toute la bande passante des serveurs était consommée. En stockant trop de données en cache, nous avons fait mal à notre application. Attention. La bande passante réseau, ça existe. Le nombre de connexions réseau ouvertes à la fois, le nombre des descripteurs de fichiers ouverts à la fois, l'espace disque, plein de choses qui vont vous poser problème. Je n'ai pas le temps d'aller dans les détails de tout cela. Il faudra revenir l'année prochaine. Je voudrais que vous souveniez que même en PHP, vous devez vous souvenir des ressources que vous consommez et des ressources disponibles dans vos machines.
Une autre ressource critique. C'est quelque chose qui est sur des applis à forte... je reviens sur php-fpm. C'est le moyen le plus utilisé aujourd'hui. Quand on veut répondre à des requêtes PHP avec nginx. Avec php-fpm, chaque processus laisse traiter qu'une seule requête à la fois. Quand le traitement de la requête dure longtemps, parce que PHP attend une réponse, une autre requête arrive et le processus n'est pas prêt, il n'y a pas de réponse à la requête et il prend une erreur. On peut stocker la requête, mais il n'est pas stocké éternellement. Php-fpm est critique et traite une seule demande à la fois. Si PHP attend par exemple qu'une base de données réponde, vous allez vous retrouver dans une situation où vous n'aurez plus de processus disponibles pour traiter d'autres requêtes. C'est quelque chose de temporaire. Pendant un moment, il y a beaucoup d'utilisateurs qui ne sont pas contents. À l'échelle, les processus php-fpm sont une ressource limitée et critique. Qu'est-ce qu'on fait ? On en lance plusieurs en parallèle et on en ajoute encore et encore. On ne peut pas en lancer une infinité. Chaque processus consomme de la mémoire. Au sens limité. Chaque processus peut consommer jusqu'à un cœur CPU. Une ressource limitée. Pas de solution magique.
Je pense que souvent, on fait un développement, en base de données, à ElasticSearch, n'importe quoi, je vais réparer toutes les informations dont j'ai besoin pour répondre à l'utilisateur. On lui répond rapidement. Mais après, vous : j'aimerais envoyer un mail. Faire un traitement qui prend du temps. Je vais mettre cela en carnet terminé pour que ce soit traité après la réponse à l'utilisateur. C'est une bonne idée. Vous lui répondez rapidement. Il est satisfait. Mais pendant tous les traitements lourds que vous faites, le processus php-fpm reste consommé. Les autres utilisateurs n'ont pas les processus pour les traiter. Vous avez répondu au premier utilisateur, mais pas aux suivants. Vous avez l'impression d'avoir amélioré les choses sur votre poste en DEV. Vous ne les avez pas améliorées en production avec de la charge.
Vous n'êtes pas encore paniqués ? J'ajoute une couche. Les ressources qui ne sont pas illimitées. C'est valable ailleurs. Vous avez un nombre maximum de connexions autorisées sur votre base de données. Si vous ajoutez des processus en parallèle. Vous ouvrez plus de connexions. Les nouvelles connexions par seconde. Toutes les API et tous les services que vous utilisez en extérieur vont racheter vos requêtes si vous en faites plus que X par seconde. Bon courage.
Je dis que la mémoire RAM. C'est une ressource limitée. Voyons comment ça fonctionne. Globalement, nous souhaitons un programme qui souhaite allouer de l'espace mémoire. Il appelle la fonction malloc(). C'est un appel système qui prend du temps. Dans l'autre sens, pour libérer de l'espace mémoire, on appelle la fonction free(). Jusque là, facile. Mais malloc(). Il peut échouer. Que fait un programme qui ne parvient pas à avoir de l'espace programme alors qu'il en a besoin ? C'est vous. Chaque fois que vous choisissez d'utiliser un espace mémoire. Lire ou écrire depuis un espace mémoire qui ne vous appartient pas. Libérer de l'espace avec l'application free(), boum l'application. On ne peut pas l'allouer à l'autre programme...
Le moteur PHP peut utiliser les fonctions malloc() et free(). Il peut demander la mémoire système. L'application PHP le peut aussi. C'est une des raisons historiques pour lesquellrs php-fpm tue les processus toutes les quelques centaines de requêtes. Au cas où il y aurait une fuite mémoire dans PHP ou les extensions. Il suit le programme et un autre sur Valence*. Il repart avec aucune fuite mémoire. C'est la galère. PHP est là pour nous simplifier la vie. On n'a pas à se soucier des fonctions malloc() et free(). Ce qu'on a fait au quotidien, c'est d'utiliser la mémoire sans y penser. Il ne faut pas bouffer des giga-octets en stockant des vidéos en RAM. Chaque fois qu'on utilise une fonction et qu'on travaille avec une variable, qu'on enlève des éléments dans un tableau, on enlève de la mémoire. PHP le fait pour nous. Ce n'est pas l'heure de la sieste.
PHP embarque le ZMM, Zend Memory Manager, il nous fournit de la mémoire plus rapidement. Il implémente memory_limit. Une sécurité. Mieux vaut Fatal Error sur une page. Ne réglez pas cette limite à une valeur trop élevée.
(coupure de son) **
... Faire ce qu'il veut dedans. Si le bloc mémoire n'est plus assez grand, on l'agrandit. Plus que nécessaire. La variable suivante, on n'a pas à nouveau à réallouer la mémoire. À la fin du traitement de la requête, ZMM libère le bloc, les données sont détruites. On a seulement un peu de fuite des textes.
Quand je parle de gestion de la mémoire en PHP, on me demande souvent ce qui est le Garbage Collector. Ils servent uniquement à briser les références circulaires. Avant PHP 5.3, quand on en effaçait, les variables à baisser restaient en mémoire jusqu'à la fin. Mais maintenant, c'est libéré jusqu'à la fin. Mais PHP n'est pas un langage garbage collected.
ZMM alloue un bloc mémoire au lancement du traitement. Les variables sont dans le bloc mémoire. Elles sont détruites à la fin du traitement de la requête. La conséquence : PHP nous offre une approche shared_nothing. Aucune donnée n'est partagée entre le traitement des requêtes. Qu'elles soient en succession, ou qu'elles soient en parallèle avec plusieurs processus. C'est fantastique. La première conséquence, c'est que PHP nous facilite les choses. C'est sans aucun doute une raison de son succès. Comme premier langage chez les débutants. Repartir d'une page blanche à chaque requête, c'est fantastique. Nous n'avons pas de fuite mémoire, pas besoin de fermer les fichiers ouverts. À la fin d'une requête, il ne reste pas de mémoire allouée pour rien. Quand nous passons au traitement d'une requête pour un utilisateur B, nous savons que nous n'avons plus en mémoire les données de l'utilisateur A.
Quand nous cherchons des applications pour répondre en millisecondes pour gérer du trafic, l'approche shared_nothing n'a pas que des avantages. Ne pas partager des données, pas de piège DNS. Pas de correction persistante vers nos bases de données. Pas de correction persistante par les API et les timeouts. On ouvre une connexion PCP. Ça bouffe du temps et des ressources, vous devez vous réidentifier sur toutes ses choses. On se retrouve à mettre en place des proxy et des connexions ouvertes parce que PHP ne partage rien d'une requête à l'autre. C'est dommage et c'est une source de souffrance.
Les extensions de PHP peuvent nous aider. Elles peuvent nous allouer de la mémoire en dehors du ZMM. Elles peuvent les conserver d'une requête à l'autre. Certaines le font. MySQL par exemple.
C'est plus facile de planter les choses et d'introduire des fins de sécurité en PHP.
Après tout cela, désolé. Il n'y a pas de solution magique. Il n'y a pas un truc où vous allez sortir : La plate-forme va faire fois deux en scalabilité.
Vous allez dire que je caricature. Il y a beaucoup de DEV dans la salle. Quand une application rame et qu'elle consomme toutes les ressources sur le serveur, le premier réflexe, c'était d'aller parler aux Ops et de dire : Il nous faut plus de serveurs. Allumer plus de ressources, ça marche. Ça donne de la patate à une application. Ça coûte plus cher. Mais c'est acceptable peut-être. Si chaque fois que vous répondez à un utilisateur, vous gagnez de l'argent, vous allez répondre à plus d'utilisateurs. Si vous bossez sur un historique, vous pouvez approvisionner plus de ressources. Pendant votre pic de charges quotidien ou pendant les soldes, vous allez payer pour rien, mais vous pouvez. Si vous êtes sur un hébergement plus moderne, vous pouvez avoir plus de capacité. La rendre quand vous n'en avez plus besoin. Vous allez mettre en place un processus d'auto-scaling. C'est pratique.
Mais dans un cas comme dans l'autre, les ressources ne sont pas illimitées et on n'en a pas immédiatement. On-prem, il faut plusieurs semaines pour avoir un nouveau serveur. Dans le Cloud, il faut quelques minutes ou quelques dizaines de secondes. Vous ne pouvez pas prédire un pic de charge. Auto-scaling réactif, ce n'est pas instantané.
Dans l'autre sens, quand les DEV disent qu'ils veulent plus de serveurs, les Ops disent qu'il faut optimiser leur code. Les Ops n'ont pas tort. J'ai déjà vu des temps de réponse divisés par 10, par 100 ou par 1000. Pour quelques heures de travail, ça peut valoir le coût. Ça peut être écrit coût ou coup.
La ressource la plus limitante, c'est le nombre de processus php-fpm. Il reste à attendre qu'une base de données à répondre. C'est là où vous devez prendre du recul sur votre plate-forme et réfléchir à l'architecture globale de votre plate-forme. Pas uniquement de la petite API dont vous êtes responsables sur laquelle vous êtes en train d'implémenter une user story. Il devient indispensable de configurer les timeouts sur toutes les requêtes que vous utilisez. Ils doivent être courts.
Imaginons que vous avez une API qui réponde à la normale en 100 millisecondes. Je vais prendre de la marge. Je vais mettre un timeout d'une seconde. Le jour où cette API aura du mal, les clients de cette API vont attendre 10 fois plus longtemps qu'en temps normal. 10 fois plus de processus php-fpm vont être occupés et consommés pour attendre un timeout. Est-ce que vous savez comment vos plates-formes se comportent dans ce cas ? J'ai une piste. Tout va merder. Selon mon expérience.
Pour un serveur PHP qui consomme beaucoup de CPU, un réflexe, installez un cache d'opcodes. Vous donnez de la RAM au cache d'opcodes. Ils veulent consommer beaucoup moins de CPU. On va atteindre les limites. C'est bien délimité le supplier. J'ai vu de la CPU divisée par deux sur des serveurs en divisant le cache d'opcodes. Vous n'avez pas d'excuses d'activer le cache d'opcodes si vous êtes maître de vos hébergements.
Mais configurez-le bien. Si vous ne lui donnez pas assez de mémoire, on va faire la compilation, stocker les opcodes dans le cache, on va purger, et on recommence. Ce sera catastrophique. Combien de mémoire allouée au Pcache ? Vous saurez combien de mémoire lui donner en regard de la volumétrie. Regardez de temps en temps quand vous faites de nouveaux développements. Vous devrez avoir plus de mémoire. Une autre approche, c'est de changer nos habitudes. Avec PHP, nous avons l'habitude de faire les choses en séquences les unes après les autres. Requête SQL, ElasticSearch, API, etc. On ne fait qu'attendre. On émet une requête. On attend longtemps. Nous nous occupons des processus php-fpm pendant ce temps.
Si nous faisions autrement ? Si nous lancions une requête en concurrence parallèle ? Nous utiliserions un processus php-fpm pendant bien moins longtemps. Nous répondrions plus vite aux utilisateurs. La contrepartie, c'est qu'on se complexifie la tâche. Et c'est fun à développer quand on a des problèmes. On le fait chezBedrock.
Rejouer encore et encore des connexions DNS et des connexions TCP, charger des données depuis des caches et les désirialiser encore et encore. Perte de temps. Si on écrivait un serveur en PHP pour le lancer, qu'il restait lancé, qu'il traitait plusieurs requêtes en asynchrone ? On pourrait partager des données. On n'aurait pas besoin de tout refaire. On éviterait le principe shared_nothing. Ce sont des choses qu'on permet de faire. Si une certaine erreur survient, ça va impacter beaucoup de données à la fois. Ça fait peur. Travailler en approche non shared_nothing, on n'en a pas trop l'habitude. On peut se poser des questions sur les Frameworks entre autres.
Est-ce qu'il y a du multi-thread en PHP ? Non, il n'y en a pas en PHP et en userland de base. L'extension parallèle peut vous aider. Il y avait une extension qui s'appelait pthreads. Mais elle a besoin d'une application spécifique pour PHP. Elle n'est pas compilée. Il faut le faire soi-même. C'est une expérience à vivre une fois dans sa vie.
Il est temps de commencer à réaliser que nous avons fort à faire. De quoi nous avons parlé pendant les 30 minutes qui viennent de s'écouler ? Travailler sur une plate-forme, construire un produit, fournir une bonne expérience, ça dépasse uniquement l'écriture du code PHP. Je suis convaincu que de parler avec des gens de métiers différents va améliorer la qualité de nos obligations et de nos produits. Les expériences de nos clients. C'est comme cela que nous allons plus loin. J'hésite à le redire. Le mot est tendu dans tous les sens. Il veut dire 36 choses. Penser DevOps. Allez plus loin.
Quand nous allons avec la solution la plus utilisée, rappelons-nous qu'un processus php-fpm traite une donnée à la fois. Il consomme jusqu'à un cœur CPU. Pour aller plus vite, faites moins de choses, installez plus de CPU. Installez du horizontal. PHP fonctionne avec que du shared_nothing, tout est indépendant. Ça simplifie beaucoup les choses quand on débute. Mais on passe beaucoup de temps à faire les mêmes choses dont les résolutions DNS.
Qu'est-ce qu'on peut dire d'autre ? Dernier point. Point de vue performance. Parfois, on peut se demander si les microservices sont toujours l'approche la plus adaptée pour nos micros plates-formes. Nous faisons face à un monolithe distribué avec plein de composantes, nous voyons peu souvent des microservices qui communiquent en asynchrone. C'est fun, sauf quand c'est planté.
Si sortir une usine à gaz avec PHP, ce n'était pas aussi génial qu'on le croyait, ajouter du code encore et encore, c'est consommer plus de CPU, plus de RAM, plus de ressources, et les ressources sur notre serveur et sur notre planète, ce n'est pas illimité.
Jetez un coup d'œil dans le code source de PHP. Parfois, c'est intéressant. mettez-vous-y à deux peut-être. Vous allez ouvrir plein d'onglets. Pensez au fait que les processus PHP, c'est des ressources précieuses. C'est un pas vers le bon chemin.
Et si PHP n'était pas toujours l'option la plus adaptée pour le fort trafic ?
(coupure de son)
... n'hésitez pas à venir me voir. Vous êtes les bienvenus. Je suis Pascal Martin. J'ai pendant longtemps été développeur PHP. J'en fais beaucoup moins aujourd'hui. Je suis principal ingénieur chez Bedrock. Nous recrutons régulièrement. Sur les postes de développeurs back. Nous avons un stand juste à côté. Vous pouvez passer pour discuter. Merci beaucoup.
(applaudissements)
Tweets