{"id":20890,"date":"2026-08-22T11:51:32","date_gmt":"2026-08-22T09:51:32","guid":{"rendered":"https:\/\/webhosting.de\/so-reuseport-linux-webserver-performance-optimierung-core\/"},"modified":"2026-08-22T11:51:32","modified_gmt":"2026-08-22T09:51:32","slug":"assim-re-report-linux-servidor-web-otimizacao-de-desempenho-nucleo","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/so-reuseport-linux-webserver-performance-optimierung-core\/","title":{"rendered":"SO_REUSEPORT no Linux: melhor desempenho para servidores Web"},"content":{"rendered":"<p>Vou mostrar como o SO_REUSEPORT acelera os servidores Web Linux com muitas liga\u00e7\u00f5es simult\u00e2neas e elimina os pontos de estrangulamento no <strong>Aceitar<\/strong> eliminado. Para tal, aposto em abordagens pr\u00e1ticas e claras, para que possas tirar mais partido dos sistemas multicore <strong>Desempenho<\/strong> retiras.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<ul>\n  <li><strong>Estrangulamento do Accept<\/strong> evitar e reduzir a lat\u00eancia<\/li>\n  <li><strong>Multicore<\/strong> Utiliza\u00e7\u00e3o eficiente da capacidade atrav\u00e9s da distribui\u00e7\u00e3o do kernel<\/li>\n  <li><strong>Fog\u00e3o de cozinha<\/strong> reduzir significativamente<\/li>\n  <li><strong>Arquitetura<\/strong> simplificar sem o dispatcher do Userland<\/li>\n  <li><strong>Nginx<\/strong> e utilizar diretamente outros servidores<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/webserver-performance-3471.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que o SO_REUSEPORT resolve do ponto de vista t\u00e9cnico<\/h2>\n\n<p>O SO_REUSEPORT atribui a cada worker um socket de escuta pr\u00f3prio, pelo que posso utilizar o cl\u00e1ssico <strong>gargalo<\/strong> evitar no Accept central. Antigamente, tudo dependia de um \u00fanico socket, o que fazia com que os threads entrassem em concorr\u00eancia e os tempos de espera aumentassem. Hoje em dia, o kernel distribui as novas liga\u00e7\u00f5es diretamente por v\u00e1rios sockets, o que reduz o <strong>Lat\u00eancia<\/strong> reduz significativamente. Desta forma, elimino a necessidade de processos de dispatcher separados e evito mudan\u00e7as de contexto. Sob carga elevada, os tempos de resposta mant\u00eam-se mais constantes, uma vez que nenhum listener isolado causa um abrandamento.<\/p>\n\n<h2>SO_REUSEPORT vs. SO_REUSEADDR: uma breve compara\u00e7\u00e3o<\/h2>\n\n<p>O SO_REUSEADDR ajuda-me a reiniciar rapidamente, uma vez que, apesar de <strong>TIME_WAIT<\/strong> pode voltar a ligar-se. SO_REUSEPORT permite outra coisa: v\u00e1rios listeners em simult\u00e2neo na mesma combina\u00e7\u00e3o de IP\/porta. S\u00f3 quando defino SO_REUSEPORT antes da chamada a bind() \u00e9 que o kernel permite a liga\u00e7\u00e3o paralela <strong>Bind<\/strong>-Opera\u00e7\u00e3o. \u00c9 importante ter em conta a ordem: se uma porta estiver ocupada sem esta op\u00e7\u00e3o, n\u00e3o ser\u00e1 poss\u00edvel adicionar mais sockets. Por isso, para workers paralelos, a op\u00e7\u00e3o SO_REUSEPORT \u00e9 fundamental.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/optimierte_webserver_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Funcionamento no kernel: grupos de portas reutiliz\u00e1veis e hash<\/h2>\n\n<p>Todos os sockets com uma combina\u00e7\u00e3o id\u00eantica de IP\/porta e com a op\u00e7\u00e3o SO_REUSEPORT definida s\u00e3o colocados numa <strong>Grupo<\/strong>. O kernel calcula, para cada nova liga\u00e7\u00e3o, um hash com base nos par\u00e2metros de origem e destino. Com base nisso, atribui a liga\u00e7\u00e3o a um listener adequado, distribuindo-as assim de forma relativamente justa. Beneficio de uma melhor localidade da cache, porque cada CPU processa \u201eas suas\u201c liga\u00e7\u00f5es com maior frequ\u00eancia. Para casos especiais, o BPF pode <strong>Sele\u00e7\u00e3o<\/strong> continuar a ajustar, por exemplo, para implementar as suas pr\u00f3prias estrat\u00e9gias.<\/p>\n\n<h2>Pr\u00e1tica: Configurar o Nginx corretamente<\/h2>\n\n<p>No Nginx, ativo o \u00abreuseport\u00bb com a diretiva \u00ablisten\u00bb e utilizo v\u00e1rios <strong>Trabalhador<\/strong>-Processos. Um exemplo: definir \u201eworker_processes\u201c para o n\u00famero de n\u00facleos e, no bloco \u00abserver\u00bb, \u00ablisten 80 reuseport;\u00bb. Desta forma, cada worker recebe o seu pr\u00f3prio listener e o kernel distribui automaticamente as novas liga\u00e7\u00f5es. Para mais detalhes sobre o n\u00famero ideal de workers, consulte o <a href=\"https:\/\/webhosting.de\/pt\/configurar-de-forma-ideal-os-processos-de-trabalho-do-nginx-para-melhorar-o-desempenho\/\">Processos de trabalho do Nginx<\/a>. Desta forma, consigo taxas de pedidos mais elevadas e uma carga de trabalho uniforme nos n\u00facleos.<\/p>\n\n<h2>Utilizar de forma eficiente as CPUs multicore<\/h2>\n\n<p>Com v\u00e1rios workers e SO_REUSEPORT, utilizo <strong>Multicore<\/strong>-sistemas de forma mais uniforme. Atribuo os trabalhadores aos n\u00facleos com base na afinidade da CPU, para reduzir o \u201ecache-hopping\u201c. O RSS\/RPS na placa de rede ajuda a distribuir adequadamente os pacotes recebidos pelas filas. Assim, as liga\u00e7\u00f5es acabam por ser encaminhadas com maior frequ\u00eancia para os n\u00facleos \u00abadequados\u00bb, o que melhora a <strong>Rendimento<\/strong>- aumenta a taxa. O efeito \u00e9 particularmente vis\u00edvel quando h\u00e1 muitas liga\u00e7\u00f5es curtas e processos de estabelecimento de liga\u00e7\u00e3o TLS.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-server-performance-boost-2341.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoriza\u00e7\u00e3o, rein\u00edcios progressivos e armadilhas<\/h2>\n\n<p>Planeio os rein\u00edcios progressivos com cuidado, pois o encerramento de um socket em escuta pode resultar na perda de <strong>Atraso<\/strong>-entradas. Antes de encerrar os workers, deixo as suas filas esvaziarem-se completamente e s\u00f3 depois os retiro do servi\u00e7o. Para os registos, opto por ficheiros separados por cada worker, para poder acompanhar a distribui\u00e7\u00e3o posteriormente. As ferramentas de monitoriza\u00e7\u00e3o t\u00eam de ter em conta v\u00e1rios processos; caso contr\u00e1rio, as m\u00e9tricas podem ser enganadoras. No que diz respeito \u00e0s liga\u00e7\u00f5es de IP, presto aten\u00e7\u00e3o \u00e0 consist\u00eancia, pois, caso contr\u00e1rio, 0.0.0.0 e IPs espec\u00edficos <strong>Conflitos<\/strong> podem produzir.<\/p>\n\n<h2>SO_REUSEPORT para al\u00e9m do HTTP<\/h2>\n\n<p>Este princ\u00edpio tamb\u00e9m me ajuda a <strong>UDP<\/strong>-servi\u00e7os como DNS, streaming ou servidores de jogos. Desta forma, muitos novos pacotes por segundo s\u00e3o distribu\u00eddos por v\u00e1rios listeners, sem que eu precise de um balanceador de carga no espa\u00e7o do utilizador. Os proxies TCP, gateways e plataformas de IoT tamb\u00e9m beneficiam desta configura\u00e7\u00e3o. \u00c9 importante definir o n\u00famero correto de workers, para que o hardware e o software funcionem em sincronia. Combino esta configura\u00e7\u00e3o com regras claras <strong>Limites<\/strong> para descritores de ficheiros e valores de tempo limite corretos.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_nacht_webserver_7834.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Otimiza\u00e7\u00e3o da pilha de rede: IRQ, descarregamentos, buffers<\/h2>\n\n<p>Estou a verificar a distribui\u00e7\u00e3o de IRQ da placa de rede, para que as filas sejam atribu\u00eddas aos <strong>CPU<\/strong>-n\u00facleos. Sempre que faz sentido, utilizo o GRO\/LRO e os offloads, mas testo sempre a lat\u00eancia. Defino os buffers do socket de forma deliberada, uma vez que valores demasiado baixos provocam lentid\u00e3o nos picos e valores demasiado elevados desperdi\u00e7am mem\u00f3ria; mais informa\u00e7\u00f5es em <a href=\"https:\/\/webhosting.de\/pt\/servidor-socket-buffers-hosting-tuning-bufferopti\/\">Buffer de socket<\/a>. Tamb\u00e9m verifico par\u00e2metros sysctl, como somaxconn e net.core.somaxconn, em rela\u00e7\u00e3o ao perfil de carga de trabalho. Mede o efeito de cada altera\u00e7\u00e3o isoladamente, para obter resultados reais <strong>Ganhos<\/strong> para ver.<\/p>\n\n<h2>Compara\u00e7\u00e3o entre as configura\u00e7\u00f5es mais comuns de servidores web<\/h2>\n\n<p>A tabela seguinte apresenta as caracter\u00edsticas t\u00edpicas de v\u00e1rios modelos de \u00ablistener\u00bb e ajuda-me a <strong>Escolha<\/strong> do design. Concentro-me no caminho de aceita\u00e7\u00e3o, na lat\u00eancia sob carga, nas caracter\u00edsticas de escalabilidade, no esfor\u00e7o de arquitetura e na utiliza\u00e7\u00e3o da CPU. Desta forma, consigo identificar rapidamente qual \u00e9 a configura\u00e7\u00e3o mais adequada ao meu perfil de tr\u00e1fego. Separo a teoria da pr\u00e1tica, verificando posteriormente as m\u00e9tricas reais. A <strong>Matriz<\/strong> serve como ponto de partida para testes espec\u00edficos.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Configura\u00e7\u00e3o<\/th>\n      <th>Caminho Accept<\/th>\n      <th>Lat\u00eancia sob carga<\/th>\n      <th>Escalonamento<\/th>\n      <th>Despesas com arquitetura<\/th>\n      <th>Utiliza\u00e7\u00e3o da CPU<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Um listener sem SO_REUSEPORT<\/td>\n      <td>A <strong>Soquete<\/strong><\/td>\n      <td>nasce cedo<\/td>\n      <td>limitado<\/td>\n      <td>baixo<\/td>\n      <td>desigual<\/td>\n    <\/tr>\n    <tr>\n      <td>V\u00e1rios workers com SO_REUSEPORT<\/td>\n      <td>Kernel-<strong>Distribui\u00e7\u00e3o<\/strong><\/td>\n      <td>mais constante<\/td>\n      <td>elevado<\/td>\n      <td>baixo<\/td>\n      <td>mais uniforme<\/td>\n    <\/tr>\n    <tr>\n      <td>Dispatcher do Userland<\/td>\n      <td>recep\u00e7\u00e3o central<\/td>\n      <td>m\u00e9dio<\/td>\n      <td>m\u00e9dio<\/td>\n      <td>elevado<\/td>\n      <td>vari\u00e1vel<\/td>\n    <\/tr>\n    <tr>\n      <td>SO_REUSEPORT + L\u00f3gica BPF<\/td>\n      <td>sele\u00e7\u00e3o personalizada<\/td>\n      <td>muito constante<\/td>\n      <td>Muito elevado<\/td>\n      <td>m\u00e9dio<\/td>\n      <td>muito uniforme<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/entwicklerschreibtisch0391.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Planear bem os testes de desempenho<\/h2>\n\n<p>Estou a testar com e sem SO_REUSEPORT, para verificar se h\u00e1 verdadeiros <strong>Diferen\u00e7as<\/strong> verificar. Os indicadores relevantes s\u00e3o os pedidos por segundo, as lat\u00eancias p95\/p99 e a utiliza\u00e7\u00e3o da CPU por n\u00facleo. Vario o n\u00famero de workers e analiso o ponto ideal entre as mudan\u00e7as de contexto e a utiliza\u00e7\u00e3o. Escolho dados de teste realistas, incluindo TLS, Keep-Alive e conte\u00fados est\u00e1ticos e din\u00e2micos. Registo os resultados de forma a que sejam reproduz\u00edveis, para que mais tarde eu possa <strong>Altera\u00e7\u00f5es<\/strong> pode comparar.<\/p>\n\n<h2>Apache: Como tirar o m\u00e1ximo partido do Event-MPM<\/h2>\n\n<p>O Apache tamb\u00e9m beneficia se eu dissociar o caminho Accept e o <strong>Evento<\/strong>-Operar o MPM corretamente. A escolha entre o MPM de eventos e o MPM de trabalhadores depende do perfil de liga\u00e7\u00e3o e dos recursos. Tenho em conta o Keep-Alive, os conjuntos de threads e os limites para os clientes. Esta vis\u00e3o geral ajuda-me a fazer uma classifica\u00e7\u00e3o sucinta: <a href=\"https:\/\/webhosting.de\/pt\/mpm-event-do-apache-vs-mpm-worker-ajuste-e-otimizacao-do-servidor-web\/\">MPM de eventos vs. MPM de trabalhadores<\/a>. Em conjunto com o SO_REUSEPORT, estou a trabalhar de forma espec\u00edfica para obter uma distribui\u00e7\u00e3o uniforme <strong>Carga<\/strong> por processo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/server-performance-linux-4852.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Limites e nuances da distribui\u00e7\u00e3o<\/h2>\n<p>O SO_REUSEPORT distribui as liga\u00e7\u00f5es recebidas por hash de forma relativamente justa, mas n\u00e3o perfeitamente igualit\u00e1ria. Os picos de carga podem afetar mais intensamente determinados workers durante breves per\u00edodos, caso os par\u00e2metros de origem\/destino provoquem uma distribui\u00e7\u00e3o desfavor\u00e1vel. Por isso, monitorizo as m\u00e9tricas dos trabalhadores (aceita\u00e7\u00f5es, liga\u00e7\u00f5es ativas, CPU) e ajusto o n\u00famero de trabalhadores, as afinidades e as filas RSS. As liga\u00e7\u00f5es Keep-Alive permanecem no listener original, o que proporciona a localiza\u00e7\u00e3o desejada na cache, mas tamb\u00e9m pode conduzir a padr\u00f5es de carga \u201esticky\u201c. Para pedidos muito heterog\u00e9neos (com carga mista de CPU e E\/S), prevejo buffers para absorver picos de curta dura\u00e7\u00e3o.<\/p>\n\n<h2>O caminho \u00abAccept\u00bb em pormenor: Backlog, somaxconn e filas SYN<\/h2>\n<p>Fa\u00e7o a distin\u00e7\u00e3o entre a fila de lista (SYN-Backlog) e a fila de aceita\u00e7\u00e3o. Par\u00e2metros como net.ipv4.tcp_max_syn_backlog, tcp_syncookies e net.core.somaxconn influenciam o n\u00famero de tentativas de liga\u00e7\u00e3o e de sockets totalmente estabelecidos que s\u00e3o mantidos. O backlog aplica-se separadamente a cada socket de escuta \u2013 com SO_REUSEPORT, a capacidade te\u00f3rica do buffer multiplica-se por todos os workers. Na pr\u00e1tica, por\u00e9m, a limita\u00e7\u00e3o \u00e9 imposta pela placa de rede (NIC) e pela carga da CPU. Mantenho os backlogs consistentes e medo as taxas de perda e de retransmiss\u00e3o para detetar precocemente eventuais estrangulamentos.<\/p>\n\n<h2>Detalhes do Nginx: accept_mutex, encerramento dos workers e TLS<\/h2>\n<p>Assim que utilizo o reuseport, desativo o accept_mutex no Nginx, uma vez que o kernel se encarrega da atribui\u00e7\u00e3o equitativa. No rein\u00edcio progressivo, defino a op\u00e7\u00e3o \u201egraceful\u201c e aguardo o t\u00e9rmino das liga\u00e7\u00f5es Keep-Alive, para que nenhuma transfer\u00eancia demorada seja interrompida. No que diz respeito ao TLS, garanto que haja chaves de bilhete comuns entre os workers\/inst\u00e2ncias, para que a retoma e os IDs de sess\u00e3o funcionem independentemente do listener atribu\u00eddo. Verifico se os workers n\u00e3o ficam demasiado grandes (p\u00e9 de cache e de mem\u00f3ria), para evitar caches frios nas mudan\u00e7as de processo.<\/p>\n\n<h2>Ativa\u00e7\u00e3o de sockets do systemd, contentores e orquestra\u00e7\u00e3o<\/h2>\n<p>Se o systemd abrir sockets antecipadamente, tem de definir SO_REUSEPORT; caso contr\u00e1rio, as liga\u00e7\u00f5es paralelas ficam bloqueadas. Em ambientes de contentores, certifico-me de que, por cada pod\/contentor, o n\u00famero pretendido de workers cria efetivamente os processos necess\u00e1rios e de que a atribui\u00e7\u00e3o de CPU do cgroup corresponde \u00e0 estrat\u00e9gia de afinidade. Nos orquestradores, planeio a estrat\u00e9gia de atualiza\u00e7\u00e3o cont\u00ednua de forma a que o grupo Reuseport permane\u00e7a est\u00e1vel durante as implementa\u00e7\u00f5es e n\u00e3o bloqueie nenhuma porta de forma exclusiva. As verifica\u00e7\u00f5es de integridade n\u00e3o devem gerar ru\u00eddo desnecess\u00e1rio por cada trabalhador nem distorcer a distribui\u00e7\u00e3o.<\/p>\n\n<h2>Consci\u00eancia NUMA e localidade da mem\u00f3ria<\/h2>\n<p>Em sistemas NUMA, associo os workers aos n\u00facleos do mesmo n\u00f3 NUMA e garanto que as IRQs das placas de rede sejam encaminhadas preferencialmente para l\u00e1. Monitorizo os acessos \u00e0 mem\u00f3ria remota e as migra\u00e7\u00f5es de p\u00e1ginas, pois s\u00e3o estes que provocam picos de lat\u00eancia. Quando a carga de trabalho escala significativamente, pode fazer sentido uma replica\u00e7\u00e3o por n\u00f3 NUMA com a sua pr\u00f3pria porta\/front-end; em combina\u00e7\u00e3o com SO_REUSEPORT, consigo lat\u00eancias muito est\u00e1veis, desde que os percursos de dados e de c\u00f3digo permane\u00e7am locais ao n\u00f3.<\/p>\n\n<h2>HTTP\/3 e o enfoque no UDP<\/h2>\n<p>No HTTP\/3 (QUIC), beneficio particularmente do SO_REUSEPORT no caminho UDP: muitos handshakes e liga\u00e7\u00f5es curtas s\u00e3o distribu\u00eddos sem a necessidade de um balanceador de carga adicional no userland. Asseguro-me de que os buffers UDP t\u00eam dimens\u00e3o suficiente e verifico os contadores de pacotes perdidos por fila. Uma vez que as liga\u00e7\u00f5es QUIC se ligam logicamente ao 5-tuple, a distribui\u00e7\u00e3o permanece est\u00e1vel; no entanto, protejo-me com estrat\u00e9gias consistentes de repeti\u00e7\u00e3o de tentativas e tokens, para que a sele\u00e7\u00e3o do worker se mantenha transparente e com bom desempenho.<\/p>\n\n<h2>Ajuste fino do eBPF para o Reuseport<\/h2>\n<p>Com um programa BPF do Reuseport, posso controlar ainda mais a sele\u00e7\u00e3o de sockets, por exemplo, com base no nome de host de destino (SNI), em prioridades locais ou na carga por worker. S\u00f3 recorro a isso quando a distribui\u00e7\u00e3o por hash padr\u00e3o n\u00e3o \u00e9 suficiente, pois a l\u00f3gica adicional aumenta a complexidade. Para a resolu\u00e7\u00e3o de problemas, verifico se os programas BPF est\u00e3o realmente carregados e a funcionar sem erros, e tenho uma estrat\u00e9gia de fallback preparada, caso seja necess\u00e1rio descarregar a pol\u00edtica.<\/p>\n\n<h2>Resili\u00eancia e seguran\u00e7a DDoS<\/h2>\n<p>O SO_REUSEPORT aumenta a capacidade de aceita\u00e7\u00e3o \u2013 o que representa tanto uma vantagem como um risco. Estabele\u00e7o limites de taxa e de liga\u00e7\u00f5es por trabalhador, para que os processos individuais n\u00e3o fiquem sobrecarregados de forma desequilibrada. Em combina\u00e7\u00e3o com SYN-Cookies, tempos de espera moderados e limites L7 bem definidos, evito que picos de carga ocupem recursos de forma permanente. Separo os registos para detetar mais rapidamente padr\u00f5es de abuso por trabalhador e, se necess\u00e1rio, utilizo o iptables\/nftables para limitar precocemente as fontes maliciosas.<\/p>\n\n<h2>Depura\u00e7\u00e3o e verifica\u00e7\u00e3o<\/h2>\n<p>Verifico a configura\u00e7\u00e3o com o comando \u00abss -ltnp\u00bb (TCP) ou \u00abss -lunp\u00bb (UDP) para ver se existem v\u00e1rios listeners na mesma combina\u00e7\u00e3o de IP\/porta. Com o \u00abperf\u00bb, o \u00abtop\/htop\u00bb e o \u00abmpstat\u00bb, verifico se a utiliza\u00e7\u00e3o da CPU est\u00e1 equilibrada. Os contadores do netstat\/ss, as mensagens do dmesg e as estat\u00edsticas de pacotes descartados da NIC (ethtool -S) indicam se as filas est\u00e3o a ficar sobrecarregadas. Para an\u00e1lises mais aprofundadas, o tcpdump e os eventos do Perf fornecem informa\u00e7\u00f5es sobre os percursos de aceita\u00e7\u00e3o, retransmiss\u00f5es e novas tentativas. A correla\u00e7\u00e3o continua a ser importante: analise sempre as m\u00e9tricas por trabalhador, por CPU e por fila.<\/p>\n\n<h2>Evitar erros de configura\u00e7\u00e3o frequentes<\/h2>\n<ul>\n  <li>Um worker sem SO_REUSEPORT estabelece a liga\u00e7\u00e3o em primeiro lugar e bloqueia todos os outros.<\/li>\n  <li>Utiliza\u00e7\u00e3o mista de 0.0.0.0 e endere\u00e7os IP espec\u00edficos \u2013 os ouvintes s\u00e3o agrupados em grupos separados.<\/li>\n  <li>O `accept_mutex` no Nginx \u00e9 ativado apesar do `reuseport` \u2013 serializa\u00e7\u00e3o desnecess\u00e1ria.<\/li>\n  <li>Backlogs inadequados: o somaxconn \u00e9 menor do que o backlog definido no servidor.<\/li>\n  <li>Sem configura\u00e7\u00e3o conjunta do bilhete TLS \u2013 a taxa de retoma desce drasticamente.<\/li>\n  <li>RSS mal dimensionado \u2013 a carga de IRQ concentra-se em poucos n\u00facleos.<\/li>\n<\/ul>\n\n<h2>Planeamento da capacidade: dimens\u00e3o dos trabalhadores e limites de FD<\/h2>\n<p>Equilibro o n\u00famero de workers em fun\u00e7\u00e3o da mem\u00f3ria RAM por worker, dos ficheiros abertos e do n\u00famero de liga\u00e7\u00f5es. Demasiados processos aumentam as trocas de contexto e a press\u00e3o sobre a cache; muito poucos desperdi\u00e7am o potencial de paralelismo. Defino os limites dos descritores de ficheiros de forma generosa e consistente (ulimit, limites do systemd, limites r\u00edgidos\/flex\u00edveis), pois cada worker necessita dos seus pr\u00f3prios descritores de ficheiros para sockets, registos e liga\u00e7\u00f5es a n\u00edvel superior. Al\u00e9m disso, prevejo um n\u00famero suficiente de portas ef\u00e9meras e monitorizo o volume de TIME_WAIT, para que picos de tr\u00e1fego de curta dura\u00e7\u00e3o n\u00e3o fiquem sem destino.<\/p>\n\n<h2>Testes de desempenho: armadilhas t\u00edpicas<\/h2>\n<p>Pr\u00e9-aque\u00e7o os servidores e as caches, calibro o gerador de carga (para evitar gargalos ocultos) e separo a rede de controlo da rede de dados. Os testes decorrem durante tempo suficiente para medir os valores p99\/p999 de forma est\u00e1vel e variam os tempos de reflex\u00e3o (Think-Times), as taxas de Keep-Alive e os par\u00e2metros TLS. Registo as configura\u00e7\u00f5es do kernel e do servidor, para que as execu\u00e7\u00f5es posteriores continuem a ser compar\u00e1veis. Quando utilizo pol\u00edticas eBPF, documento separadamente a sua vers\u00e3o e o seu efeito, para n\u00e3o confundir causa e efeito.<\/p>\n\n<h2>Lista de controlo para o in\u00edcio<\/h2>\n\n<p>Primeiro, verifico a vers\u00e3o do kernel e certifico-me de que SO_REUSEPORT est\u00e1 dispon\u00edvel e configurado corretamente <strong>definido<\/strong> . Em seguida, ativo a op\u00e7\u00e3o na configura\u00e7\u00e3o do servidor web e defino o n\u00famero desejado de workers. Verifico o somaxconn, os limites dos descritores de ficheiro e as filas da placa de rede. Depois, realizo testes de carga, comparo m\u00e9tricas e itero. Por fim, otimizo o registo, a estrat\u00e9gia de rein\u00edcio e <strong>afinidade<\/strong> de.<\/p>\n\n<h2>Resumo<\/h2>\n\n<p>O SO_REUSEPORT elimina o gargalo do Accept, distribui novas liga\u00e7\u00f5es atrav\u00e9s do hash do kernel e obt\u00e9m um melhor desempenho em sistemas multicore <strong>Rendimento<\/strong> . Utilizo v\u00e1rios listeners por porta, evito o problema do \u201eThundering Herd\u201c e poupo-me de ter de utilizar um dispatcher separado. No Nginx, isto consegue-se com \u00ablisten \u2026 reuseport\u00bb e um n\u00famero adequado de workers. Juntamente com a afinidade da CPU, uma distribui\u00e7\u00e3o adequada de IRQs e buffers adequados, garanto um desempenho constante <strong>Lat\u00eancias<\/strong> sob carga. Quem verificar, testar e ajustar com precis\u00e3o estes passos aumenta o desempenho sem custos adicionais com hardware em euros.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubra como o SO_REUSEPORT melhora o desempenho do seu servidor web no Linux. Saiba como funciona esta op\u00e7\u00e3o de socket e como a pode utilizar no Nginx e noutros servi\u00e7os.<\/p>","protected":false},"author":1,"featured_media":20883,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20890","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"110","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"SO_REUSEPORT Linux","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20883","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20890","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=20890"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20890\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20883"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20890"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20890"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20890"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}