Este tópico é um
Mas na verdade foi a pedido do @mvbs hahaha
Ele lançou uma dúvida na área de tira-dúvidas daqui sobre servidores, sobrecarga de servidores, esse tipo de situação. Então este tópico é uma tentativa de tentar sanar essas dúvidas, mas já deixo claro que não sou expert no assunto então se eu der uma patinada por favor me corrijam. Minha experiência com servidores em produção é bem rasa ainda então não tenho muita vivência no assunto.
Antes de mais nada, este tópico é mais ou menos uma continuação do tópico de "como funciona a web" >>
Como a web funciona - Tecnologia - Bastter.com então é interessante ler ele antes de ler este aqui.
Um servidor nada mais é do que um computador, como o que você pode estar usando para ler este tópico, mas um computador muito mais potente do que o que você está usando, com mais processamento, memória ram, armazenamento (inclusive com SSD), etc.
E é neste servidor que iremos adicionar nossa aplicação web (web app), ou nosso servidor web, ou nosso servidor de banco de dados, ou servidor de arquivos, etc.
Quem leu o tópico de como funciona a web lembra que, por exemplo, quando acessamos um site como a Bastter.com, nosso navegador mandou uma requisição (request) para o IP do servidor que armazena o conteúdo da Bastter.com.
E este conteúdo é controlado por uma parada que chamamos de framework. Este troço que chamamos de framework é responsável por receber as requisições, realizar o processamento necessário para visualizar o conteúdo que pedimos na nossa tela, comunicar-se com o banco de dados (que traz nossa carteira do BS), etc. No caso aqui da Bastter, se não me engano, o framework é o ASP.NET (escrito em C#), mas existem diversas opções além do ASP.NET, que inclusive eu citei no chat abaixo
Aqui eu vou usar uma imagem de o que acontece com essa requisição como se o site tivesse sido feito em Django, que é um framework web feito em Python.
Ignorem por enquanto tudo que acontece na esfera do Django. Observem principalmente a parte superior da imagem. Supondo que a Bastter tivesse sido feita em Django, o usuário, nós (client side), iríamos enviar a requisição para acessar o site via browser. Essa requisição vai cair em um servidor web, ou web server, no qual a aplicação está hospedada. E o servidor, aquele computador que mostrei no início da postagem, irá procurar a aplicação Bastter.com, e diversos arquivos irão fazer essa procura para no fim mandar para nosso navegador arquivos nos formatos HTML, CSS e JavaScript, que são os formatos de arquivos que o navegador aceita ler, renderizar.
Na camada mais abaixo da imagem, temos nossa aplicação, a Bastter.com, acessando o banco de dados. É no banco de dados que temos nosso cadastro no site, nossas postagens, nossa carteira no BS, os dados em geral do site.
Se a requisição for feita com sucesso, o site irá ser renderizado em nosso navegador.
Bem, este é o funcionamento básico do ciclo de requisição entre o client side e o server side.
Agora, por que ouvimos frases como "estamos precisando cada vez mais de servidores mais caros", ou "nosso servidor está sobrecarregado", ou "o site caiu na black friday porque não aguentou a quantidade de requisições"?
Bem, de forma curta e grossa, já que um servidor é um computador, quanto mais pessoas acessando aquela aplicação naquele computador, mais aquele computador vai requerer processamento, memória ram, armazenamento, etc, para responder a tantas requisições, a tantas buscas no banco de dados, etc. E ainda tem os casos no qual o site precisa de serviço de terceiros, como acessar serviços de pagamento em sites de e-commerce, que podemos realizar o pagamento de algo usando PayPal, etc. Aí vira uma bola de neve de gargalos que vão aparecendo quanto mais o servidor não aguenta processar tantas tarefas simultâneas.
Imagina abrir 2000 abas no seu Google Chrome pra ver o que acontece. Você está sobrecarregando seu computador, está pedindo mais e mais processamento e vai ter um momento que ele não vai mais responder adequadamente.
Tomando a Bastter.com como exemplo, quando aqui começou e tudo era mato, não tínhamos essa quantidade de usuários cadastrados (que no momento são 181.664 pessoas). Não tinha nem perto disso. Então não tinha tantos tópicos para armazenar em um banco de dados. E não tinha a quantidade de ferramentas que hoje existem aqui. Não tinha área de tecnologia, não tinha investimentos no exterior, talvez não tivesse a área de saúde. Então imaginem que bastava um servidor bem mais simples do que o que está sendo usado agora para armazenar o site.
Se menos pessoas acessam um site, menos acessos simultâneos teremos, menos processamento será necessário e assim por diante.
Agora o site do tamanho que está hoje, com uma infinidade de tópicos, de imagens, de ferramentas, muito mais usuários online ao mesmo tempo (como no print, no qual é mostrado que 7210 pessoas estão online ao mesmo tempo acessando o site, embora eu não saiba como é o funcionamento desse RODATNOC, mas pra título de conceito considerem que 7210 pessoas estão acessando de forma simultânea o site), demanda muito mais processamento, demanda um banco de dados muito maior do que aquele usado inicialmente, demanda buscas mais inteligentes nesse banco de dados (já que um código mal feito pode fazer o banco de dados trabalhar à toa, o que gera gargalos de processamento e memória), demanda muito mais memória ram e por aí vai. E o pagamento por servidores é mais caro quanto melhor for a máquina disponibilizada.
Abaixo tem um exemplo de tabela de preços de um site conhecido de hospedagem que é a Digital Ocean (
Pricing on DigitalOcean - Cloud virtual machine & storage pricing), onde é possível ver que quanto mais memória, processamento, armazenamento, maior o preço do plano mensal.
Na pesquisa para criar o tópico eu cheguei a ver uma analogia interessante de um servidor com um supermercado.
Pensem que estão num supermercado e todos os clientes estão espalhados pelas gôndolas, prateleiras, e alguns desses clientes estão na fila do caixa.
Agora imaginem que todos os clientes da situação acima resolvam usar o caixa ao mesmo tempo. Nas gôndolas e prateleiras agora não tem mais ninguém. Todos estão na fila pra pagar. Isso vai tornar o fluxo menos eficiente. Os caixas estarão sobrecarregados. Os clientes irão esperar mais tempo na fila. Isso seria a definição de um gargalo no caso dos servidores.
E isso explica porque a Black Friday é o paraíso para os sites de e-commerce mas é o pesadelo dos times de TI destes sites. Não sei se alguém aqui tentou comprar algo online nas primeiras Blacks Fridays que existiram por aqui, mas os relatos da época era de sites gigantescos não aguentarem tantas requisições simultâneas, o que causava lentidão, os servidores podiam chegar a cair mesmo e ninguém comprava nada.
Era frustração para consumidores e para a administração da empresa lojista. Eu li até umas pesquisas interessantes sobre isso mas vai um pouco além do assunto do tópico.
Enfim, ainda há muita coisa pra falar, mais da parte técnica, como os cenários que crasheiam um servidor, sobre monitoramento de requisições, sobre escalabilidade de servidores, sobre servidores em máquinas virtuais, etc, mas aí entra num campo mais avançado e a ideia aqui era deixar o assunto mais leve, menos aprofundado.
Espero que tenha ficado claro, principalmente para o @mvbs. Se eu falei alguma besteira podem comentar abaixo. Quem quiser complementar fique à vontade.
Referências
https://queue-it.com/blog/website-failure-under-load-this-is-why/https://queue-it.com/blog/how-high-online-traffic-can-crash-your-website/What does it mean when a server goes 'down'? Why does it go down? - Quora
