Um assunto que 90% dos programadores não se preocupam é sobre a economia ou ganho de desempenho no processamento do servidor. Digo isto porque esses 90% são apenas programadores, não são especialistas em servidor. O que não é nenhum crime antes que me condenem.

Mas atualmente, é item OBRIGATÓRIO o fato de que é preciso saber e conhecer, formas de economizar e se possivel melhorar a performance de um servidor web.

Este artigo vale para: administradores de servidor que programam ou não e programadores que administram servidores ou não. E até mesmo pro seu chefe que acha que o servidor está lento por culpa sua e não do programador freela que ele contratou (e que obviamente não economiza recursos ao programar)

Claro que não vou conseguir abordar em um único artigo, 100% dos pormenores sobre o ganho de desempenho e performance de um servidor. Porém abordarei os mais importantes. Outros itens também importantes serão abordados em um outro artigo!

Aos tópicos e suas explicações:

• HTTPS (protocolo seguro) - Não use se não tiver necessidade
  Todo mundo fala em segurança, mas será que você precisa mesmo? Tenho visto por aí sites pessoais funcionando dentro de protocolos HTTPS. Puro e simples desperdício.
  O protocolo HTTPS consome muitos recursos do servidor. Isto se deve ao fato de que cada informação trafegada dentro do protocolo, será criptografada, o que exige muito tráfego de rede (banda). A criptografia funciona tanto no envio de informações quanto no recebimento, por este motivo, também consome muito tempo de processamento, chamado de tempo de CPU.
  Outro item a ser levado em conta é a memória utilizada. Os algoritmos de criptografia, tendo de atender a múltiplas requisições de entrada e saída de dados criptografados armazenam mais memória da máquina.
  Saiba que, quanto menor o arquivo que você enviar via HTTPS, maior será o processamento. Por isso não pense que você pode ter paginazinhas de 10kb rodando em HTTPS sem gastar uma boa grana com banda por mês, além de ter o site bem mais lento.
  
  Mas aí você vai me perguntar: Mas e os grandes sites que rodam suas áreas restritas em HTTPS, e são rápidas, como eles fazem?
  
  Há duas coisas a serem observadas aí:
  - Primeiro: Os grandes sites rodam APENAS o que é necessário em HTTPS. Ou seja, você não vé páginas públicas comuns dentro de protocolo de segurança, apenas páginas referente á áreas restritas, centrais de pagamento, locais onde se trafegam informações pessoais e sigilosas etc.
  - Segundo: Grandes empresas possuem clusters adicionais apenas para rodar HTTPS. Geralmente possuem servidores APENAS para esta finalidade. Por isso são rápidos, estão ali apenas pra isso.
  
  Em suma: utilize o poder do HTTPS apenas quando necessário. Se não é necessário, não use.
  
  
• Upload de arquivos via formulário - Evite ou limite o tamanho
  Geralmente os servidores vem configurados com um limite de 21MB para upload de arquivos. Isto é, para cada arquivo. Se você enviar 10 arquivos de 21MB, estará ocupando fisicamente 210MB da memória da máquina. Imagine 1000 usuários tentando fazer upload de arquivos deste tamanho? Aí acontecem perdas de link ou quedas de servidor e você vai lá culpar a hospedagem ou falar pro seu chefe que o servidor que ele comprou é ruim.
  Alguns analistas modificam essa configuração para 50MB. Apenas pense que: se é apenas para seu uso, ótimo. Se é pra uso de ilimitados usuários, não vai demorar a ter problemas.
  
  Em sites de fotos e videos, basta limitar o tamanho de arquivo enviado. Até mesmo o monstruoso Google limita os arquivos anexados, ou à enviar via form em 10MB. Mas para quem tem N servidores com balanceamento de carga (cada um assume um pouco do tráfego) fica bem mais fácil.
  Se você tem um site de fotos, limite cada foto em 100KB, isso vai economizar memória da sua máquina, tráfego de CPU e espaço em disco! É muito ganho pra pouco esforço.
  
  Se não há necessidade MESMO de usuários enviando anexos, ou fazendo upload de arquivos, não utilize. Dar esse tipo de ferramenta para os usuários, pode acabar dando é mais trabalho e problema pra você.
  
  
• Partições de disco (em ambientes de plataforma alta, é claro) - Um item de suma importância!
  Os usuários de plataforma baixa (windows), já sabem que ter partições em disco é importante para poder formatar a máquina sem perder dados caso precise. Em ambientes de plataforma alta (Unix, Linux, FreeBSD etc), a importância é outra.
  Utilize discos sobressalentes ou partições de um disco muito grande, como local para exibição de dados públicos.
  
  Explico:
  Se você tem um servidor com um disco sobressalente, monte seu sistema de arquivos de forma que as pastas dos sites fiquem neste disco. Assim, você economiza o processamento do disco principal com a tarefa de buscar os dados para apresentar ao navegador do cliente.
  
  O disco principal (ou partição principal) já tem muito trabalho em executar todas as tarefas que necessita. Quanto mais você puder economizar deste trabalho, melhor. É claro que o disco principal vai ser consultado quando o usuárioo site, mas pense bem: ele será apenas consultado: "Onde está o site?". E aí, vai te redirecionar para o disco (ou partição) onde está o conteúdo, e o trabalho será apenas e sempre este. Manter ativo o link com a resposta enquanto o usuário estiver no site. Quando o usuário desconectar, essa conexão é fechada e pronto, o disco principal continua lá, firme e forte e aguardando uma nova consulta.
  
  Use sempre partições ou discos sobressalentes para melhorar o desempenho de apresentação de resultados, e economizar processamento em disco principal do servidor.
  
  
• Evite instruções SQL muito grandes para aplicações onde o banco de dados está na mesma máquina da aplicação
  Este é um caso comum para sites que ficam hospedados em empresas de hospedagem. Ou empresas pequenas que possuem apenas um servidor, ou seja, o banco de dados fica no mesmo local onde estão as páginas que o acessa.
  O cenário perfeito seria é claro, separar o banco do resto, mas como nem tudo é perfeito, vamos tentar ganhar pelo menos alguma performance.
  
  Servidores onde o banco fica junto com as páginas, serão sempre mais lentos do que separados. Porém, evitar instruções SQL muito longas ajuda a melhorar o desempenho.
  
  Se você tem instruções SQL maiores de 15 linhas (ou então com mais de 5 instruções INNER JOIN), execute-as em separado, ou através de interfaces externas ou até mesmo, em horários onde o movimento do site é menor.
  
  Explicando:
  Executando em separado: quebre a instrução SQL em duas ou três partes dependentes se necessário. Isso evita travamentos do banco, processos zumbis roubando memória ou até mesmo perda de dados.
  
  Executando através de interface externa: hoje em dia para os nerds mais aplicados, construir uma inteface para execução de longas querys é uma coisa básica. Você pode fazê-la com qualquer linguagem, seja online ou não. Se você fizer com PHP por exemplo, aloque sua aplicação em um outro servidor onde você vai cadastrar essas querys, que serão executadas de tempos em tempos. Se for com JAVA que é offline, o processo é o mesmo.
  
  Executando em horários pré determinados: você pode usar a interface acima mencionada para executar uma query de otimização de um banco com mais de 500.000 registros, a 1:00 da manhã por exeplo. Ou então pode utilizar-se do CRON (aplicativo cronjob dos ambientes plataforma alta) para agendar a chamada de um arquivo. Arquivo este onde conterão as querys que você quer executar.
  
  Em um próximo artigo, vou abordar outros tópicos importantes sobre a economia de recursos do servidor.
  Obrigada!