Neste artigo, vamos nos aprofundar no motivo pelo qual ocorre o aumento da carga do servidor e discutir várias maneiras de otimizar processos de alta carga. Atenção especial será dada à otimização de código no Apache/Nginx e MySQL, falaremos sobre cache como uma ferramenta auxiliar e também consideraremos possíveis ameaças externas, como ataques DDOS, e maneiras de preveni-los.
Por que ocorre a carga do servidor
Antes de prosseguir com a otimização do servidor, é necessário conduzir uma análise completa da carga atual nos recursos. Isso inclui medir a carga da CPU, uso de RAM, atividade de rede e outros parâmetros-chave. Entender a dinâmica e os picos de carga permite identificar gargalos e otimizar a alocação de recursos, aumentando assim a estabilidade e o desempenho da infraestrutura do servidor.
Para solução de problemas inicial de alta carga do servidor, recomendamos realizar uma diagnóstico geral do servidor. Se isso não for suficiente, uma análise mais detalhada análise de recursos é necessário. Como ferramenta auxiliar, explorar o registros do Linux servidor pode ser útil, pois é onde a origem do problema é encontrada na maioria dos casos.
Otimizando o Servidor Apache/Nginx
Aumento da carga do servidor devido à indexação
O aumento de carga devido à indexação no servidor pode ocorrer, por exemplo, quando mecanismos de busca escaneiam um grande número de páginas em seu site. Isso pode levar ao aumento do uso de recursos do servidor e, consequentemente, diminuir o desempenho do site. Identificar a causa é relativamente simples; você precisa abrir o arquivo localizado em:
/var/www/httpd-logs/sitename.access.log
Quando indexado por mecanismos de busca, o usuário verá entradas da seguinte natureza:
11.22.33.44 - - [Date and Time] "GET /your-page-path HTTP/1.1" 200 1234 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Como primeira solução para reduzir a carga, você pode usar a configuração de meta tags "sem índice" e "não siga" em páginas que não precisam ser indexadas. A segunda solução é a .htaccess arquivo, onde entradas correspondentes a mecanismos de busca específicos precisam ser adicionadas, por exemplo, para ocultar do Yandex e do Google:
SetEnvIfNoCase User-Agent "^Yandex" search_bot
SetEnvIfNoCase User-Agent "^Googlebot" search_bot
Order Allow,Deny
Allow from all
Deny from env=search_bot
Da mesma forma, edições precisam ser feitas para outros mecanismos de busca. Deve-se notar que os recursos do .htaccess não se limitam apenas a bloquear a indexação. Recomendamos se familiarizar mais com seus principais recursos no neste artigo.
Usando configurações de cache
Configurações incorretas de cache no servidor também podem levar a uma carga alta. Para otimizar esse parâmetro, as alterações correspondentes precisam ser feitas nos arquivos de configuração ou .htaccess. No caso do Apache, a última opção é preferível, para o Nginx – a primeira.
Em um apache servidor, você precisa abrir o .htacess arquivo e insira o seguinte código:
<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf|doc|docx)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>
Em seguida, habilite o Validade módulo usando o comando:
sudo a2enmod expires
Depois disso, reinicie o servidor web:
sudo service apache2 restart
E ative o módulo especificando:
ExpiresActive On
Em um nginx servidor, basta adicionar o seguinte código ao arquivo de configuração:
location ~* .(jpg|jpeg|gif|png|ico|css|swf|flv|doc|docx)$ {
root /var/www/yoursite.com;
}
E execute uma recarga de serviço:
sudo service nginx restart
Observe que com essas configurações, o Permitir e Denegar as diretivas serão ignoradas.
Usando compressão de dados
Habilitando a compactação de dados usando Gzip em servidores web Apache e Nginx ajuda a reduzir a quantidade de dados transmitidos entre o servidor e o cliente, o que melhora o desempenho e reduz o tempo de carregamento da página web.
Para habilitar Gzip on apache, você precisa ativar o mod_deflate módulo:
sudo a2enmod deflate
Em seguida, reinicie o servidor web:
sudo service apache2 restart
E finalmente, adicione o seguinte bloco ao arquivo de configuração ou .htaccess:
<IfModule mod_deflate.c>
# Configure compression for specified file types
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript application/json
# If the browser matches the specified pattern, apply compression only to text/html files
BrowserMatch ^Mozilla/4 gzip-only-text/html
# If the browser matches the specified version patterns of Mozilla 4.0.6, 4.0.7, 4.0.8, disable compression
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# If the browser is MSIE (Internet Explorer), disable compression for all files except text/html
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# If the request contains the specified pattern (extensions of image files), disable compression
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
</IfModule>
Esta configuração habilita a compactação para certos tipos de arquivos e desabilita-a para imagens.
No caso de nginx, a configuração ocorre no http bloco do arquivo de configuração. O seguinte código precisa ser adicionado:
gzip on;
gzip_disable "msie6";
# Adds the Vary header, indicating that the response may change depending on the Accept-Encoding header value
gzip_vary on;
# Enables compression for any proxy servers
gzip_proxied any;
# Sets the compression level. A value of 6 provides a good balance between compression efficiency and resource use
gzip_comp_level 6;
# Sets the size of the buffer for compressed data (16 buffers of 8 kilobytes each)
gzip_buffers 16 8k;
# Specifies that data compression should be used only for HTTP version 1.1 and higher
gzip_http_version 1.1;
# Sets the file types that can be compressed
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
Semelhante a apache, aqui os parâmetros de compressão para certos tipos de arquivos são definidos. Após fazer alterações em qualquer um dos servidores web, uma recarga de serviço é necessária:
sudo service apache2 restart
Or
sudo service nginx restart
Ataque DDOS no servidor
Alta carga do servidor pode ocorrer como resultado de um ataque DDoS. Identificar a presença de um ataque DDoS pode ser feito por meio do monitoramento de um aumento repentino no tráfego, solicitações anormais e quedas de desempenho do servidor. Rever logs para solicitações repetidas de um endereço IP ou varredura de porta também pode indicar um possível ataque DDoS. Existem muitas medidas de proteção, mas discutiremos apenas o básico.
Usando uma CDN (Rede de Distribuição de Conteúdo). Uma CDN pode servir como intermediária entre seu servidor web e usuários, distribuindo tráfego e armazenando conteúdo em cache para mitigar o impacto de um ataque DDoS. As CDNs também podem ter mecanismos de proteção DDoS integrados, incluindo distribuição de carga e filtragem de tráfego.
Configuração de firewalls e sistemas de detecção de intrusão (IDS/IPS). Firewalls podem ser configurados para filtrar tráfego com base em vários critérios, como endereços IP e portas. IDS/IPS podem detectar comportamento de tráfego anormal e bloquear conexões suspeitas. Essas ferramentas podem ser eficazes no rastreamento e bloqueio de tráfego potencialmente malicioso.
Configurando servidores web Apache e Nginx para mitigar o impacto de ataques DDoS.
Como solução para o Apache, habilitamos o mod_evasive módulo. Para fazer isso, descomente ou adicione a seguinte linha no httpd.conf or apache2.conf arquivo de configuração:
LoadModule evasive20_module modules/mod_evasive.so
No mesmo arquivo, você precisa adicionar um bloco de configurações:
<IfModule mod_evasive20.c>
# Hash table size for storing request information
DOSHashTableSize 3097
# Number of requests to one page before activating protection
DOSPageCount 2
DOSPageInterval 1
# Number of requests to all pages before activating protection
DOSSiteCount 50
DOSSiteInterval 1
# Blocking period in seconds for IP addresses
DOSBlockingPeriod 10
</IfModule>
Da mesma forma, ativamos o mod_taxalimite módulo:
LoadModule ratelimit_module modules/mod_ratelimit.so
E adicione a configuração:
<IfModule mod_ratelimit.c>
# Setting the output filter for rate limiting (Rate Limit)
SetOutputFilter RATE_LIMIT
# Beginning of the settings block for the location "/login"
<Location "/login">
# Setting the environment variable rate-limit with a value of 1
SetEnv rate-limit 1
# Ending of the settings block for the location "/login"
</Location>
</IfModule>
A configuração para nginx é similar a apache. No nginx.conf arquivo de configuração, as seguintes diretivas precisam ser utilizadas:
http {
...
# Defining a zone for connection limits
limit_conn_zone $binary_remote_addr zone=addr:10m;
# Defining a zone for request limits
limit_req_zone $binary_remote_addr zone=req_zone:10m rate=1r/s;
server {
...
# Configuring connection limits
limit_conn addr 10;
# Configuring request limits
limit_req zone=req_zone burst=5;
...
}
}
Após fazer alterações em cada um dos serviços, eles precisam ser recarregados:
sudo systemctl restart apache2
Ou:
sudo systemctl restart nginx
Esses exemplos fornecem apenas uma configuração básica, que pode ser adaptada dependendo dos requisitos específicos e da natureza dos ataques.
Otimizando consultas MySQL
A otimização de consultas de banco de dados MySQL em um servidor web pode ser alcançada de várias maneiras, e uma delas é a configuração adequada do arquivo de configuração. Normalmente, esse arquivo é chamado meu.cnf or meu.ini e está localizado no / Etc / or /etc/mysql/ diretório. Você precisa abri-lo e fazer as seguintes alterações:
[mysqld]
# Location of the file for recording slow queries. Be sure to replace it with your path
log-slow-queries = /var/log/mariadb/slow_queries.log
# Threshold time for considering slow queries (in seconds)
long_query_time = 5
# Enabling recording of queries that do not use indexes
log-queries-not-using-indexes = 1
# Disabling query caching
query_cache_size = 0
query_cache_type = 0
query_cache_limit = 1M
# Size of temporary tables
tmp_table_size = 16M
max_heap_table_size = 16M
# Size of the thread cache
thread_cache_size = 16
# Disabling name resolving
skip-name-resolve = 1
# Size of the InnoDB buffer pool. Set to 50-70% of available RAM
innodb_buffer_pool_size = 800M
# Size of the InnoDB log file
innodb_log_file_size = 200M
Vamos também considerar recomendações adicionais que podem facilitar a interação com o banco de dados do servidor:
- Use o EXPLIQUE comando antes de uma consulta SQL para analisar sua execução. Isso permite que você obtenha um plano de execução para a consulta e determine quais índices são usados, quais tabelas são escaneadas, etc.
- Os índices aceleram a pesquisa de dados, portanto, índices projetados corretamente podem melhorar significativamente o desempenho da consulta. Preste atenção às colunas que são usadas com frequência em ONDE or Cadastre-se condições.
- Evite usar SELECT *. Especifique apenas as colunas que são realmente necessárias para sua consulta, em vez de selecionar todas as colunas em uma tabela.
- Evite usar funções em ONDE condições. Usando funções (como MAIS BAIXO, UPPER, ESQUERDA, DIREITO) em ONDE condições podem tornar índices inúteis. Tente evitar seu uso direto em condições.
- Uso INNER JOIN sempre que possível, pois geralmente é mais eficiente. Além disso, garanta que as colunas correspondentes para junção tenham índices.
- Uso LIMITE para restringir o número de linhas retornadas se você precisar obter apenas um certo número de resultados.
- Considere armazenar em cache os resultados da consulta, especialmente se eles raramente mudam, para reduzir a carga do servidor.
O servidor de e-mail cria alta carga no servidor
Nesta seção, exploraremos como determinar se o servidor de e-mail está com alta carga e quais etapas podem ser tomadas para otimizar sua operação, incluindo a verificação da fila de mensagens e a configuração dos parâmetros do servidor. Comece verificando a fila de mensagens. correioq O utilitário pode ajudar com isso, para ativá-lo, digite o comando correspondente no terminal:
mailq
Isso exibirá uma lista de mensagens na fila, se houver. Cada mensagem será exibida com seu identificador exclusivo e informações sobre o status de envio. Um resultado semelhante pode ser obtido revisando os logs do cliente de e-mail.
Na maioria dos casos, a alta carga ocorre no caso de comprometimento do servidor quando ele começa a enviar spam. No entanto, se após a verificação o administrador estiver confiante de que o servidor não foi atacado de fora e os usuários não estão negligenciando o spam, é hora de prosseguir para otimizar o servidor de e-mail. Aqui estão as etapas que ajudarão:
- Certifique-se de que os registros DNS do seu domínio estejam configurados corretamente, incluindo SPF, DKIM e DMARC registros para melhorar a entrega de e-mails e proteger contra spam. A configuração correta dos parâmetros pode ser encontrada no artigo sobre diagnóstico do servidor de e-mail.
- Verifique as configurações de rede, incluindo configuração de firewall e regras de roteamento, para evitar bloqueios e acelerar a entrega de e-mails.
- Configure os parâmetros da fila de mensagens de acordo com a carga do servidor. Isso pode incluir a configuração do tamanho máximo da fila e dos tempos limite.
- Considere as soluções que discutimos neste artigo anteriormente. Otimize periodicamente o banco de dados do servidor de e-mail para melhorar o desempenho, use mecanismos de cache para acelerar a pesquisa e o processamento de dados, como consultas DNS.
- Se o servidor de e-mail ainda encontrar carga alta regularmente, considere opções de dimensionamento, como usar um cluster de servidores de e-mail ou soluções em nuvem.
Conclusão
O aumento da carga do servidor afeta diretamente a velocidade de carregamento do site, impactando, em última análise, a experiência do usuário e a reputação em mecanismos de busca. Assim, gerenciar essa carga de forma eficaz desempenha um papel fundamental para garantir a funcionalidade contínua do recurso e aumentar sua acessibilidade para os visitantes.