RubyRussia 2019. Julian Pokrovsky: comment optimiser un monolithe

Malgré l'énorme quantité de documents sur le thème de l'optimisation des monolithes, je veux souvent m'éloigner de l'étude approfondie du problème et essayer de deviner comment rendre l'application plus rapide ou plus compacte. La bonne nouvelle: le principe de Pareto fonctionne ici. Lors de la conférence RubyRussia du 28 septembre, Julian Pokrovsky parlera des techniques nécessaires. Quelques teasers seront dans cette interview avec Julian et Grigory Petrov .



Que faites-vous dans le monde de l'informatique, Ruby, vos intérêts, votre expertise?

Je travaille à Cupill. Dans le projet, j'ai écrit en Ruby et sur le backend Rust pour rechercher, réserver et acheter des billets d'avion. Je m'intéresse à un large éventail de ce qui se passe dans l'informatique: des compilateurs aux systèmes distribués. Pas vraiment intéressé par l'apprentissage automatique et le front-end, mais peut-être qu'un jour j'y arriverai aussi.

Dites-moi de quoi parle votre rapport?

Je vais raconter notre expérience dans l'optimisation d'un monolithe de 8 ans et montrer qu'il est très simple et bénéfique pour tout le monde. Et il est possible d'allouer du temps pour cela dans le sprint. Vous pouvez obtenir une amélioration des performances en examinant quelques astuces et outils simples qui ne nécessitent pas de Rails et conviennent non seulement à une application Web. Je vais vous parler du matériel que nous avons guidé pour résoudre nos problèmes. Examinons stackprof, rbspy, heapy, et aussi pourquoi des modifications triviales des paramètres du système d'exploitation, en changeant l'allocateur, peuvent apporter des avantages incroyables. Et pourquoi est-il mauvais d'appliquer des conseils sur Internet sans prendre de mesures sur votre application.

Il y a une telle légende urbaine que si nous comparons les langages des Big Four (Ruby, Python, JavaScript et PHP), alors en premier lieu nous avons JS, car il attend et jit, dans le deuxième PHP, puis Python, et Ruby prend l'honorable 4e Que dites-vous, est-ce le cas?

Je ne suis pas enclin à nier que Ruby ne fonctionne pas bien sur de nombreux benchmarks. Mais ce n'est certainement pas juste de dire que dans n'importe quelle situation, il sera à la dernière place. Plus largement, Ruby est une norme de langage. Nous pouvons parler de TruffleRuby, de JRuby, de l'IRM, des problèmes de performances. Ce sont des choses très individuelles. Tout dépend de la façon dont vous avez écrit le code et de ce que vous vouliez obtenir. Dans certains cas, Ruby sera plus rapide que n'importe qui, dans certains Python, non sans raison qu'il est populaire en science des données, parfois JavaScript sera le plus rapide.

Dans quelle mesure l'écosystème Ruby offre-t-il désormais des moyens rapides et natifs de résoudre les problèmes courants?

Je peux interpréter la question différemment. Vous pouvez parler de la situation actuelle avec les extensions C dans Ruby. Si nous limitons la question à cela, alors nous savons tous: OJ pour la sérialisation JSON, pilote PostgreSQL, pilote Ruby pour MySQL et bien d'autres choses sont écrites en C.La question est de savoir à quel point c'est bon ou mauvais pour moi personnellement. Pour que les compilateurs jit, qui peuvent être l'avenir de Ruby, optimisent bien le code, nous devons écrire plus dans Ruby et utiliser moins d'étendue. Pour que le compilateur puisse le faire. TruffleRuby a une approche différente à cela. Pour autant que je m'en souvienne, il vous permet de faire une optimisation entre différentes langues, donc il s'appelle polyglot vm. Encore une fois, avec quel succès il le fait, je ne suis pas prêt à dire. Et TruffleRuby lui-même est encore un projet assez jeune.

Quelles sont les avancées dans le monde Ruby pour la programmation asynchrone?

