Ankündigung eines Mitaps, der sich nahtlos in eine BeerPHP-Getränkekappe verwandelt (in Moskau und online)

Hallo, im August werden wir in Moskau ein Treffen mit Rednern aus anderen Städten abhalten , ein BeerPHP- Treffen und die Ausstrahlung des offiziellen Teils für alle, die nicht teilnehmen können.

Heute beginnen wir, Redner vorzustellen . Sergey Zhuk wird aus Brjansk zu dem Treffen kommen - es gibt keine Party in seiner Stadt, und er hat etwas über asynchrones PHP zu erzählen: Er schrieb Bücher darüber, eine Reihe von Artikeln und mehr. Unten finden Sie eine Abschrift eines aktuellen Podcasts dazu, Links zum Anhören und Anzeigen der Veröffentlichung sowie Details zum Mitap selbst.



Pjotr ​​Myazin alias PQR : Heute stehe ich mit einem der Hauptexperten für ReactPHP in Kontakt. Sergey, ich habe kürzlich reactphp.org besucht und dich auf der Hauptseite gefunden. Sie schreiben viel zu diesem Thema, Sie haben sogar einen eigenen Kanal mit Videoanweisungen. Sag mir, wie du dazu gekommen bist, was hat dich an ReactPHP gefesselt?

Tatsächlich entdecken Sie die Sprache wieder, die Sie seit vielen Jahren schreiben

Sergey aka seregazhuk : Vor zwei Jahren war es bei einem früheren Job notwendig, ein Skript zu schreiben, das ständig Kunden anruft und sehr schnell arbeitet. Die Aufgabe musste „gestern“ erledigt werden, nur PHP-Entwickler waren im Team - es war keine Zeit für einen neuen Stack, wissen Sie. Es stellte sich jedoch heraus, dass jeder etwas über ReactPHP hörte. Er positionierte sich als produktionsbereit, alles war sehr einfach: Wir haben die Firma nur über Composer installiert und es war möglich, asynchronen Code zu schreiben. Als Ergebnis schrieben sie eine Lösung darauf, starteten sie, alle waren zufrieden.

Mir wurde klar, dass wir ein Werkzeug haben - aber es gab fast keine Artikel, praktische Beispiele wie „Wir haben ein solches Problem, wir haben es so gelöst“, weder auf Russisch noch auf Englisch. Infolgedessen habe ich ein paar Artikel in meinem Blog geschrieben, ein positives Feedback erhalten und das ist alles - es hat mich irgendwie in die Länge gezogen. Wir sind an das Request-Response-Modell gewöhnt, aber es lohnt sich, es in asynchronen Code zu laden, und Sie werden sofort fragen: "Wie könnte das sein?"

Peter: Reden wir noch einmal, welches Problem löst der asynchrone Code für uns und warum wird insbesondere ReactPHP benötigt?

Sergey: Fast jede Anwendung hat entweder API-Aufrufe oder Interaktion mit dem Dateisystem oder Datenbankabfragen. Wenn wir auf eine Antwort von ihnen warten, ist unser Prozessor inaktiv - anstatt etwas Nützliches zu tun. Sie können nicht auf eine Antwort warten, sondern nicht blockierende Vorgänge starten und fortfahren. Es stellt sich die Frage: "Wenn wir ReactPHP überall für E / A erhalten, werden unsere Anwendungen dann um ein Vielfaches schneller sein?"

Leider können Sie unsere Anwendungen nicht einfach in asynchrone Anwendungen umschreiben

Sergey: Ich würde darüber nachdenken, ReactPHP in Fällen zu verwenden, in denen die Leistung kritisch ist, und I / O ist unser Botlock, der alles blockiert. Darüber hinaus würde ich empfehlen, nicht die gesamte Anwendung auf asynchrone Schienen zu übertragen, sondern diesen speziellen Botlock neu zu schreiben. In der Regel lässt sich ein asynchroner Slice viel einfacher in einen herkömmlichen Blockierungscode einfügen, als die gesamte Anwendung neu zu schreiben.

Peter: Ok, aber warum starten wir dann nicht einfach einige PHP-Prozesse? Dieser ist untätig, aber der nächste ist beschäftigt.

Sergey: Und wie koordinieren wir die Ergebnisse? Angenommen, wir müssen Daten aus drei Quellen abrufen, drei APIs aufrufen, dann die Ergebnisse zusammenstellen und dem Benutzer übergeben. Wenn wir drei separate Streams erstellen, tritt das Problem der Koordinierung des Ergebnisses auf.

Bei einem asynchronen Ansatz würden wir sie einfach sozusagen parallel ausführen, dann erhalten wir das Ergebnis und verarbeiten es. Bei Threads müssen Sie diesen Ball irgendwie koordinieren, das heißt, es gibt ein Problem mit dem Zustand. Dies scheint komplizierter zu sein als ein asynchroner Ansatz.

Peter: Ich verstehe. Ich hatte diesen Gedanken im Kopf: Wenn wir die Anzahl der Benutzer erhöhen wollen. Wie würde der gesamte Anwendungsstapel von Symfony in der asynchronen Version gestartet und eine größere Anzahl von Verbindungen verarbeitet?

