Annonce d'un mitap qui se transforme en douceur en un drinkcap BeerPHP (à Moscou et en ligne)

Bonjour, en août, nous tiendrons une réunion à Moscou avec des conférenciers d'autres villes, une réunion BeerPHP et la diffusion de la partie officielle pour tous ceux qui ne peuvent pas participer.

Aujourd'hui, nous commençons à présenter des conférenciers . Sergey Zhuk viendra à la réunion de Bryansk - il n'y a pas de fête dans sa ville, et il a quelque chose à dire sur le PHP asynchrone: il a écrit des livres à ce sujet, une série d'articles et plus encore. Vous trouverez ci-dessous une transcription d'un podcast récent à ce sujet, des liens vers l'écoute et la visualisation de la version, ainsi que des détails sur le mitap lui-même.



Pyotr Myazin alias PQR : Aujourd'hui, je suis en contact avec l'un des principaux experts de ReactPHP. Sergey, j'ai récemment visité reactphp.org et vous ai trouvé sur la page principale. Vous écrivez beaucoup sur le sujet, vous avez même votre propre chaîne avec des instructions vidéo. Dites-moi comment vous en êtes arrivé là, qu'est-ce qui vous a accroché à ReactPHP?

En fait, vous redécouvrez la langue que vous écrivez depuis de nombreuses années

Sergey aka seregazhuk : Il y a deux ans, lors d'un travail précédent, il était nécessaire d'écrire un script qui attirerait constamment les clients et fonctionnerait très rapidement. La tâche devait être terminée «hier», seuls les développeurs PHP faisaient partie de l'équipe - il n'y avait pas de temps pour une nouvelle pile, vous savez. Mais il s'est avéré que tout le monde avait entendu parler de ReactPHP. Il s'est positionné comme prêt à la production, tout a été très simple: nous venons d'installer l'entreprise via composer, et il a été possible d'écrire du code asynchrone. En conséquence, ils y ont écrit une solution, l'ont lancée, tout le monde était satisfait.

J'ai réalisé que nous avions un outil - mais il n'y avait presque pas d'articles, des exemples pratiques comme «Nous avons un tel problème, nous l'avons résolu comme ça» ni en russe ni en anglais. En conséquence, j'ai écrit quelques articles sur mon blog, j'ai reçu des commentaires positifs, et c'est tout - cela m'a en quelque sorte entraîné. Nous sommes habitués au modèle Request-Response, mais cela vaut la peine de le charger dans du code asynchrone, et vous demanderez immédiatement: "Comment est-ce possible?"

Peter: Parlons à nouveau, quel problème le code asynchrone résout-il pour nous, et pourquoi ReactPHP est-il nécessaire en particulier?

Sergey: Presque toutes les applications ont soit des appels d'API, soit une interaction avec le système de fichiers ou des requêtes de base de données. Lorsque nous attendons une réponse de leur part, notre processeur est inactif - au lieu de faire quelque chose d'utile. Vous ne pouvez pas attendre une réponse, mais lancez des opérations non bloquantes et continuez. La question se pose: "Si nous obtenons ReactPHP partout pour les E / S, nos applications seront-elles beaucoup plus rapides?"

Malheureusement, vous ne pouvez pas simplement prendre et réécrire nos applications en applications asynchrones

Sergey: Je penserais à utiliser ReactPHP dans les cas où les performances sont critiques, et les E / S sont notre botlock qui bloque tout. De plus, je recommanderais de ne pas transférer l'intégralité de l'application sur des rails asynchrones, à savoir de réécrire ce botlock particulier. En règle générale, une tranche asynchrone est beaucoup plus facile à insérer dans un code de blocage traditionnel que d'essayer de réécrire toute l'application.

Peter: Ok, mais pourquoi ne démarrons-nous pas alors des processus PHP? Celui-ci est inactif, mais le suivant est occupé.

Sergey: Et comment coordonnons-nous les résultats? Supposons que nous ayons besoin d'obtenir des données de trois sources, nous appelons trois API, puis nous composons les résultats et les donnons à l'utilisateur. Si nous faisons trois flux distincts, le problème de la coordination du résultat se posera.

Avec une approche asynchrone, nous les exécuterions simplement, pour ainsi dire, en parallèle, puis nous obtenons le résultat et le traitons. Avec les threads, vous devrez en quelque sorte coordonner cette balle, c'est-à-dire qu'il y aura un problème avec l'état. Cela semble être plus compliqué qu'une approche asynchrone.

Peter: Je comprends. J'avais cette pensée en tête: si nous voulons augmenter le nombre d'utilisateurs. traitées par seconde, comment la pile d'applications entière de Symfony serait-elle lancée dans la version asynchrone et traiterait-elle un plus grand nombre de connexions?

