{"id":1618,"date":"2016-11-17T14:28:39","date_gmt":"2016-11-17T16:28:39","guid":{"rendered":"https:\/\/blog.umbler.com\/?p=1618"},"modified":"2018-12-10T12:24:09","modified_gmt":"2018-12-10T14:24:09","slug":"2-como-aperfeicoar-velocidade-de-seu-site-back-end","status":"publish","type":"post","link":"https:\/\/blog.umbler.com\/br\/2-como-aperfeicoar-velocidade-de-seu-site-back-end\/","title":{"rendered":"#2 Como aperfei\u00e7oar a velocidade de seu site: back-end"},"content":{"rendered":"

Em meu post anterior<\/a>, falei de dois t\u00f3picos de suma import\u00e2ncia quando o assunto \u00e9 deixar nossos sites mais r\u00e1pidos: lat\u00eancia e front-end. Hoje, falarei de outro item important\u00edssimo: back-end!<\/p>\n

Enquanto a maioria dos problemas de carregamento atuais s\u00e3o culpa de a) sites hospedados no exterior e b) sites com uma tonelada de recursos (plugins, imagens, estilos, v\u00eddeos, etc), existem muitas coisas que ainda podemos fazer nos “bastidores” do nosso site para torn\u00e1-lo um canh\u00e3o.<\/p>\n

Claro que estas altera\u00e7\u00f5es no lado do servidor variam de plataforma para plataforma, de linguagem de programa\u00e7\u00e3o para linguagem de programa\u00e7\u00e3o. Dicas de performance para C# podem variar enormemente das dicas para PHP, o mesmo para Java vs. NodeJS, s\u00f3 para citar alguns exemplos.<\/p>\n

Sendo assim, tentarei focar em conceitos mais gen\u00e9ricos e abrangentes, sem entrar no detalhe de “programming hacks” e tunning de aplica\u00e7\u00f5es na linguagem X ou Y. Al\u00e9m disso, muito provavelmente, as dicas deste post far\u00e3o mais sentido para desenvolvedores de sistemas web, e n\u00e3o para desenvolvedores de sites, uma vez que backends complexos geralmente n\u00e3o s\u00e3o necess\u00e1rios em sites comuns.<\/p>\n

Dica 1: Mantenha seu projeto atualizado<\/h2>\n

Voc\u00ea costuma acompanhar as release notes (tamb\u00e9m chamado de changelogs) da sua linguagem de programa\u00e7\u00e3o favorita?
\nNas release notes \u00e9 que os engenheiros respons\u00e1veis pelas linguagens dizem o que foi alterado de uma vers\u00e3o pra outra. E, se tem um item muito recorrente, s\u00e3o as melhorias de performance. Sempre \u00e9 comum ver tanto melhorias gerais na performance, quanto melhorias em pontos espec\u00edficos, que estavam com problemas de desempenho.<\/p>\n

Um exemplo \u00e9 esse changelog do PHP 7<\/a>.<\/p>\n

Procure pela palavra performance que voc\u00ea ver\u00e1, na data deste post, tr\u00eas men\u00e7\u00f5es a ajustes de performance.<\/p>\n

Ou seja, estando atualizado com a sua linguagem de programa\u00e7\u00e3o, seu sistema opera com o melhor desempenho b\u00e1sico poss\u00edvel. Claro, grandes mudan\u00e7as de vers\u00f5es (geralmente no primeiro ou segundo n\u00famero da vers\u00e3o, dependendo da linguagem) podem acarretar em um estudo mais aprofundado para fazer a mudan\u00e7a, pois, \u00e0s vezes, alguns comandos somem e outros tomam o seu lugar, bem como configura\u00e7\u00f5es de ambiente.<\/p>\n

Dica 2: Deixe parte da responsabilidade com o front-end<\/h2>\n

