Ir para conteúdo

.


Rafael Lima

Posts Recomendados

Texto ocupa muito espaço visual, mas não tanto espaço em memória. Por exemplo, um artigo de 65536 caracteres é grande "pakas" para se ler, mas só ocupa 64 KiB. (considerando somente caracteres ASCII)
O que é muita coisa para um embarcado com 32 KiB, mas para uma requisição HTTP com um servidor não é lá grande coisa a ponto de causar uma negação de serviço. Por exemplo no PHP, o tamanho máximo para upload de um arquivo é por padrão 2 MiB. Uma imagem em full HD pode alcançar fácil 4~5 MiB.
Agora respondendo as perguntas:

  1. Depende da infraestrutura do site e como ele foi programado. Um site qualquer poderia cair só em tu ficar apertando F5 na página.
    Mas um site bem feito provavelmente iria limitar o número de requisições e começaria a responder seu script com 429 após um número N de requisições em um curto intervalo de tempo. O nome disto é rate limit.
  2. Limitar no lado do servidor, sim você pode fazer isto. Mas não vai fazer uma diferença significativa. Você pode pesquisar sobre técnicas para evitar que o seu serviço caia por qualquer besteira. Isto inclui desde configurar uma boa infraestrutura até configurar rate limit e, talvez o mais importante, seria otimizar sua aplicação. Porque não adianta de nada tu fazer tudo isto se existe uma determina página no teu site que roda um monte de queries e faz um monte de operações pesadas e nem sequer faz cache no lado do servidor. Tu tá criando uma bomba pronta para ser explodida, e nem precisa de script para explodir ela.
  3. No banco de dados existe um limite no tamanho de uma query. No MySQL a variável max_allowed_packet quem determina isto, e por padrão é 1 MiB. Se o site tá fazendo pesquisa usando queries no banco de dados (que não é a única, e nem a melhor forma), então ele já está englobado neste limite.

 

Se isto é uma preocupação para você, uma solução não-gratuita seria pagar um serviço para proteção contra DDoS. Como o da Cloudflare.
Dicas para melhorar a performance do site:

  • Se seu servidor precisar fazer operações pesadas, tente otimizar isto o máximo possível e use cache no lado do servidor.
  • Quando precisar usar o banco de dados, tente ao máximo fazer isto com uma só query. Aprenda a usar joins e evite queries dentro de loops. (pesquise sobre o N+1 query problem)
  • Se você estiver escrevendo dados no banco de dados em loop, e não souber (ou não for possível) fazer isto com uma só query. Então adicione o loop dentro de uma transaction. Alterações dentro de transactions são primariamente feitas em memória, para só depois serem efetivamente escritas no disco. Portanto dentro do loop só existirá uma só escrita em disco, ao invés de várias em sequência. (ainda é melhor fazer tudo em uma única query)
    Só para servir de referência. Eu tinha um seeder aqui inserindo dados em loop e estava rodando em um pouco mais de 1 minuto. Adicionei a transaction e este tempo caiu para 5 segundos.

Enfim, foi o que me lembrei agora. Mas tu pode pesquisar mais afundo para ver melhor estas coisas. o/

Link para o comentário
Compartilhar em outros sites

Em 14/02/2021 em 00:25, Rafael Lima disse:

Se eu gerar script que faça um bilhão de requisição e usar isso poderia levar um site a cair?

E a possível solução seria limitar a quantidade de caracteres em uma barra de pesquisa?
Se a requisição for via post o próprio banco de dados  limita até (200epouco char) estou certo??

Aumentando um cadinho a resposta do Felipe.Silva (e reforçando alguns pontos):

Em primeiro lugar, query strings são limitadas, senão pelo seu browser, pelo menos pelo webserver. Eu acho (assim como ficou implícito na resposta do Felipe) que o limite é de 32 KiB (mas, já ouvi falar de 4 KiB ou menos). Se você precisar enviar mais dados tem que usar o método POST que, em teoria, tem um limite muito maior.

Se você gerar um script que faça bilhões de requisições (não dá pra fazer no mesmo computador!) o site não cai porque o webserver tem um limite de conexões simultâneas. As demais ele simplesmente desconecta. Isso é diferene de enviar bilhões de "pacotes" TCP para o servidor alvo, por exemplo.

No caso de uma aplicação, geralmente não se expõe a conexão com o banco de dados diretamente. Então, o limite do tamanho de uma query (outro tipo de query - uma query SQL) não está diretamente relacionada com a http query.

Link para o comentário
Compartilhar em outros sites

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

  • Quem Está Navegando   0 membros estão online

    • Nenhum usuário registrado visualizando esta página.
×
×
  • Criar Novo...