Sergey: Je ne ferais pas ça. Souvent, l'application ne ralentit pas complètement. Si la question des performances se pose, il y a très probablement quelques goulots d'étranglement à l'intérieur, ce qui entraîne également très probablement des E / S lentes. Et maintenant, je traduirais ces goulots d'étranglement en ReactPHP.

Cela ressemblerait à un petit programme asynchrone à l'intérieur du code de blocage habituel: par exemple, nous avons appelé trois requêtes en parallèle, les avons traitées et envoyé une réponse à l'utilisateur, et le temps d'exécution total serait égal au temps de la requête la plus lente. Si dans le cas de l'approche traditionnelle, on attendrait la première demande, la deuxième et la troisième. Mais l'application n'est pas devenue asynchrone à partir de cela.

Et si nous comparons tout cela avec NodeJS et d'autres?

Peter: Et si nous comparons tout cela avec NodeJS, disons, ou Go, il y a vraiment une asynchronie dans toute l'application. Toutes les demandes à la base de données, au système de fichiers - elles sont toutes asynchrones à l'intérieur. Est-ce à dire, en principe, si tout est écrit sous une forme asynchrone, y a-t-il un profit?

Sergey: Ce sera rentable si le problème initial est les E / S. Alors oui, nous allons le résoudre. Notre code sera aussi efficace que possible, capable de traiter le nombre maximum de tâches au lieu d'être inactif et d'attendre que cette sortie soit traitée. Mais si au départ le problème n'est pas dans les E / S, puis en écrivant tout de manière asynchrone, il est peu probable que nous gagnions quoi que ce soit, et nous pouvons obtenir du code complexe qui sera difficile à lire et à maintenir.

Peter: Revenons à PHP. Nous avons donc ReactPHP et les célèbres analogues Swoole, Amp et Ext-async. Et dites-moi en comparaison, quelle est la différence entre ces projets, et quelle est la qualité de ReactPHP, est-il rapide et a-t-il des inconvénients par rapport au même Swoole?

Sergey: Des trois, pour être honnête, je n'ai testé que Amp, et parce que, comme ReactPHP, il est pris en charge dès la sortie de la boîte. Autrement dit, nous mettons les composants nécessaires à travers le compositeur et vous avez terminé. Et ici, je n'aime pas vraiment les histoires avec des extensions. Parce que si nous nous retrouvons seuls avec PHP et asynchronie, alors, il me semble, il est plus raisonnable d'utiliser le langage et les choses natives - et si nous utilisons des extensions supplémentaires, alors ce n'est pas particulièrement PHP asynchrone, mais des extensions asynchrones pour PHP.

Comment ReactPHP est-il vraiment prêt pour la production?

Peter: «Un soutien à long terme» est écrit sur leur site Web. Autrement dit, une sorte de support à long terme, sans modifications critiques de l'API. En est-il ainsi? Est-ce que tout est assez haut?

Sergey: Oui. Le projet ReactPHP lui-même est déjà assez ancien. Il travaille depuis la douzième année, il s'avère avoir 7 ans. Il a déjà suffisamment de temps pour la production. Et oui, en plus, voici le support à long terme des principaux composants pendant 2 ans. Autrement dit, vous pouvez être lié à ces composants en toute sécurité, recevoir des correctifs, des mises à jour et ne pas vous soucier de la compatibilité descendante. Pendant deux ans ils s'engagent à maintenir leurs versions, rien ne cassera. Je pense que c'est vraiment très cool, c'est un grand pas en avant. Pour autant que je me souvienne, jusqu'à récemment, Amp a discuté de certains de ses composants, ils n'ont pas entièrement décidé de l'interface et de leur API publique.

Peter: Où recommandez-vous de commencer à apprendre ReactPHP? En plus de la documentation officielle et de vos didacticiels vidéo, bien sûr. Où sont toutes les communautés, y a-t-il des discussions par télégramme ou des discussions discordantes, des forums?

Sergey: Malheureusement, je ne connais pas une communauté aussi directe. Il existe un compte Twitter assez actif: vous pouvez y poser, poser des questions et être intéressé. Et les mineurs répondent assez rapidement - vous pouvez leur écrire personnellement sur Twitter. Je l'ai fait, en leur demandant certaines choses.



Peter: Eh bien, merci pour cette histoire si détaillée sur ReactPHP - et à cet égard, j'annoncerai le Panda Meetup , qui se tiendra le 22 août à Moscou dans le bureau Skyeng. Vous allez y jouer, non?

Sergey: Oui, c'est vrai. Venez discuter.

Peter: Il y aura également un rapport sur la conception pilotée par domaine, qui est également un sujet intéressant et intéressant dans le contexte de PHP, [et quelques autres ont été ajoutés] et, comme les organisateurs me l'ont dit, il y aura une afterparty.

Les plus:

• Version audio complète et podcast YouTube
• Lien pour diffuser mitap pour ceux qui ne peuvent pas venir
• Détails sur l'afterparty dans le télégramme BeerPHP Moscou