“Como assim, no post anterior voc\u00ea n\u00e3o falou que 80% do tempo de carregamento das p\u00e1ginas \u00e9 culpa do front-end? E agora quer que eu coloque mais coisas l\u00e1?”<\/p><\/blockquote>\n

Sim. E n\u00e3o!<\/p>\n

Usar o front-end para processar algumas coisas, as coisas corretas, faz muito bem \u00e0 performance geral da sua aplica\u00e7\u00e3o. Com a escala da web atual, voc\u00ea jamais conseguir\u00e1 ter um servidor com todo o poder suficiente para atender aos seus usu\u00e1rios rapidamente processando tudo nele. Voc\u00ea ter\u00e1 de aprender a usar tecnologias mais responsivas, ass\u00edncronas e n\u00e3o-bloqueantes, como Ajax e Web Sockets, para dar ao usu\u00e1rio o que ele deseja, na hora que ele deseja e sem sobrecarregar seu back-end.<\/p>\n

Scripts de constru\u00e7\u00e3o de tela s\u00e3o um \u00f3timo exemplo. Geralmente podemos pedir ao servidor apenas os dados crus, coisa que o client-side n\u00e3o consegue resolver sozinho, e com estes dados montar a apresenta\u00e7\u00e3o da tela, sem a necessidade da mesma ser constru\u00edda no servidor.<\/p>\n

Outro exemplo s\u00e3o os scripts de valida\u00e7\u00e3o no lado do cliente. \u00d3bvio que n\u00e3o estou dizendo para confiar apenas no cliente, mas uma pr\u00e9-valida\u00e7\u00e3o no lado do cliente pode poupar idas desnecess\u00e1rias ao servidor, por exemplo.<\/p>\n

N\u00e3o estou querendo aqui te convencer a abrir m\u00e3o de processar coisas no servidor, longe disso. Estou apenas sugerindo que, o que puder ser feito no lado do cliente, sem que atrapalhe a experi\u00eancia dele, pode ser feito. Afinal, geralmente o browser do usu\u00e1rio est\u00e1 com mais processamento ocioso do que nossos servidores.<\/p>\n

Dica 3: Publique para produ\u00e7\u00e3o<\/h2>\n

Ok, a primeira parte desta dica n\u00e3o vale para o PHP, mas muitos programadores de outras linguagens n\u00e3o fazem ideia de que existe mais de um tipo de compila\u00e7\u00e3o. Geralmente dois: debug e release.<\/p>\n

Quando compilamos nossa aplica\u00e7\u00e3o como debug (o default), diversas meta-informa\u00e7\u00f5es s\u00e3o inseridas nela para que o debugging possa ocorrer, para que a pilha de erro d\u00ea mais informa\u00e7\u00f5es sobre cada exce\u00e7\u00e3o lan\u00e7ada e muito mais. Nada disso \u00e9 necess\u00e1rio (ou n\u00e3o deveria) quando sua aplica\u00e7\u00e3o vai para produ\u00e7\u00e3o.
\nSendo assim, sempre que existir a possibilidade (e sua linguagem for compilada), procure o jeito correto de publicar sua aplica\u00e7\u00e3o em modo release (produ\u00e7\u00e3o) para que ela tenha o menor tamanho e maior performance b\u00e1sica poss\u00edvel.<\/p>\n

Al\u00e9m disso, mesmo que sua aplica\u00e7\u00e3o n\u00e3o seja compilada, sempre existem ajustes que podemos fazer para melhorar sua performance em produ\u00e7\u00e3o, geralmente ajustes associados \u00e0s vari\u00e1veis de inicializa\u00e7\u00e3o, de ambiente e arquivos de configura\u00e7\u00e3o. N\u00e3o sou nenhum expert em PHP, mas tenho certeza que existem configura\u00e7\u00f5es que voc\u00ea pode fazer.<\/p>\n

