RubyRussia 2019. Julian Pokrovsky: Wie man einen Monolithen optimiert

Trotz der großen Menge an Materialien zum Thema Monolithoptimierung möchte ich mich oft nicht eingehend mit dem Thema befassen und versuchen zu erraten, wie die Anwendung schneller oder kompakter werden kann. Die gute Nachricht: Hier funktioniert das Pareto-Prinzip. Auf der RubyRussia- Konferenz am 28. September wird Julian Pokrovsky über die notwendigen Techniken sprechen. In diesem Interview mit Julian und Grigory Petrov werden einige Teaser zu sehen sein.



Was machen Sie in der IT-Welt, Ruby, Ihre Interessen, Ihr Fachwissen?

Ich arbeite in Cupill. In dem Projekt schrieb ich in Ruby und im Rust-Backend für das Suchen, Buchen und Kaufen von Flugtickets. Ich interessiere mich für eine breite Palette von Ereignissen in der IT: von Compilern bis zu verteilten Systemen. Ich bin nicht wirklich an maschinellem Lernen und Frontend interessiert, aber vielleicht werde ich eines Tages auch dorthin gelangen.

Sag mir, worum geht es in deinem Bericht?

Ich werde über unsere Erfahrungen bei der Optimierung eines 8 Jahre alten Monolithen berichten und zeigen, dass dies für alle sehr einfach und vorteilhaft ist. Und dafür besteht im Sprint die Möglichkeit, Zeit dafür einzuplanen. Sie können eine Leistungssteigerung erzielen, indem Sie sich nur einige einfache Tricks und Tools ansehen, für die keine Rails erforderlich sind und die nicht nur für eine Webanwendung geeignet sind. Ich erzähle Ihnen von den Materialien, die wir bei der Lösung unserer Probleme geführt haben. Schauen wir uns stackprof, rbspy, heapy an und auch, warum triviale Änderungen an den Betriebssystemeinstellungen und das Ändern des Allokators unglaubliche Vorteile bringen können. Und warum ist es schlecht, Ratschläge aus dem Internet anzuwenden, ohne Messungen an Ihrer Bewerbung vorzunehmen?

Es gibt eine solche urbane Legende, dass, wenn wir die Sprachen der Big Four (Ruby, Python, JavaScript und PHP) vergleichen, wir an erster Stelle JS haben, weil dort warten und jit, an zweiter Stelle PHP, dann Python und Ruby den ehrenwerten vierten Platz einnehmen Ort. Was sagst du, ist das so?

Ich bin nicht geneigt zu leugnen, dass Ruby bei vielen Benchmarks nicht gut abschneidet. Aber es ist definitiv nicht richtig zu sagen, dass er in jeder Situation auf dem letzten Platz sein wird. Im weiteren Sinne ist Ruby ein Sprachstandard. Wir können über TruffleRuby, über JRuby, über MRT und über Leistungsprobleme sprechen. Das sind sehr individuelle Dinge. Es hängt alles davon ab, wie Sie den Code geschrieben haben und was Sie bekommen wollten. In einigen Fällen ist Ruby schneller als jeder andere, in einigen Pythons nicht ohne Grund in der Datenwissenschaft beliebt, manchmal ist JavaScript am schnellsten.

Inwieweit bietet das Ruby-Ökosystem jetzt schnelle, native Möglichkeiten zur Lösung beliebter Probleme?

Ich kann die Frage anders interpretieren. Sie können jetzt darüber sprechen, wie die Dinge mit C-Erweiterungen in Ruby sind. Wenn wir die Frage darauf eingrenzen, wissen wir alle: OJ für JSON-Serialisierung, PostgreSQL-Treiber, Ruby-Treiber für MySQL und viele andere Dinge sind in C geschrieben. Die Frage ist, wie gut oder schlecht es für mich persönlich ist. Damit JIT-Compiler, die möglicherweise die Zukunft von Ruby darstellen, den Code gut optimieren können, müssen wir mehr in Ruby schreiben und weniger Extents verwenden. Damit der Compiler dies tun kann. TruffleRuby verfolgt hier einen anderen Ansatz. Soweit ich mich erinnere, können Sie damit zwischen verschiedenen Sprachen optimieren. Daher wird es als polyglot vm bezeichnet. Wie erfolgreich er dies tut, kann ich nicht sagen. Und TruffleRuby selbst ist noch ein ziemlich junges Projekt.

Welche Fortschritte in der Ruby-Welt gibt es für die asynchrone Programmierung?