À mon avis, aucun mouvement de masse récent vers le Ruby asynchrone ne s'est produit. Il existe des projets distincts: le projet éprouvé EventMachine et le projet Sam Williams, async , ou plutôt tout un groupe de projets dans lesquels une nouvelle implémentation asynchrone est faite sur la base de nio4r , qui est plus simple que EventMachine ou Celluloid. Mais en général, l'histoire, bien qu'elle ne reste pas immobile, marche plutôt en petit cercle. Et jusqu'à présent, rien n'est allé au-delà. Voyons ce qui se passe ensuite.

Je vois toujours beaucoup d'utilisation basée sur des threads rubis simultanés. Ce n'est pas une si mauvaise option pour une langue avec un runtime modérément productif - utilisez des flux qui libèrent GVL (verrouillage global) et vous permettent de faire des requêtes HTTP parallèles ou d'autres opérations d'E / S en même temps. Peut-être que la fibre à l'avenir sera plus populaire. Ils constituaient désormais la base de la bibliothèque du groupe effets secs-secs. Cela vous permet simplement d'effectuer des opérations parallèles basées sur la fibre. Pas de manière synchrone, mais pas entièrement asynchrone - déjà à moitié asynchrone.

Matsumoto-san, l'auteur de Ruby, s'envole pour la conférence. Que pensez-vous qu'il serait intéressant pour vous de discuter avec lui autour d'une tasse de café ou d'un verre de saké à l'afterparty?

J'ai déjà vu Matsumoto à Moscou en 2016. Je me souviens, il a ensuite dit que si la conférence continuait de s'appeler RailsClub, il ne reviendrait pas.

Oui, et il a été renommé RubyRussia, c'est un nom plus large. Et il nous rend de nouveau visite.

J'ai alors pensé qui gagnerait, lui ou RailsClub. Matsumoto bat. Je voudrais savoir comment il a réussi à soulever la question de telle manière qu'ils ont renommé le plus grand événement Ruby en Russie.

Je pense que vous aurez toutes les chances de poser cette question personnellement. Quel est l'avenir de Ruby? Qu'est-ce qui vous manque dans la langue, l'écosystème?

Prédire le sort d'un langage de programmation est une tâche ingrate, car jusqu'à présent, personne n'a deviné comment les événements se développeront pour n'importe quel langage. Je peux me tromper, mais Ruby n'est pas le choix le plus populaire pour les nouveaux projets en ce moment. Beaucoup ont entendu "Ruby est mort, mais Rails est déconseillé": il est lent, non asynchrone, il n'est pas parallèle et il a tout un tas de problèmes. Cela affecte-t-il le nombre de nouveaux projets Ruby? À mon avis, certainement oui. Ils deviennent plus petits et deviendront encore plus petits. Mais les vieux projets restent. À mon avis, Ruby a ainsi besoin d'outils pour prendre en charge des applications complexes et massives. Dans de telles situations, c'est une bonne idée de regarder des ajouts comme le système de type. Beaucoup de gens préfèrent prendre en charge de grandes applications et les développer, comme nous pouvons le voir avec JavaScript avec Flow et TypeScript, vers la saisie, ce qui facilite un peu la refactorisation et la surveillance d'une situation dans un projet complexe. Vous devez peut-être créer un écosystème plus riche de bibliothèques que vous devez utiliser indépendamment, comme dry-rb. Où une personne peut choisir ce dont elle a besoin pour valider, quoi créer des effets dans un sous-système. Peut-être qu'il a besoin de conteneurs d'injection de dépendance qui résolvent certains problèmes. L'écosystème devrait évoluer dans cette direction. Dans le sens du développement de l'entreprise et du support de systèmes vastes et complexes.

Discutez sur RubyRussia!

Venez et vous, l' inscription est toujours ouverte.

Il y aura non seulement des rapports, mais aussi des stands d'entreprises sympas:

Organisateur - Evrone
Associé commandité - Toptal
Partenaire Gold - Gett
Partenaires Silver - Valarm , JetBrains , Bookmate et Cashwagon
Partenaire Bronze - InSales