Mesmo as linguagens compiladas possuem tais configura\u00e7\u00f5es, como no caso do web.config do ASP.NET por exemplo, que possui diversos ajustes de performance como remover autentica\u00e7\u00e3o quando n\u00e3o \u00e9 utilizada e o mesmo para sess\u00e3o, s\u00f3 para citar dois exemplos. Estude os arquivos de configura\u00e7\u00e3o da sua linguagem web e ver\u00e1 que h\u00e1 muito mais neles do que apenas a string de conex\u00e3o com o banco. \ud83d\ude09<\/p>\n

Dica 4: Tipos de vari\u00e1veis<\/h2>\n

Voc\u00ea deve achar que estou maluco, afinal, o que tipos de vari\u00e1veis t\u00eam a ver com performance do meu site? Tudo!
\nTalvez n\u00e3o se lembre das primeiras aulas de algoritmos (supondo que voc\u00ea fez\/faz um curso t\u00e9cnico ou faculdade de computa\u00e7\u00e3o), mas uma das primeiras coisas que aprendemos s\u00e3o os tipos de vari\u00e1veis e o quanto eles ocupam de espa\u00e7o na mem\u00f3ria do computador. Quanto maior a capacidade e os poderes do tipo que voc\u00ea escolher, mais mem\u00f3ria ele vai consumir e muitas vezes mais processamento tamb\u00e9m.<\/p>\n

Um alerta aos programadores PHP e outras linguagens com tipagem din\u00e2mica: voc\u00eas tamb\u00e9m devem se preocupar com os tipos que voc\u00eas inferem dinamicamente \u00e0s vari\u00e1veis!<\/p>\n

Mas, dando um exemplo pr\u00e1tico, um INTEGER (int, Int32, inteiro, como preferir) geralmente ocupa 4 bytes de mem\u00f3ria, ou 32-bit. Isso d\u00e1 a ele (aproximadamente) 4.3 bilh\u00f5es de n\u00fameros poss\u00edveis ou quase a idade do planeta Terra. Falando em idade, voc\u00ea j\u00e1 notou como \u00e9 comum os programadores usarem INTEGER para vari\u00e1veis de idade e semelhantes? Se a sua linguagem possui outros tipos de dados num\u00e9ricos, como o SHORT INTEGER (short, Int16, etc), voc\u00ea deve us\u00e1-lo para evitar desperd\u00edcios como esse do exemplo, de guardar a idade de uma pessoa (que dificilmente passa de 100 anos) em uma vari\u00e1vel que comporta at\u00e9 4.5 bilh\u00f5es de anos.<\/p>\n

O mesmo vale para tipos com ponto flutuante. Com exce\u00e7\u00e3o do PHP, onde double e float s\u00e3o a mesma coisa, geralmente eles n\u00e3o s\u00e3o. Algumas linguagens, inclusive, possuem um terceiro tipo chamado decimal. O float \u00e9 o equivalente do integer quando o assunto \u00e9 ponto flutuante, sendo que ele usa parte dos bits para o n\u00famero inteiro e parte para os decimais. J\u00e1 o double possui esse nome pois \u00e9 um float de dupla precis\u00e3o, ou 64-bit, com muitos mais possibilidades \u2018antes e depois da v\u00edrgula\u2019. J\u00e1 o decimal t\u00eam foco nas casas decimais, com uma precis\u00e3o absurdamente maior que o float, mas com uma grandeza menor de n\u00fameros inteiros dispon\u00edveis. Ou seja, dependendo da linguagem que voc\u00ea usa, existem diversas op\u00e7\u00f5es de vari\u00e1veis para ponto flutuante, uma para cada ocasi\u00e3o e depois de ler isso deve ter ficado \u00f3bvio que o double \u00e9 o mais custoso deles para a m\u00e1quina em termos de recursos consumidos.<\/p>\n

Claro que isso somente faz diferen\u00e7a em grandes quantidades, em sites\/sistemas com muitos acessos. Mas considerando que todos queremos que nosso projeto seja bem sucedido um dia, que tal perder mais alguns minutinhos agora j\u00e1 programando do jeito certo?<\/p>\n

