{"id":20906,"date":"2026-08-22T18:18:36","date_gmt":"2026-08-22T16:18:36","guid":{"rendered":"https:\/\/webhosting.de\/nginx-sendfile-tcp-nopush-ratgeber-performance-setup\/"},"modified":"2026-08-22T18:18:36","modified_gmt":"2026-08-22T16:18:36","slug":"nginx-sendfile-tcp-nopush-guia-de-desempenho-configuracao","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/nginx-sendfile-tcp-nopush-ratgeber-performance-setup\/","title":{"rendered":"Utilizar corretamente o `sendfile` e o `tcp_nopush` do NGINX para obter o m\u00e1ximo desempenho"},"content":{"rendered":"<p>Com <strong>nginx sendfile<\/strong> e <strong>tcp_nopush<\/strong> Entreguei ficheiros est\u00e1ticos em modo \u00abzero-copy\u00bb do sistema de ficheiros para o socket, reduzindo assim de forma percet\u00edvel tanto a carga da CPU como o n\u00famero de pacotes. Quando corretamente configuradas, ambas as diretivas aumentam a efici\u00eancia da transmiss\u00e3o, reduzem a sobrecarga e estabelecem as bases para uma otimiza\u00e7\u00e3o adequada do nginx no que diz respeito a recursos e transfer\u00eancias.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>C\u00f3pia zero<\/strong> atrav\u00e9s do `sendfile`: menos c\u00f3pias, maior d\u00e9bito<\/li>\n  <li><strong>tcp_nopush<\/strong> armazena pacotes em buffer: quadros maiores, menos sobrecarga<\/li>\n  <li><strong>Combina\u00e7\u00e3o<\/strong> conta: sendfile + tcp_nopush + tcp_nodelay<\/li>\n  <li><strong>Casos de utiliza\u00e7\u00e3o<\/strong> priorizar: recursos est\u00e1ticos, downloads de grande dimens\u00e3o<\/li>\n  <li><strong>Testes<\/strong> No caso do NFS\/SMB: avaliar o impacto; se necess\u00e1rio, desativar o `sendfile`<\/li>\n<\/ul>\n\n<h2>Por que \u00e9 que o `sendfile` melhora tanto o desempenho do NGINX?<\/h2>\n\n<p>Eu ativo <strong>sendfile<\/strong>, porque o kernel consegue enviar ficheiros diretamente atrav\u00e9s da pilha de rede, sem ter de passar por opera\u00e7\u00f5es de c\u00f3pia adicionais no espa\u00e7o do utilizador. Este percurso \u00abzero-copy\u00bb reduz as mudan\u00e7as de contexto e poupa ciclos da CPU, especialmente quando muitos clientes simult\u00e2neos acedem a conte\u00fados est\u00e1ticos. Ficheiros de grande dimens\u00e3o, como imagens, CSS, JavaScript ou arquivos, beneficiam disso, uma vez que a transfer\u00eancia de dados ocorre de forma mais uniforme e com menos sobrecarga. Os caches do sistema tamb\u00e9m funcionam de forma mais eficiente, pois ocorrem menos movimentos de mem\u00f3ria e o kernel controla o percurso dos dados. \u00c9 nos sistemas de ficheiros locais que a vantagem se torna mais evidente, raz\u00e3o pela qual fa\u00e7o as medi\u00e7\u00f5es primeiro a\u00ed, antes de as aplicar a configura\u00e7\u00f5es mais ex\u00f3ticas.<\/p>\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\/nginx-server-setup-8934.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que o tcp_nopush faz exatamente e em que situa\u00e7\u00f5es se destaca<\/h2>\n\n<p>Com <strong>tcp_nopush<\/strong> Pe\u00e7o ao sistema que s\u00f3 envie pacotes TCP quando estes estiverem devidamente preenchidos, em vez de enviar segmentos pequenos prematuramente. No Linux, isto corresponde a TCP_CORK; no FreeBSD, a TCP_NOPUSH; e, em ambos os casos, o n\u00famero de pacotes diminui de forma mensur\u00e1vel. Esta diretiva n\u00e3o reduz a lat\u00eancia ao m\u00ednimo, mas visa uma melhor rela\u00e7\u00e3o entre dados \u00fateis e sobrecarga. Utilizo o `tcp_nopush` especificamente em ficheiros est\u00e1ticos, porque \u00e9 a\u00ed que os fluxos de dados cont\u00ednuos proporcionam os maiores ganhos de efici\u00eancia. Sem o `sendfile`, o `tcp_nopush` fica sem efeito; por isso, integro sempre ambas as configura\u00e7\u00f5es em conjunto.<\/p>\n\n<h2>sendfile e tcp_nopush em conjunto: \u00e9 assim que estabele\u00e7o as bases<\/h2>\n\n<p>A combina\u00e7\u00e3o de <strong>sendfile<\/strong> e o tcp_nopush reduz as c\u00f3pias e agrupa os pacotes, permitindo que um servidor por n\u00facleo de CPU consiga lidar com um n\u00famero significativamente maior de transfer\u00eancias paralelas. Configuro ambos no n\u00edvel de contexto http e, frequentemente, adiciono o tcp_nodelay para que o \u00faltimo resqu\u00edcio de um fluxo seja transmitido sem tempo de espera. Continua a ser importante realizar testes com tr\u00e1fego real, uma vez que os tamanhos dos pacotes, o MTU e os clientes variam, e o melhor equil\u00edbrio pode diferir ligeiramente consoante a carga de trabalho. Para diret\u00f3rios est\u00e1ticos, a ativa\u00e7\u00e3o global \u00e9 normalmente suficiente, enquanto que, no caso de rotas de resposta din\u00e2micas, presto aten\u00e7\u00e3o ao impacto. Esta combina\u00e7\u00e3o proporciona uma base s\u00f3lida para futuras etapas de otimiza\u00e7\u00e3o do nginx, que ser\u00e3o implementadas posteriormente.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>diretiva<\/th>\n      <th>Objetivo<\/th>\n      <th>Efeito t\u00edpico<\/th>\n      <th>Depend\u00eancia<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>ativar o sendfile<\/strong><\/td>\n      <td>Zero-Copy de ficheiro para socket<\/td>\n      <td>Menos carga na CPU, maior rendimento<\/td>\n      <td>Sistema de ficheiros local ideal<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>tcp_nopush ativado<\/strong><\/td>\n      <td>Preencher as encomendas, reduzir os custos gerais<\/td>\n      <td>Menos segmentos por ficheiro<\/td>\n      <td>Funciona apenas com o sendfile<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>tcp_nodelay on<\/strong><\/td>\n      <td>Enviar os \u00faltimos bytes sem esperar<\/td>\n      <td>Conclus\u00e3o r\u00e1pida da transfer\u00eancia<\/td>\n      <td>Adicionado tcp_nopush<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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\/nginx_performance_meeting_8371.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>\u00c9 assim que o tcp_nodelay interage com o tcp_nopush<\/h2>\n\n<p>Eu ativo <strong>tcp_nopush<\/strong>, para enviar o in\u00edcio de uma transfer\u00eancia em pacotes maiores e, ao mesmo tempo, ativar o tcp_nodelay para que a conclus\u00e3o n\u00e3o fique bloqueada. Ambas as configura\u00e7\u00f5es atuam em fases diferentes do fluxo e n\u00e3o se interferem mutuamente quando o NGINX entrega ficheiros atrav\u00e9s do sendfile. Especialmente no caso de muitos ficheiros pequenos, o tcp_nodelay evita que o cliente tenha de esperar desnecessariamente devido a pequenos volumes de dados restantes. Testo primeiro esta combina\u00e7\u00e3o no ambiente de staging, observo os RTTs e os tamanhos dos segmentos e comparo-os com as m\u00e9tricas em produ\u00e7\u00e3o. Desta forma, garanto efici\u00eancia no in\u00edcio e rapidez no final da transfer\u00eancia.<\/p>\n\n<pre><code>http {\n    sendfile on;\n    tcp_nopush on;\n    tcp_nodelay on;\n}\n<\/code><\/pre>\n\n<h2>Cen\u00e1rios t\u00edpicos de aplica\u00e7\u00e3o: onde as diretivas t\u00eam um forte impacto<\/h2>\n\n<p>Para grandes <strong>Transfer\u00eancias<\/strong> Tal como acontece com v\u00eddeos, arquivos ou imagens ISO, o percurso \u00abzero-copy\u00bb do kernel reduz significativamente o tempo de CPU por transfer\u00eancia. Em configura\u00e7\u00f5es semelhantes a CDN, com muitos ficheiros CSS, JS e de tipos de letra, o tcp_nopush poupa segmentos e, assim, aumenta a largura de banda utiliz\u00e1vel por socket. Em sites WordPress com um bom cache, a maioria dos pedidos diz respeito a recursos est\u00e1ticos, pelo que noto o efeito muito rapidamente nesse contexto. Tamb\u00e9m os artefactos de compila\u00e7\u00e3o, as imagens de contentores ou os instaladores beneficiam desta funcionalidade, desde que se encontrem localmente e n\u00e3o sejam acedidos atrav\u00e9s de um sistema de ficheiros de rede inst\u00e1vel. Quem prev\u00ea picos de carga consegue, com esta combina\u00e7\u00e3o, tirar o m\u00e1ximo partido da estabilidade do hardware dispon\u00edvel.<\/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\/nginx-performance-optimization-2378.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Exemplo pr\u00e1tico: NGINX para WordPress com cache e recursos<\/h2>\n\n<p>Nas configura\u00e7\u00f5es do WordPress, defino <strong>sendfile<\/strong>, tcp_nopush e tcp_nodelay a n\u00edvel global, forne\u00e7o recursos est\u00e1ticos diretamente e mantenho o PHP-FPM bem separado dos caminhos din\u00e2micos. Adiciono cabe\u00e7alhos de cache adequados para imagens, CSS e JavaScript, para que os navegadores fa\u00e7am menos idas e voltas. Quando forne\u00e7o respostas do tipo streaming, tenho em conta a intera\u00e7\u00e3o com o buffer e testo como os tamanhos dos blocos afetam a lat\u00eancia e a taxa de transfer\u00eancia; para tal, a vis\u00e3o geral sobre <a href=\"https:\/\/webhosting.de\/pt\/http-resposta-streaming-alojamento-desempenho-chunks\/\">Transmiss\u00e3o de respostas em blocos<\/a>. No caso de conte\u00fados baseados em texto, recorro \u00e0 compress\u00e3o, sem compactar arquivos bin\u00e1rios desnecessariamente. Desta forma, o fluxo de pedidos mant\u00e9m-se est\u00e1vel, a CPU fica menos sobrecarregada e o tempo at\u00e9 ao primeiro byte \u00e9 curto.<\/p>\n\n<pre><code>http {\n    sendfile on;\n    tcp_nopush on;\n    tcp_nodelay on;\n\n keepalive_timeout 65;\n    gzip on;\n    gzip_types text\/css application\/javascript image\/svg+xml;\n\n    server {\n listen 80;\n server_name blog.example.com;\n root \/var\/www\/blog;\n\n location \/ {\n try_files $uri $uri\/ \/index.php?$args;\n }\n\n        location ~ \\.php$ {\n include fastcgi_params;\n fastcgi_pass unix:\/run\/php\/php-fpm.sock;\n            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n }\n\n location ~* \\.(jpg|jpeg|png|gif|css|js|ico|svg|woff2?)$ {\n expires 30d;\n add_header Cache-Control \"public, max-age=2592000\";\n }\n    }\n}\n<\/code><\/pre>\n\n<h2>Quando desativo deliberadamente a fun\u00e7\u00e3o `sendfile`<\/h2>\n\n<p>Eu troco <strong>sendfile<\/strong> quando os ficheiros se encontram em NFS, SMB ou sistemas de ficheiros distribu\u00eddos, que, no meu teste, apresentam taxas de transfer\u00eancia mais baixas. Alguns controladores ou lat\u00eancias no caminho de armazenamento anulam a vantagem do Zero-Copy, raz\u00e3o pela qual as medi\u00e7\u00f5es s\u00e3o determinantes. Em caso de comportamentos espor\u00e1dicos da rede, desativo primeiro o tcp_nopush para isolar os efeitos, antes de questionar o pr\u00f3prio sendfile. Tamb\u00e9m bugs invulgares do kernel ou pilhas mais antigas podem ser motivos para mudar temporariamente para o caminho cl\u00e1ssico de leitura e escrita. O importante \u00e9 implementar as altera\u00e7\u00f5es gradualmente e comprov\u00e1-las com m\u00e9tricas.<\/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\/nginx_performance_3456.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Fontes de erro que tenho sempre em aten\u00e7\u00e3o<\/h2>\n\n<p>Primeiro verifico se <strong>tcp_nopush<\/strong> esteja ativado acidentalmente, enquanto o `sendfile` permanece desativado, pois, nesse caso, a configura\u00e7\u00e3o n\u00e3o surte efeito. No que diz respeito a caminhos din\u00e2micos, observo se o armazenamento em buffer adicional aumenta a lat\u00eancia e avalio os benef\u00edcios em rela\u00e7\u00e3o ao tempo de resposta. Em redes de alta lat\u00eancia, avalio se pacotes maiores ajudam realmente ou se preciso ajustar os tamanhos dos segmentos e o keep-alive. A configura\u00e7\u00e3o do MTU e as funcionalidades de offloading da placa de rede tamb\u00e9m podem alterar visivelmente o resultado. Registos organizados, amostras pcap e m\u00e9tricas do sistema correlacionadas mostram-me rapidamente onde devo fazer ajustes.<\/p>\n\n<h2>Uma abordagem hol\u00edstica ao desempenho do NGINX: outros ajustes poss\u00edveis<\/h2>\n\n<p>Al\u00e9m de <strong>sendfile<\/strong> Vale a pena definir o n\u00famero correto de `worker_processes` e `worker_connections`, para n\u00e3o limitar artificialmente os sockets. No Linux, utilizo o epoll e garanto que haja descritores de ficheiros suficientes, para que os picos de carga n\u00e3o provoquem estrangulamentos. Para conte\u00fados de texto, ativo o gzip ou o Brotli e verifico se o n\u00edvel de compress\u00e3o sobrecarrega a CPU de forma razo\u00e1vel. Ao n\u00edvel da camada de transporte, mantenho as liga\u00e7\u00f5es abertas por mais tempo e otimizo o Keep-Alive, para o que serve o guia <a href=\"https:\/\/webhosting.de\/pt\/http-keep-alive-ajuste-otimizacao-do-desempenho-da-carga-do-servidor-fluxo\/\">Ajuste do Keep Alive<\/a> fornece orienta\u00e7\u00f5es pr\u00e1ticas. O TLS, a reutiliza\u00e7\u00e3o de sess\u00f5es e o HTTP\/2 ou HTTP\/3 completam a configura\u00e7\u00e3o e permitem um elevado n\u00edvel de paralelismo com uma lat\u00eancia moderada.<\/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\/nginx_performance_4203.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Limites e casos especiais: TLS, HTTP\/2\/3 e proxy<\/h2>\n\n<p>Tenho em conta que <strong>sendfile<\/strong> aplica-se tecnicamente apenas a percursos de ficheiros n\u00e3o encriptados ou a fun\u00e7\u00f5es espec\u00edficas do kernel. No TLS cl\u00e1ssico, o NGINX encripta os bytes no espa\u00e7o do utilizador, pelo que a vantagem do \u00abzero-copy\u00bb deixa de existir; os kernels modernos podem, em parte, transferir a encripta\u00e7\u00e3o para o kernel, o que restabelece esse efeito, mas n\u00e3o est\u00e1 dispon\u00edvel em todas as configura\u00e7\u00f5es. No caso de <strong>HTTP\/2<\/strong> os dados est\u00e3o em frames, v\u00e1rias respostas partilham uma liga\u00e7\u00e3o TCP e o NGINX reorganiza ativamente os bytes \u2013 neste caso, o sendfile \u00e9 menos relevante. <strong>HTTP\/3<\/strong> baseia-se no UDP\/QUIC e segue regras diferentes, pelo que consigo obter ganhos de efici\u00eancia principalmente atrav\u00e9s de buffers, controlo de congestionamento e tamanhos de blocos corretamente selecionados. Como <strong>Proxy invertido<\/strong> O sendfile s\u00f3 funciona se eu estiver efetivamente a servir ficheiros a partir do sistema de ficheiros local; respostas de <em>proxy_pass<\/em> ou <em>fastcgi_pass<\/em> passam, de qualquer forma, pelo espa\u00e7o do utilizador. Por isso, separo rigorosamente os recursos do caminho din\u00e2mico, para que a abordagem \u00abzero-copy\u00bb seja aproveitada ao m\u00e1ximo.<\/p>\n\n<h2>Compreender corretamente a compress\u00e3o: gzip\/Brotli versus gzip_static<\/h2>\n\n<p>Sempre que o NGINX comprime conte\u00fados em tempo real, tem de ler o ficheiro, process\u00e1-lo e gravar o resultado \u2013 e, nesse processo, perde <strong>sendfile<\/strong> a sua vantagem. Por isso, no que diz respeito aos recursos est\u00e1ticos, utilizo, sempre que poss\u00edvel, <em>pr\u00e9-comprimidos<\/em> Ficheiros (por exemplo, .gz ou .br) e fa\u00e7o com que sejam entregues diretamente. Desta forma, mant\u00e9m-se a rota \u00abzero-copy\u00bb, porque o NGINX pode transferir o ficheiro pr\u00e9-comprimido tal como qualquer outro recurso. Para conte\u00fados com grande volume de texto e que raramente s\u00e3o alterados, consigo assim poupar recursos da CPU e obter um d\u00e9bito est\u00e1vel, sem comprometer o tempo de transmiss\u00e3o. No caso de ficheiros bin\u00e1rios e formatos j\u00e1 comprimidos, evito qualquer compress\u00e3o em tempo de execu\u00e7\u00e3o \u2013 aqui, o que conta \u00e9 a taxa de transfer\u00eancia pura de E\/S, e o `sendfile` juntamente com o `tcp_nopush` revelam os seus pontos fortes.<\/p>\n\n<h2>AIO, directio e Page Cache: padr\u00f5es para ficheiros pequenos e grandes<\/h2>\n\n<p>Eu combino <strong>sendfile<\/strong> com E\/S ass\u00edncrona e acesso direto ao disco, para alcan\u00e7ar o melhor desempenho em fun\u00e7\u00e3o do tamanho do ficheiro. Os ficheiros pequenos a m\u00e9dios beneficiam da cache de p\u00e1ginas do kernel e permanecem no caminho do `sendfile`. Por outro lado, os ficheiros muito grandes podem esvaziar a cache; nesse caso, leio-os especificamente com <em>dire\u00e7\u00e3o<\/em> fora da cache e utilizo threads AIO. Desta forma, alivio a carga na mem\u00f3ria e mantenho baixa a lat\u00eancia para outras solicita\u00e7\u00f5es. Um padr\u00e3o t\u00edpico \u00e9 o seguinte:<\/p>\n\n<pre><code>http {\n    # Caminho padr\u00e3o: Zero-Copy a partir do cache de p\u00e1ginas\n    sendfile on;\n    tcp_nopush on;\n    tcp_nodelay on;\n\n # Ficheiros grandes: ignorar o cache e ler de forma ass\u00edncrona\n    aio threads;\n    directio 4m; o # s\u00f3 se aplica a ficheiros &gt;= 4 MiB\n    output_buffers 1 512k;    Buffers # para percursos directio\n    sendfile_max_chunk 1m;    Equil\u00edbrio sob carga elevada\n}\n<\/code><\/pre>\n\n<p>Com esta escalonagem, os ficheiros pequenos mant\u00eam-se extremamente eficientes, enquanto as transfer\u00eancias muito grandes n\u00e3o sobrecarregam a mem\u00f3ria de trabalho. Importante: o directio desativa a rota sendfile para os ficheiros em quest\u00e3o \u2013 exatamente como pretendo para o caso de utiliza\u00e7\u00e3o de ficheiros de grande dimens\u00e3o.<\/p>\n\n<h2>Equidade e controlo do fluxo sob carga<\/h2>\n\n<p>Em per\u00edodos de elevada carga, pretendo evitar que um \u00fanico fluxo monopolize a CPU ou o socket. Eu defino <strong>sendfile_max_chunk<\/strong>, para que o NGINX devolva o kernel ap\u00f3s uma quantidade definida de bytes e d\u00ea espa\u00e7o a outras liga\u00e7\u00f5es. Para o controlo da largura de banda, ajudam <em>limit_rate<\/em> e <em>limit_rate_after<\/em>, por exemplo, para limitar os downloads em massa, mantendo os recursos da interface de utilizador a funcionar rapidamente. Com <em>postpone_output<\/em> controlo a partir de que tamanho de resposta o NGINX come\u00e7a a enviar \u2013 em combina\u00e7\u00e3o com o tcp_nopush, garanto assim um corte de pacotes adequado. Al\u00e9m disso, presto aten\u00e7\u00e3o a <em>lingering_close<\/em>, para que os pacotes restantes sejam transmitidos corretamente e o socket n\u00e3o seja encerrado abruptamente.<\/p>\n\n<h2>Sistemas de ficheiros, pr\u00e9-leitura e caminhos de armazenamento<\/h2>\n\n<p>Porque <strong>sendfile<\/strong> Quando se utilizam caches de p\u00e1gina, o sistema de ficheiros subjacente desempenha um papel importante. Verifico os valores de pr\u00e9-leitura e mantenho-os de forma a que as sequ\u00eancias de leitura de ficheiros de grande dimens\u00e3o n\u00e3o fiquem bloqueadas, sem, no entanto, suplantar os recursos mais pequenos. Em <em>ext4<\/em> ou <em>xfs<\/em> Observo como o prefetching e o agendador de E\/S se adaptam bem ao meu padr\u00e3o de d\u00e9bito. Nos sistemas de ficheiros de rede (NFS\/SMB), testo rigorosamente os par\u00e2metros rsize\/wsize, o cache e as lat\u00eancias, pois mesmo pequenos desvios neutralizam a vantagem do zero-copy. A minha regra continua a ser: primeiro, explorar ao m\u00e1ximo os caminhos locais; depois, ajustar cuidadosamente as pilhas externas \u2013 e dar sempre prioridade aos valores medidos em detrimento da intui\u00e7\u00e3o.<\/p>\n\n<h2>Ajustar de forma pragm\u00e1tica a pilha de rede e o offloading da placa de rede<\/h2>\n\n<p>Para um n\u00famero elevado de liga\u00e7\u00f5es, confio no ajuste autom\u00e1tico dos buffers das pilhas modernas, mas, se necess\u00e1rio, ajusto os buffers de envio e de rece\u00e7\u00e3o. As fun\u00e7\u00f5es de descarregamento da placa de rede (NIC), como TSO, GSO e GRO, reduzem sensivelmente a carga da CPU; no entanto, nas medi\u00e7\u00f5es, procuro ter cuidado, pois as capturas de pacotes podem parecer distorcidas devido ao descarregamento (aparentemente, poucos segmentos muito grandes). Por isso, correlaciono <em>pcap<\/em>\u2011Traces com m\u00e9tricas do NGINX e do kernel, para distinguir os tamanhos reais dos dados transmitidos dos artefactos de offload. No caso de picos de lat\u00eancia, interrompo brevemente os testes com os offloads desativados, registo a diferen\u00e7a e, em seguida, decido o que traz mais benef\u00edcios em funcionamento cont\u00ednuo.<\/p>\n\n<h2>Modelos de configura\u00e7\u00e3o por localiza\u00e7\u00e3o: ativar e desativar de forma seletiva<\/h2>\n\n<p>Deixo em aberto a possibilidade de, <strong>sendfile<\/strong> a ser substitu\u00eddo, dependendo do caminho ou do tipo de ficheiro. Para diret\u00f3rios est\u00e1ticos, mant\u00e9m-se ativado; para caminhos de streaming ou din\u00e2micos, desativo-o seletivamente quando os buffers ou filtros (por exemplo, compress\u00e3o) t\u00eam prioridade. Um pequeno exemplo:<\/p>\n\n<pre><code>server {\n    listen 80;\n    server_name static.example.com;\n    root \/var\/www\/static;\n\n # Recursos est\u00e1ticos: Zero-Copy\n    location \/assets\/ {\n sendfile on;\n tcp_nopush on;\n        tcp_nodelay on;\nexpires 7d;\n    }\n\n # Conte\u00fado din\u00e2mico ou streaming: flexibilidade em vez de Zero-Copy\n    location \/api\/ {\n sendfile off;\n proxy_pass http:\/\/app_upstream;\n    }\n}\n<\/code><\/pre>\n\n<p>Esta separa\u00e7\u00e3o impede que eu perca vantagens num dos lados, apenas porque outro caminho imp\u00f5e requisitos espec\u00edficos.<\/p>\n\n<h2>Intervalos, fatias e grandes cat\u00e1logos<\/h2>\n\n<p>No caso de objetos de grandes dimens\u00f5es, entra em jogo <strong>Gama<\/strong>- As solicita\u00e7\u00f5es tiram partido dos seus pontos fortes: o cliente carrega apenas as partes necess\u00e1rias e as liga\u00e7\u00f5es mant\u00eam-se est\u00e1veis. Em cat\u00e1logos de conte\u00fado com ficheiros muito grandes, gosto de segmentar as transfer\u00eancias de forma l\u00f3gica \u2013 a carga do servidor distribui-se de forma mais uniforme e os erros, como interrup\u00e7\u00f5es, custam menos tempo. Em cen\u00e1rios de cache, previno os \u201eThundering Herds\u201c ao armazenar as respostas de forma sensata, mas sem reter artificialmente pequenos blocos e dados residuais. A intera\u00e7\u00e3o com o tcp_nopush continua a ser fundamental: mantenho os segmentos iniciais grandes, mas n\u00e3o deixo que o final fique \u00e0 espera.<\/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\/nginx-performance-5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Estrat\u00e9gia de medi\u00e7\u00e3o e ensaio: comprovar os efeitos de forma fi\u00e1vel<\/h2>\n\n<p>Comprovo as otimiza\u00e7\u00f5es com testes reproduz\u00edveis. No lado do servidor, analiso os perfis da CPU, <em>$request_time<\/em>, <em>$bytes_enviados<\/em>, liga\u00e7\u00f5es ativas e mudan\u00e7as de contexto. Na rede, me\u00e7o tamanhos de segmentos, retransmiss\u00f5es e distribui\u00e7\u00e3o de RTT; correlaciono as capturas de pacotes com as estat\u00edsticas de socket para ter em conta os efeitos do offload. Do lado do cliente, comparo o TTFB, o First Contentful Paint e os tempos de download sob RTTs e larguras de banda realistas. Vario o MTU, as defini\u00e7\u00f5es de Keep-Alive e os tamanhos dos ficheiros, para n\u00e3o ver apenas curvas de cen\u00e1rio ideal. Por fim, com base em n\u00fameros concretos, decido se o `sendfile`\/`tcp_nopush` proporciona a estabilidade e a efici\u00eancia desejadas na respetiva carga de trabalho \u2013 e fa\u00e7o ajustes finos at\u00e9 que o fa\u00e7am.<\/p>\n\n<h2>Detalhes HTTP que fazem a diferen\u00e7a: Range e Streaming<\/h2>\n\n<p>Eu uso <strong>Gama<\/strong>-Solicita\u00e7\u00f5es no caso de ficheiros de grande dimens\u00e3o, para que os clientes apenas carreguem as partes necess\u00e1rias e as liga\u00e7\u00f5es se mantenham est\u00e1veis. Especialmente no caso de avan\u00e7os de v\u00eddeo e retomadas de atualiza\u00e7\u00f5es, um suporte adequado aos intervalos de bytes ajuda a distribuir a taxa de transfer\u00eancia de forma eficiente; a p\u00e1gina sobre este tema fornece informa\u00e7\u00f5es adicionais <a href=\"https:\/\/webhosting.de\/pt\/pedidos-de-gama-http-desempenho-do-alojamento-de-meios-de-comunicacao-e-de-descarregamento-byte\/\">Pedidos HTTP Range<\/a>. Para respostas cont\u00ednuas com corpo crescente, testo estrat\u00e9gias de streaming e garanto que os buffers n\u00e3o retenham os dados por demasiado tempo acidentalmente. Ao faz\u00ea-lo, respeito as caches e defino cabe\u00e7alhos adequados, para que os proxies e os navegadores funcionem corretamente. Tenho em conta a intera\u00e7\u00e3o com o tcp_nopush, uma vez que o tamanho dos pacotes e o momento da limpeza t\u00eam uma influ\u00eancia direta na rapidez percebida.<\/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\/nginx-performance-5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Com <strong>sendfile<\/strong> Encaminho os ficheiros de forma eficiente diretamente para o kernel e, com o tcp_nopush, fa\u00e7o com que os pacotes sejam preenchidos de forma adequada antes de sobrecarregarem a liga\u00e7\u00e3o. Ambas as diretivas complementam-se, enquanto o tcp_nodelay entrega o \u00faltimo byte restante sem atrasos. Verifico o efeito em tr\u00e1fego real, presto aten\u00e7\u00e3o ao caminho de armazenamento, ao MTU, ao Keep-Alive e \u00e0 compress\u00e3o, e fa\u00e7o medi\u00e7\u00f5es de forma consistente. Para cargas de trabalho do tipo WordPress e CDN, os benef\u00edcios tornam-se vis\u00edveis muito rapidamente, uma vez que muitas solicita\u00e7\u00f5es dizem respeito a recursos est\u00e1ticos. Quem utilizar estas configura\u00e7\u00f5es de forma seletiva obt\u00e9m maior d\u00e9bito por n\u00facleo, reduz a sobrecarga e cria reservas para picos de crescimento reais.<\/p>","protected":false},"excerpt":{"rendered":"<p>Guia pr\u00e1tico para a configura\u00e7\u00e3o do sendfile e do tcp_nopush do NGINX, com vista a obter o m\u00e1ximo desempenho na entrega de ficheiros est\u00e1ticos e downloads de grande dimens\u00e3o.<\/p>","protected":false},"author":1,"featured_media":20899,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20906","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":"143","_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":"nginx sendfile","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":"20899","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20906","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=20906"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20906\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20899"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20906"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20906"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20906"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}