A aplicação esta lenta, e a culpa é nossa!
Recentemente, participei de um meetup como palestrante, quis apresentar alguns dos vários motivos de uma aplicação estar lenta, tentando levar as pessoas a refletir se realmente a tecnologia é a culpada.
Lembrando que a opinião que expressei no momento da palestra pode mudar no decorrer do tempo, afinal, estou sempre reavaliando o meu ponto de vista sobre este assunto :D
Gravei, por conta, ficou bom o suficiente para compartilhar :D
Algumas mensagens que talvez não ficou tão clara:
- Não culpe a linguagem antes de comprovar que a tecnologia é a culpada, normalmente há maneiras de melhorar;
- Não use apenas a sua percepção de lentidão, entenda oque acontece e porque acontece a lentidão;
- Entenda as decisões que foram tomadas na hora de começar a construir a aplicação
- Faça seus experimentos, provas de conceitos
- Onde está a ciência nos cientistas da computação?
- Normalmente o consenso falha frente a estatística
- Leia o livro: Um livro ilustrado de maus argumentos
Vou acrescentar aqui, que o GraalVM tem sido melhor do que a OpenJ9 em meus testes.
[Adicionado em: 01/01/2020]
A algum tempo venho observando pessoas procurando alternativas a o modelo de “service discovery” e “loadbalancing”, principalmente quando se trata de “non blocking io”. Eis que me aparece o ServiceTalk pra ficar de olho
Outro ponto interessante, é sobre como ganhar performance com o paradigma asyncrono, uma das mais antigas é o processamento de jobs em background, e me apareceu para leitura o Dynein, da Airbnb, que implementa uma estratégia interessante de parelilizar jobs.
Acredito que seja interessante dar uma olhada em benchmarks para entender um pouco mais sobre o assunto, particularmente recomendo este: https://www.techempower.com/benchmarks/.
Neste benchmark você encontra um lista das bibliotecas, e frameworks, organizado por linguagem e performance. Beeeeem, interessante pra você comparar a sua stack com outras possibilidades.
Sempre avalie as dependêndias transitivas do seu projeto, por exemplo ao utilizar o zipkin em um projeto Spring boot provávelmente você terá a biblioteca que envia para kafka e rabbitmq já inclusa no projeto, mas, se você não precisa dele, porque deixar ela ir para produção e deixar tudo mais lento pra sua aplicação?
Leia também…