Outro exemplo, ainda mais dram\u00e1tico s\u00e3o as vari\u00e1veis de texto. String, text, CHAR*, STR, n\u00e3o importa. Vari\u00e1veis de texto geralmente est\u00e3o associadas a alto consumo de mem\u00f3ria, principalmente devido \u00e0s caracter\u00edsticas intr\u00ednsecas de tais dados, como sua imutabilidade (exceto no PHP), suporte \u00e0 m\u00faltiplos caracteres (o que exige muitos bits para cada caracter) e por a\u00ed vai. Em algumas linguagens como o C#, cada String consome 20 bytes de mem\u00f3ria s\u00f3 por existir, e mais 2 bytes para cada caracter que ela tiver, \u00e9 muita mem\u00f3ria! \u00c9 quando entra nossa segunda dica.<\/p>\n

Dica 5: N\u00e3o fique manipulando Strings diretamente<\/h2>\n

Isso \u00e9 especialmente importante para quem trabalha com linguagens fortemente tipadas como Java e C#, mas tamb\u00e9m pode ser levada em considera\u00e7\u00e3o por quem usa PHP.<\/p>\n

Qual a diferen\u00e7a? Em linguagens como Java e C#, as Strings s\u00e3o imut\u00e1veis, elas n\u00e3o podem ser alteradas. Quando, em nosso c\u00f3digo, acreditamos estar alterando uma String, na verdade, estamos criando uma nova sem saber, o que obviamente nos leva a um problema enorme de mem\u00f3ria se ficarmos manipulando Strings muito grandes ou mesmo Strings pequenas – se fizermos isso muitas vezes, em um la\u00e7o, por exemplo.<\/p>\n

Nestas linguagens, o ideal \u00e9 usar buffers de Strings, como o StringBuilder do C# e do Java, que manipula Strings de maneira mais inteligente, sem ter de ficar recriando-as o tempo todo.<\/p>\n

E no PHP?<\/p>\n

No PHP as Strings s\u00e3o mut\u00e1veis, ent\u00e3o n\u00e3o h\u00e1 uma perda t\u00e3o grande em uma manipula\u00e7\u00e3o extensa de strings, embora a performance de suas Strings n\u00e3o sejam t\u00e3o boas quanto um StringBuilder. Mas \u00e9 um \u00f3timo meio-termo!<\/p>\n

Ainda falando de Strings, vamos \u00e0 pr\u00f3xima dica!<\/p>\n

Dica 6: Use express\u00f5es regulares quando necess\u00e1rio<\/h2>\n

Se voc\u00ea n\u00e3o conhece express\u00f5es regulares, deveria!<\/p>\n

Acontece que quando temos tarefas de processamento intenso sobre textos, envolvendo condi\u00e7\u00f5es complexas, m\u00faltiplas condi\u00e7\u00f5es simples ou tarefas textuais que s\u00f3 de olhar o c\u00f3digo digitado voc\u00ea j\u00e1 percebe que tem alguma coisa errada, \u00e9 hora de usar express\u00f5es regulares.<\/p>\n

Por exemplo, voc\u00ea quer verificar se um padr\u00e3o de palavra existe dentro de um texto (ou n\u00e3o existe). Voc\u00ea pode faz\u00ea-lo testando todas as possibilidades com um \u2018contains\u2019 tradicional, ou simplesmente resumir a um \u00fanico IF em cima de uma express\u00e3o regular com o padr\u00e3o de palavra que est\u00e1 buscando. O mesmo vale para \u2018REPLACES\u2019 condicionais, extra\u00e7\u00e3o de texto, valida\u00e7\u00e3o de formatos, etc. Se testes complexos ou mesmo muitos testes simples devem ser feitos em strings, \u00e9 hora de pensar em usar uma REGEX.<\/p>\n

