O que não te dizem sobre performance e escalabilidade

Já reparou que a maior parte das conversas que envolvam as palavras “performance” e “escalabilidade” terminam no vácuo?  Normalmente a certeza vêm quando topo com perguntas do tipo: “X é rápido?”, “X é mais rápido que Y?”, “X escala?”, “Quem escala melhor, X ou Y?”. Há ausências nestas perguntas sobre as quais quero falar aqui.

Primeira ausência: o referencial

As perguntas que citei acima são incompletas por que não nos dizem qual o objetivo. Meu código precisa ser rápido para atingir uma meta. Por exemplo: sei que este blog irá receber X acessos/dia. Qual plataforma consegue isto da melhor forma possível?

O assustador é a imensa bibliografia existente hoje que não inclui referencial algum. Não sei se já repararam, mas toda nova plataforma de desenvolvimento que surge se vende como a mais rápida, mais eficiente, mais escalável, mas simplesmente não te dizem pra que. Vou lidar com dados textuais, Perl é excelentemente performático, mas será que pra lidar com transações também? Pense um pouco: por que não te mostram estes referenciais quando surge algo novo? Te respondo: por que reduz a aplicabilidade do que está sendo oferecido. Simples assim.

Segunda ausência: o referencial que represente minha realidade

E aí eu topo com benchmarks que parecem lindos em um primeiro momento (especialmente quando usados para justificar a sua escolha), mas que ao levarmos para o mundo real, ou seja, o seu dia a dia, não significam coisa alguma.

Como é a sua realidade? Aposto que não faz parte dela ficar implementando algoritmos de solução de sudokus, fibonacci, etc. Também aposto que seus sistemas não são compostos por uma única tabela na qual fica inserindo registros randômicos. É? Se for, que mundo interessante este no qual vive hein?

Referenciais significativos dizem respeito ao problema que você precisa resolver. Imagine que seu objetivo é desenvolver um sistema de envio de spam. No que um algoritmo de Fibonacci influencia seu trabalho? O que te interessa é ter um servidor de envio de e-mails de alto desempenho.

Terceira ausência: benchmarks honestos

A maior parte dos benchmarks que encontro na Internet são desonestos, talvez por que quem os escreve apenas acha que sabe sobre o que está falando. Vou dar dois exemplos comuns.

Benchmarks de SGBDs, especialmente os que comparam bases relacionais e não relacionais: como você vai comparar maçãs com laranjas? Pense no universo NoSQL: há inúmeros paradigmas ali como, por exemplo, baseado em documentos, chave-valor, grafos, colunares, etc. Cada um destes modelos é criado objetivando resolver problemas diferentes. Nada mais natural que um SGBD chave-valor encontre um registro por identificador mais rápido que um baseado em grafos, concorda? Se sim, qual a honestidade intelectual por trás de uma comparação entre o Neo4J e o Redis na busca por chave primária?

Benchmarks de linguagens de programação: se você que está escrevendo o benchmark é mais experiente na linguagem X, que garantia o leitor tem de que o código escrito na linguagem Y seja igualmente bem escrito? Ainda pior: você irá ver em inúmeros casos linguagens sendo levadas para contextos completamente diferentes daqueles para os quais foram criadas e consequentemente tirando os piores resultados nestes testes. Groovy para desenvolver sistemas hard real time?

(não existe linguagem ou SGBD ruim, mas sim uso equivocado, o que não é argumento suficiente para invalidar uma tecnologia)

O benchmark é honesto quando o escopo é bem definido, os testes foram executados por pessoas que conheçam a tecnologia e, ainda mais importante: que os participantes da comparação estejam todos sendo aplicados em situações nas quais se apliquem.

Quarta ausência: diversidade

Esta ausência se manifesta em perguntas deste tipo: “Kico, qual framework é mais rápido: X ou Y?”. O framework é apenas um dos componentes do desenvolvimento de uma solução. Entram no projeto o SGBD(s), servidor de aplicações, sistema operacional, protocolos de comunicação, etc. A combinação de todos estes levam ao desempenho ideal para seu projeto, não um componente isolado.

Exemplo de frase que já ouvi: “PHF (Power Hipster Framework) é de longe o framework que oferece maior escalabilidade no desenvolviento de aplicações web”. Ok: qual o SGBD usado? Qual o sistema operacional? Para qualquer tipo de aplicação web ou a interface web é apenas um dos componentes do seu sistema?

Para falar algo real sobre desempenho e escalabilidade, um elemento isolado nada diz. Tem de dizer também com o que a coisa se relaciona bem ou não.

Quinta ausência: cases próximos da minha realidade

Tem a ver com a segunda ausência que citei, mas é diferente. Aqui vêm um exemplo: “Node.js é excelente e você deve usar, pois o Linkedin usou e foi um sucesso”.

Que bom que o Linkedin teve sucesso! Agora: seu sistema é feito para resolver os mesmos problemas que o seu sistema? Se você desenvolve um sistema de controle de estoque, por que prestar atenção em casos de sucesso do Google, Linkedin, Apple, etc? Você tem de olhar são cases de empresas como TOTVS que também desenvolvem sistemas parecidos com o seu.

Quando ouço falar de escalabilidade vejo muita bobagem sendo dita nestes comparativos. Uma coisa é você resolver problemas que envolvam uma ou duas dezenas de servidores no máximo (99% dos casos você vai ter menos de dez). Outra completamente diferente lidar com centenas e milhares. E sabem o que é mais legal? A solução aplicada a milhares de nós na maior parte das vezes não é eficiente em pequena escala. :)

Um case só faz sentido se o problema resolvido for o mesmo ou próximo de você.

Sexta ausência: fatores econômicos

Deixei por última a ausência que considero ser a mais grave. Quando falamos de desempenho e escalabilidade na realidade estamos tratando de fatores econômicos e duas das principais perguntas que devem estar por trás de todo projeto. O investimento inicial no projeto e implementação da solução vale à pena (CAPEX)? O custo de manutenção e evolução do sistema após sua implementação é viável (OPEX)?

Vou lhes dar um exemplo real: em um mundo pós cloud como o que temos hoje, no qual se paga por processamento, por que não implementamos nossos sistemas web inteiramente em C já que esta é uma das linguagens mais eficientes já criadas?

(ignore por um momento a razão de que não se deve ver o mundo inteiro como um prego só por que você só tem um martelo e a quarta razão que citei acima)

Fiquei um bom tempo analisando esta possibilidade. Me parecia uma excelente idéia de negócio. Por que não? A primeira razão é que não há muitas opções de frameworks hoje para isto (eu poderia usar CGI, mas não valeria tanto à pena) capazes de lidar com a complexidade deste tipo de projeto. Era grande a probabilidade de eu desenvolver meu próprio framework. Isto aumentaria o custo. Ainda pior: eu reinventaria a roda inúmeras vezes.  O custo era inviável.

Outro exemplo: sua equipe é ultra experiente com a linguagem X. Existe uma outra, digamos, Y, que seja mais eficiente para o seu problema. Será que o custo de treinamento e adaptação da sua equipe compensa a mudança?

A quinta ausência cai aqui: os cases avaliados devem ser próximos da sua capacidade financeira. Do que adianta se espelhar na Netflix que lida com data centers que você pode apenas sonhar? A lógica de custo não é a mesma em qualquer escala. Os valores não crescem linearmente, mas curiosamente ninguém fala disto, não é mesmo?

A métrica ideal para desempenho e escalabilidade se chama dinheiro. Quanto custa seu processamento mensal?