Meiner Meinung nach hat in letzter Zeit keine Massenbewegung in Richtung asynchroner Ruby stattgefunden. Es gibt einige separate Projekte: sowohl das bewährte EventMachine- als auch das Sam Williams-Projekt, async , oder vielmehr eine ganze Gruppe von Projekten, bei denen eine neue asynchrone Implementierung basierend auf nio4r vorgenommen wird , was einfacher als EventMachine oder Celluloid ist. Aber im Allgemeinen geht die Geschichte, obwohl sie nicht stillsteht, eher in einem kleinen Kreis. Und bisher ist nichts darüber hinausgegangen. Mal sehen, was als nächstes passiert.

Ich sehe immer noch eine Menge von gleichzeitig auf Rubinen basierenden Threads. Dies ist keine so schlechte Option für eine Sprache mit einer mäßig produktiven Laufzeit. Verwenden Sie Streams, die GVL (Global Lock) freigeben und es Ihnen ermöglichen, parallele HTTP-Anforderungen oder andere E / A-Vorgänge gleichzeitig auszuführen. Vielleicht wird Faser in Zukunft populärer sein. Sie bildeten nun die Grundlage der Bibliothek aus der Gruppe der Trockeneffekte. Auf diese Weise können Sie nur einige parallele Operationen basierend auf Glasfaser ausführen. Nicht synchron, aber nicht ganz asynchron - schon halb asynchron.

Mr. Matsumoto, der Autor von Ruby, fliegt zur Konferenz. Was denkst du, wäre es interessant für dich, bei der Afterparty bei einer Tasse Kaffee oder einem Glas Sake mit ihm zu diskutieren?

Ich habe Matsumoto bereits 2016 in Moskau gesehen. Ich erinnere mich, er sagte dann, wenn die Konferenz weiterhin RailsClub heißt, würde er nicht wiederkommen.

Ja, und es wurde in RubyRussia umbenannt. Dies ist ein weiter gefasster Name. Und er besucht uns wieder.

Ich dachte dann, wer gewinnen würde, er oder RailsClub. Matsumoto besiegt. Ich würde fragen, wie er es geschafft hat, die Frage so zu stellen, dass sie das größte Ruby-Ereignis in Russland umbenannten.

Ich denke, Sie werden jede Gelegenheit haben, diese Frage persönlich zu stellen. Was ist die Zukunft von Ruby? Was fehlt dir an Sprache, Ökosystem?

Das Schicksal einer Programmiersprache vorherzusagen, ist eine undankbare Aufgabe, da bisher niemand erraten hat, wie sich Ereignisse für eine Sprache entwickeln werden. Ich könnte mich irren, aber Ruby ist derzeit nicht die beliebteste Wahl für neue Projekte. Viele haben gehört, "Ruby ist tot, aber Rails ist veraltet": Es ist langsam, nicht asynchron, es ist nicht parallel und es gibt eine ganze Reihe von Problemen. Beeinflusst dies die Anzahl neuer Ruby-Projekte? Meiner Meinung nach definitiv ja. Sie werden kleiner und werden noch kleiner. Aber alte Projekte bleiben. Meiner Meinung nach benötigt Ruby auf diese Weise Tools, um komplexe, massive Anwendungen zu unterstützen. In solchen Situationen ist es eine gute Idee, Ergänzungen wie das Typsystem zu betrachten. Viele Menschen bevorzugen es, große Anwendungen zu unterstützen und zu entwickeln, wie wir in JavaScript mit Flow und TypeScript sehen können, um zu tippen, was das Refactoring und die Überwachung einer Situation in einem komplexen Projekt ein wenig erleichtert. Möglicherweise müssen Sie ein reichhaltigeres Ökosystem von Bibliotheken erstellen, die Sie unabhängig voneinander verwenden müssen, z. B. dry-rb. Wo eine Person auswählen kann, was sie validieren muss, was Effekte in einem Subsystem erzeugen sollen. Vielleicht braucht er Abhängigkeitsinjektionsbehälter , die bestimmte Probleme lösen. Das Ökosystem sollte sich in diese Richtung bewegen. In Richtung Unternehmensentwicklung und Unterstützung großer und komplexer Systeme.

Diskutieren Sie über RubyRussia!

Komm und du, die Registrierung ist noch offen.

Es wird nicht nur Berichte geben, sondern auch Stände cooler Unternehmen:

Veranstalter - Evrone
Komplementärin - Toptal
Gold Partner - Gett
Silberpartner - Valarm , JetBrains , Bookmate und Cashwagon
Bronze Partner - InSales