Claro que existem muitas dicas de performance que poderiam ser dadas somente acerca do uso de regex em seu c\u00f3digo, mas em linhas gerais, \u00e9 uma dica a ser utilizada sempre que necess\u00e1rio. N\u00e3o seja pregui\u00e7oso e fa\u00e7a certo!<\/p>\n

Dica 7: Cuidado com o que voc\u00ea declara<\/h2>\n

Isso \u00e9 uma verdade at\u00e9 mesmo na vida real \ud83d\ude00<\/p>\n

A quantidade de vari\u00e1veis que declaramos, e principalmente, os objetos que declaramos (caso esteja usando orienta\u00e7\u00e3o a objetos) impactam profundamente o desempenho da nossa aplica\u00e7\u00e3o, principalmente quando associados \u00e0 la\u00e7os de repeti\u00e7\u00e3o ou chamadas recursivas.
\nComo assim?<\/p>\n

Uma vari\u00e1vel declarada ou objeto instanciado fora de um la\u00e7o, em uma situa\u00e7\u00e3o normal, \u00e9 criado uma vez em mem\u00f3ria. A mesma vari\u00e1vel ou objeto declarado dentro de um FOR ou WHILE \u00e9 criada uma vez em mem\u00f3ria…para cada itera\u00e7\u00e3o do la\u00e7o!!!
\nJunte isso ao que vimos antes sobre tipos de vari\u00e1veis e principalmente Strings e veremos que declarar vari\u00e1veis e objetos dentro de la\u00e7os \u00e9 algo que somente deve ser usado em \u00faltimo caso, pois geralmente 90% do custo computacional de um sistema est\u00e1 nos 10% de trechos de c\u00f3digo que programamos, geralmente onde la\u00e7os est\u00e3o envolvidos.<\/p>\n

Ent\u00e3o, \u201cbora\u201d declarar suas vari\u00e1veis fora dos la\u00e7os de repeti\u00e7\u00e3o?<\/p>\n

O mesmo vale para chamadas recursivas, que facilmente podem estourar a pilha de mem\u00f3ria da sua linguagem se ficarem criando objetos e vari\u00e1veis a torto e a direito.<\/p>\n

Dica 8: N\u00e3o sobrecarregue suas requisi\u00e7\u00f5es<\/h2>\n

No post sobre front-end<\/a>, falei muito sobre diminuir o n\u00famero de requisi\u00e7\u00f5es, aqui o foco \u00e9 diminuir o \u2018custo\u2019 de cada requisi\u00e7\u00e3o: consumo de CPU, mem\u00f3ria, etc.
\nCada vez que o usu\u00e1rio interage com sua aplica\u00e7\u00e3o web, uma requisi\u00e7\u00e3o \u00e9 feita ao back-end, certo?<\/p>\n

Se a cada requisi\u00e7\u00e3o voc\u00ea tiver de fazer um monte de verifica\u00e7\u00f5es, carregamentos, valida\u00e7\u00f5es, conex\u00f5es ao banco e por a\u00ed vai, n\u00e3o \u00e9 preciso ser um g\u00eanio do MIT para ver que n\u00e3o vai dar certo, que tudo vai ficar muito lento rapidamente.<\/p>\n

A regra \u00e9 clara: se voc\u00ea faz sempre as mesmas tarefas durante as requisi\u00e7\u00f5es ao servidor (como verificar no banco se o usu\u00e1rio tem permiss\u00e3o para acessar uma p\u00e1gina) \u00e9 hora de repensar sua estrat\u00e9gia pois h\u00e1 um jeito melhor de faz\u00ea-la.<\/p>\n