Sergey: Das würde ich nicht tun. Oft wird die Anwendung nicht vollständig verlangsamt. Wenn sich die Frage nach der Leistung stellt, gibt es höchstwahrscheinlich einige Engpässe im Inneren, die höchstwahrscheinlich auch zu langsamen E / A führen. Und jetzt würde ich diese Engpässe in ReactPHP übersetzen.

Es würde wie ein kleines asynchrones Programm innerhalb des üblichen Blockierungscodes aussehen: Zum Beispiel haben wir drei Anforderungen parallel aufgerufen, verarbeitet und eine Antwort an den Benutzer gesendet, und die Gesamtausführungszeit entspricht der Zeit der langsamsten Anforderung. Wenn wir im Fall des traditionellen Ansatzes auf die erste Anfrage, die zweite und die dritte warten würden. Die Anwendung wurde dadurch jedoch nicht asynchron.

Und wenn wir alles mit NodeJS und anderen vergleichen?

Peter: Und wenn wir alles mit NodeJS vergleichen, sagen wir mal oder Go, dann gibt es wirklich Asynchronität in der gesamten Anwendung. Alle Anforderungen an die Datenbank, an das Dateisystem - alle sind innerhalb asynchron. Bedeutet dies im Prinzip, wenn alles in asynchroner Form geschrieben ist, gibt es Gewinn?

Sergey: Es wird rentabel sein, wenn das anfängliche Problem I / O ist. Dann werden wir es ja lösen. Unser Code wird so effizient wie möglich sein und die maximale Anzahl von Aufgaben verarbeiten können, anstatt inaktiv zu sein und auf die Verarbeitung dieser Ausgabe zu warten. Wenn das Problem anfangs nicht in der E / A liegt und dann alles asynchron geschrieben wird, ist es unwahrscheinlich, dass wir etwas gewinnen, und wir können komplexen Code erhalten, der schwer zu lesen und zu warten ist.

Peter: Zurück zu PHP. Wir haben also ReactPHP und die berühmten Analoga Swoole, Amp und Ext-async. Und sagen Sie mir im Vergleich, was ist der Unterschied zwischen diesen Projekten und wie gut ist ReactPHP, ist es schnell und hat es irgendwelche Nachteile im Vergleich zu demselben Swoole?

Sergey: Um ehrlich zu sein, habe ich von allen dreien nur Amp getestet, und weil es wie ReactPHP sofort unterstützt wird. Das heißt, wir stellen die erforderlichen Komponenten durch den Komponisten und Sie sind fertig. Und hier mag ich Geschichten mit Erweiterungen nicht wirklich. Denn wenn wir mit PHP und Asynchronität allein sind, scheint es mir vernünftiger, die Sprache und native Dinge zu verwenden - und wenn wir zusätzliche Erweiterungen verwenden, dann ist hier nicht besonders asynchrones PHP, sondern asynchrone Erweiterungen für PHP.

Wie ReactPHP wirklich produktionsbereit?

Peter: "Langzeitunterstützung" steht auf ihrer Website. Das heißt, eine Art langfristige Unterstützung ohne kritische Änderungen an der API. Ist das so Ist alles hoch genug?

Sergey: Ja. Das ReactPHP-Projekt selbst ist bereits ziemlich alt. Er arbeitet seit dem zwölften Jahr, er ist 7 Jahre alt. Er hat schon genug produktionsbereite Zeit. Und ja, außerdem kommt hier die langfristige Unterstützung für die Hauptkomponenten für 2 Jahre. Das heißt, Sie können sicher an diese Komponenten gebunden sein, Korrekturen und Updates erhalten und sich keine Sorgen um die Abwärtskompatibilität machen. Zwei Jahre lang verpflichten sie sich, ihre Versionen zu pflegen, nichts wird kaputt gehen. Das finde ich wirklich sehr, sehr cool, das ist ein großer Schritt nach vorne. Soweit ich mich erinnere, hat Amp bis vor kurzem einige seiner Komponenten besprochen, sie haben sich jedoch nicht vollständig für die Schnittstelle und ihre öffentliche API entschieden.

Peter: Wo empfehlen Sie, ReactPHP zu lernen? Neben der offiziellen Dokumentation und Ihren Video-Tutorials natürlich. Wo sind alle Communities, gibt es Telegramm- oder Zwietracht-Chats, Foren?

Sergey: Leider kenne ich keine so direkte Community. Es gibt einen Twitter-Account, der ziemlich aktiv ist: Dort kann man fragen, Fragen stellen und interessiert sein. Und die Bergleute reagieren ziemlich schnell - Sie können ihnen persönlich auf Twitter schreiben. Ich tat es und bat sie um einige Dinge.



Peter: Nun, danke für eine so detaillierte Geschichte über ReactPHP - und in diesem Zusammenhang werde ich das Panda Meetup ankündigen, das am 22. August in Moskau im Skyeng-Büro stattfinden wird. Du wirst dort auftreten, richtig?

Sergey: Ja, das stimmt. Komm und plaudere.

Peter: Es wird auch einen Bericht über Domain Driven Design geben, der auch im Zusammenhang mit PHP ein cooles interessantes Thema ist [und ein paar weitere wurden hinzugefügt], und wie die Organisatoren mir sagten, wird es eine Afterparty geben.

Goodies:

• Vollständige Audio- und YouTube- Podcast- Version
• Link zum Broadcast Mitap für diejenigen, die nicht kommen können
• Details zur Afterparty im Telegramm BeerPHP Moskau