RubyRussia 2019. Julian Pokrovsky: como otimizar um monólito

Apesar da enorme quantidade de materiais sobre o tema da otimização de monólitos, muitas vezes queremos fugir do estudo aprofundado do problema e tentar adivinhar como tornar o aplicativo mais rápido ou mais compacto. A boa notícia: o princípio de Pareto funciona aqui. Na conferência RubyRussia , em 28 de setembro, Julian Pokrovsky falará sobre as técnicas necessárias. Alguns teasers estarão nesta entrevista com Julian e Grigory Petrov .



O que você faz no mundo da TI, Ruby, seus interesses, experiência?

Eu trabalho em Cupill. No projeto, escrevi em Ruby e no back-end do Rust para pesquisar, reservar e comprar passagens aéreas. Estou interessado em uma ampla gama do que está acontecendo em TI: de compiladores a sistemas distribuídos. Não estou realmente interessado em aprendizado de máquina e front-end, mas talvez um dia eu chegue lá também.

Diga-me sobre o que é o seu relatório.

Vou contar sobre a nossa experiência na otimização de um monólito de 8 anos e mostrar que é muito simples e benéfico para todos. E há uma oportunidade de alocar tempo para isso no sprint. Você pode obter um aumento de desempenho entendendo apenas alguns truques e ferramentas simples que não exigem o Rails e são adequados não apenas para aplicativos da Web. Vou falar sobre os materiais que fomos guiados ao resolver nossos problemas. Vejamos stackprof, rbspy, heapy e também por que alterações triviais nas configurações do sistema operacional, alterando o alocador, podem trazer benefícios incríveis. E por que é ruim aplicar conselhos da Internet sem fazer medições em seu aplicativo?

Existe uma lenda urbana que, se compararmos as linguagens dos Big Four (Ruby, Python, JavaScript e PHP), em primeiro lugar, temos JS, porque aguardamos e jit, no segundo PHP, em seguida, Python, e Ruby leva o honorável quarto lugar. O que você diz, é isso?

Não estou inclinado a negar que Ruby não tenha um bom desempenho em muitos benchmarks. Mas definitivamente não é certo dizer que, em qualquer situação, ele estará em último lugar. Mais amplamente, Ruby é um padrão de idioma. Podemos falar sobre o TruffleRuby, sobre o JRuby, sobre a ressonância magnética, sobre questões de desempenho. Essas são coisas muito individuais. Tudo depende de como você escreveu o código e o que queria obter. Em alguns casos, Ruby será mais rápido do que qualquer um, em alguns Python, não sem razão, é popular na ciência de dados; às vezes, o JavaScript será o mais rápido.

Até que ponto o ecossistema Ruby agora oferece maneiras rápidas e nativas de resolver problemas populares?

Eu posso interpretar a pergunta de maneira diferente. Você pode falar sobre como estão as extensões C no Ruby agora. Se restringirmos a questão a este ponto, todos saberemos: OJ para serialização JSON, PostgreSQL Driver, Ruby Driver para MySQL e muitas outras coisas estão escritas em C. A questão é quão bom ou ruim é para mim pessoalmente. Para que os compiladores jit, que podem ser o futuro do Ruby, otimizem bem o código, precisamos escrever mais em Ruby e usar menos extensões. Para que o compilador possa fazer isso. O TruffleRuby tem uma abordagem diferente para isso. Tanto quanto me lembro, ele permite que você faça a otimização entre diferentes idiomas, portanto, é chamado polyglot vm. Novamente, com que sucesso ele faz isso, não estou pronto para dizer. E o próprio TruffleRuby ainda é um projeto bastante jovem.

Que avanços no mundo Ruby existem para a programação assíncrona?

Na minha opinião, nenhum movimento recente de massas em direção ao Ruby assíncrono ocorreu. Existem alguns projetos separados: o projeto comprovado EventMachine e Sam Williams, assíncrono , ou melhor, um grupo inteiro de projetos nos quais uma nova implementação assíncrona é feita com base no nio4r , que é mais simples que o EventMachine ou o Celluloid. Mas, em geral, a história, embora não fique parada, caminha em um pequeno círculo. E até agora nada foi além disso. Vamos ver o que acontece a seguir.

Eu ainda vejo muito uso baseado em encadeamento em ruby ​​simultâneo. Essa não é uma opção tão ruim para um idioma com um tempo de execução moderadamente produtivo - use fluxos que liberam GVL (bloqueio global) e permitem fazer solicitações HTTP paralelas ou algumas outras operações de E / S ao mesmo tempo. Talvez a fibra no futuro seja mais popular. Eles agora formaram a base da biblioteca a partir do grupo efeitos secos. Isso apenas permite que você faça algumas operações paralelas baseadas em fibra. Não de forma síncrona, mas não totalmente assíncrona - já meio assíncrona.

Matsumoto-san, autor de Ruby, voa para a conferência. O que você acha que seria interessante discutir com ele sobre uma xícara de café ou um copo de saquê no pós-festa?

Eu já vi Matsumoto em Moscou em 2016. Lembro que ele disse que, se a conferência continuar a se chamar RailsClub, ele não voltaria.

Sim, e foi renomeado RubyRussia, este é um nome mais amplo. E ele está nos visitando novamente.

Então pensei em quem venceria, ele ou o RailsClub. Matsumoto derrotou. Gostaria de perguntar como ele conseguiu levantar a questão de tal maneira que eles renomearam o maior evento de Ruby na Rússia.

Eu acho que você terá todas as oportunidades para fazer essa pergunta pessoalmente. Qual é o futuro do Ruby? O que falta na linguagem, ecossistema?

Prever o destino de uma linguagem de programação é uma tarefa ingrata, porque até agora ninguém adivinhou como os eventos se desenvolveriam para qualquer linguagem. Eu posso estar errado, mas Ruby não é a escolha mais popular para novos projetos no momento. Muitos ouviram dizer que "Ruby está morto, mas o Rails está obsoleto": é lento, não assíncrono, não é paralelo e tem muitos problemas. Isso afeta o número de novos projetos Ruby? Na minha opinião, definitivamente sim. Eles estão se tornando menores e se tornarão ainda menores. Mas projetos antigos permanecem. Na minha opinião, dessa forma, o Ruby precisa de ferramentas para suportar aplicativos complexos e massivos. Em tais situações, é uma boa ideia considerar adições como o sistema de tipos. Muitas pessoas preferem dar suporte a aplicativos grandes e desenvolvê-los, como podemos ver no JavaScript com Flow e TypeScript, para digitar, o que facilita a refatoração e o monitoramento de uma situação em um projeto complexo. Talvez você precise criar um ecossistema mais rico de bibliotecas que precise usar de forma independente, como dry-rb. Onde uma pessoa pode escolher o que precisa validar, o que criar efeitos em algum subsistema. Talvez ele precise de contêineres de injeção de dependência que resolvam certos problemas. O ecossistema deve se mover nessa direção. Na direção do desenvolvimento empresarial e suporte de sistemas grandes e complexos.

Discuta sobre RubyRussia!

Venha e você, as inscrições ainda estão abertas.

Não haverá apenas relatórios, mas também estandes de empresas legais:

Organizador - Evrone
Parceiro Geral - Toptal
Parceiro Gold - Gett
Parceiros Silver - Valarm , JetBrains , Bookmate e Cashwagon
Parceiro Bronze - InSales