Claro que eu n\u00e3o tenho como cobrir todas aqui, pois cada linguagem tem as suas particularidades. No NodeJS, por exemplo, uma pr\u00e1tica comum, e err\u00f4nea, \u00e9 carregar a conex\u00e3o com o banco de dados junto \u00e0s requisi\u00e7\u00f5es, para n\u00e3o oner\u00e1-la. No ASP.NET, fala-se de n\u00e3o usar ViewState para n\u00e3o ficar carregando um monte de informa\u00e7\u00e3o, geralmente in\u00fatil, junto aos postbacks. Mas em linhas gerais, o que estou sugerindo \u00e9 que pesquise as boas pr\u00e1ticas do seu framework\/linguagem de programa\u00e7\u00e3o quando o assunto \u00e9 \u2018idas e vindas do servidor\u2019.<\/p>\n

Uma dica gen\u00e9rica e excelente para isso \u00e9 a seguinte.<\/p>\n

Dica 9: Use cache<\/h2>\n

Se o seu backend \u00e9 muito requisitado para efetuar opera\u00e7\u00f5es ou consultar dados muitas vezes repetidores, pode ser uma boa oportunidade de usar algum tipo de caching.<\/p>\n

Vale tudo aqui: cache in-proc, plugins, Redis, memcached, n\u00e3o importa. A ideia \u00e9, se voc\u00ea vai demais no servidor para pegar sempre os mesmos dados, um cache vai te ajudar, e muito.<\/p>\n

Boa parte dos sistemas, principalmente aqueles em que o usu\u00e1rio se autentica para usar, acabam consultando muita informa\u00e7\u00e3o repetida durante a navega\u00e7\u00e3o do usu\u00e1rio por dentro da ferramenta e, muitas vezes, estes dados n\u00e3o se alteram com frequ\u00eancia para terem de ser consultados \u201c\u00e0 quente\u201c toda hora.<\/p>\n

Por exemplo, as pr\u00f3prias informa\u00e7\u00f5es da conta do usu\u00e1rio logado. No momento que ele se autenticar, voc\u00ea deveria guardar as principais informa\u00e7\u00f5es dele que voc\u00ea pode precisar ao longo da sess\u00e3o de navega\u00e7\u00e3o, como o nome e foto, por exemplo, mas tamb\u00e9m quais produtos\/servi\u00e7os ele tem contratados com voc\u00ea. Essas s\u00e3o informa\u00e7\u00f5es que geralmente s\u00e3o exibidas em todas telas, e voc\u00ea n\u00e3o vai querer ir no banco a cada requisi\u00e7\u00e3o de troca de tela para pegar a mesma coisa, certo?<\/p>\n

Estas foram mais algumas dicas que acreditamos que possam fazer uma diferen\u00e7a significativa no desempenho do seu site e certamente existem muitas outras que poder\u00edamos aplicar, principalmente se entrarmos no detalhe de linguagens espec\u00edficas. No pr\u00f3ximo post, vamos abordar melhorias no banco de dados, a come\u00e7ar pela escolha do banco certo para sua aplica\u00e7\u00e3o (sim, voc\u00ea pode estar usando o banco errado neste exato momento!).<\/p>\n

E voc\u00ea, tem alguma dica de performance para back-end? Nos conte aqui nos coment\u00e1rios \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":"

Em meu post anterior, falei de dois t\u00f3picos de suma import\u00e2ncia quando o assunto \u00e9 deixar nossos sites mais r\u00e1pidos: lat\u00eancia e front-end. Hoje, falarei de outro item important\u00edssimo: back-end! Enquanto a maioria dos problemas de carregamento atuais s\u00e3o culpa de a) sites hospedados no exterior e b) sites com uma tonelada de recursos (plugins, […]<\/p>\n","protected":false},"author":46,"featured_media":5468,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"class_list":["post-1618","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dev"],"_links":{"self":[{"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/posts\/1618"}],"collection":[{"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/users\/46"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/comments?post=1618"}],"version-history":[{"count":0,"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/posts\/1618\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/media\/5468"}],"wp:attachment":[{"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/media?parent=1618"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/categories?post=1618"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/tags?post=1618"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}