{"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-rendimiento-configuracion","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/nginx-sendfile-tcp-nopush-ratgeber-performance-setup\/","title":{"rendered":"C\u00f3mo utilizar correctamente \u00absendfile\u00bb y \u00abtcp_nopush\u00bb en NGINX para obtener el m\u00e1ximo rendimiento"},"content":{"rendered":"<p>Con <strong>nginx sendfile<\/strong> y <strong>tcp_nopush<\/strong> Entrego archivos est\u00e1ticos mediante \u00abzero-copy\u00bb desde el sistema de archivos al socket, lo que reduce notablemente tanto la carga de la CPU como el n\u00famero de paquetes. Si se configuran correctamente, ambas directivas aumentan la eficiencia de la transmisi\u00f3n, reducen la sobrecarga y sientan las bases para una optimizaci\u00f3n adecuada de Nginx en lo que respecta a los recursos y las descargas.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<ul>\n  <li><strong>Copia cero<\/strong> mediante sendfile: menos copias, mayor rendimiento<\/li>\n  <li><strong>tcp_nopush<\/strong> almacena paquetes en b\u00fafer: tramas m\u00e1s grandes, menos sobrecarga<\/li>\n  <li><strong>Combinaci\u00f3n<\/strong> cuenta: sendfile + tcp_nopush + tcp_nodelay<\/li>\n  <li><strong>Casos pr\u00e1cticos<\/strong> Priorizar: recursos est\u00e1ticos, descargas de gran tama\u00f1o<\/li>\n  <li><strong>Pruebas<\/strong> En NFS\/SMB: medir el impacto; si es necesario, desactivar sendfile<\/li>\n<\/ul>\n\n<h2>Por qu\u00e9 \u00absendfile\u00bb mejora tanto el rendimiento de NGINX<\/h2>\n\n<p>Activo <strong>sendfile<\/strong>, ya que el n\u00facleo puede enviar archivos directamente a trav\u00e9s de la pila de red, sin necesidad de pasar por operaciones de copia adicionales en el espacio de usuario. Esta ruta de \u00abzero-copy\u00bb reduce los cambios de contexto y ahorra ciclos de CPU, especialmente cuando muchos clientes simult\u00e1neos acceden a contenidos est\u00e1ticos. Los archivos de gran tama\u00f1o, como im\u00e1genes, CSS, JavaScript o archivos comprimidos, se benefician de ello, ya que la transferencia de datos se realiza de forma m\u00e1s uniforme y con menos sobrecarga. Las cach\u00e9s del sistema tambi\u00e9n funcionan de manera m\u00e1s eficiente, ya que se producen menos movimientos de memoria y el n\u00facleo controla la ruta de los datos. La mejora se aprecia con mayor claridad en los sistemas de archivos locales, por lo que realizo las mediciones all\u00ed primero, antes de aplicarlas a configuraciones m\u00e1s 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>Qu\u00e9 hace exactamente tcp_nopush y cu\u00e1ndo destaca<\/h2>\n\n<p>Con <strong>tcp_nopush<\/strong> Pido al sistema que env\u00ede los paquetes TCP solo cuando est\u00e9n completamente llenos, en lugar de enviar segmentos peque\u00f1os antes de tiempo. En Linux, esto se corresponde con TCP_CORK; en FreeBSD, con TCP_NOPUSH; y, en ambos casos, el n\u00famero de paquetes se reduce de forma apreciable. Esta directiva no reduce la latencia al m\u00ednimo, sino que busca una mejor relaci\u00f3n entre los datos \u00fatiles y la sobrecarga. Utilizo tcp_nopush espec\u00edficamente con archivos est\u00e1ticos, ya que es ah\u00ed donde los flujos de datos contiguos aportan mayores ganancias de eficiencia. Sin sendfile, tcp_nopush no surte efecto, por lo que siempre integro ambas configuraciones conjuntamente.<\/p>\n\n<h2>sendfile y tcp_nopush como d\u00fao: as\u00ed es como establezco las bases<\/h2>\n\n<p>La combinaci\u00f3n de <strong>sendfile<\/strong> y tcp_nopush reduce las copias y agrupa los paquetes, lo que permite que un servidor por n\u00facleo de CPU pueda gestionar un n\u00famero significativamente mayor de transferencias en paralelo. Yo configuro ambas opciones en el nivel de contexto http y, a menudo, a\u00f1ado tcp_nodelay para que el \u00faltimo resto de un flujo se transmita sin tiempo de espera. Sigue siendo importante realizar pruebas con tr\u00e1fico real, ya que el tama\u00f1o de los paquetes, la MTU y los clientes var\u00edan, y el mejor equilibrio puede variar ligeramente en funci\u00f3n de la carga de trabajo. Para los directorios est\u00e1ticos, suele bastar con la activaci\u00f3n global, mientras que en el caso de las rutas de respuesta din\u00e1micas presto atenci\u00f3n al efecto que tiene. Esta combinaci\u00f3n proporciona una base s\u00f3lida para otras medidas de optimizaci\u00f3n de nginx que se aplicar\u00e1n posteriormente.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>directiva<\/th>\n      <th>Prop\u00f3sito<\/th>\n      <th>Efectos t\u00edpicos<\/th>\n      <th>Dependencia<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>sendfile activado<\/strong><\/td>\n      <td>Copia sin transferencia de archivos al socket<\/td>\n      <td>Menor carga de la CPU, mayor rendimiento<\/td>\n      <td>Un sistema de archivos local es la opci\u00f3n ideal<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>tcp_nopush activado<\/strong><\/td>\n      <td>Llenar los paquetes, reducir los gastos generales<\/td>\n      <td>Menos segmentos por archivo<\/td>\n      <td>Solo funciona con sendfile<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>tcp_nodelay on<\/strong><\/td>\n      <td>Enviar los \u00faltimos bytes sin esperar<\/td>\n      <td>Conclusi\u00f3n r\u00e1pida de la transferencia<\/td>\n      <td>Se ha a\u00f1adido 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>As\u00ed es como interact\u00faan tcp_nodelay y tcp_nopush<\/h2>\n\n<p>Activo <strong>tcp_nopush<\/strong>, para enviar el inicio de una transferencia en paquetes m\u00e1s grandes, y habilito al mismo tiempo tcp_nodelay para que la finalizaci\u00f3n no se atasque. Ambos ajustes afectan a diferentes fases del flujo y no interfieren entre s\u00ed cuando NGINX entrega archivos mediante sendfile. Especialmente cuando hay muchos archivos peque\u00f1os, tcp_nodelay evita que el cliente espere innecesariamente debido a peque\u00f1os datos restantes. Primero pruebo la combinaci\u00f3n en el entorno de staging, observo los RTT y los tama\u00f1os de los segmentos, y los comparo con las m\u00e9tricas en producci\u00f3n. De esta forma, me aseguro de que la transmisi\u00f3n sea eficiente al principio y r\u00e1pida al final.<\/p>\n\n<pre><code>http {\n    sendfile on;\n    tcp_nopush on;\n    tcp_nodelay on;\n}\n<\/code><\/pre>\n\n<h2>Situaciones t\u00edpicas de aplicaci\u00f3n: en las que las directivas tienen un gran impacto<\/h2>\n\n<p>Para los grandes <strong>Descargas<\/strong> Al igual que con los v\u00eddeos, los archivos o las im\u00e1genes ISO, la ruta \u00abzero-copy\u00bb del n\u00facleo reduce considerablemente el tiempo de CPU por transferencia. En configuraciones similares a las de una CDN, con numerosos archivos CSS, JS y de fuentes, tcp_nopush ahorra segmentos y, de este modo, aumenta el ancho de banda \u00fatil por socket. En las p\u00e1ginas de WordPress con un buen almacenamiento en cach\u00e9, la mayor\u00eda de las solicitudes se dirigen a recursos est\u00e1ticos, por lo que el efecto se nota all\u00ed muy r\u00e1pidamente. Tambi\u00e9n se benefician los artefactos de compilaci\u00f3n, las im\u00e1genes de contenedores o los instaladores, siempre que se encuentren localmente y no se accedan a trav\u00e9s de un sistema de archivos de red inestable. Quien prevea picos de carga, conseguir\u00e1 con este d\u00fao sacar mucho m\u00e1s partido al hardware disponible.<\/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>Ejemplo pr\u00e1ctico: NGINX para WordPress con almacenamiento en cach\u00e9 y recursos<\/h2>\n\n<p>En las configuraciones de WordPress, utilizo <strong>sendfile<\/strong>, tcp_nopush y tcp_nodelay a nivel global, sirvo los recursos est\u00e1ticos directamente y mantengo PHP-FPM bien separado para las rutas din\u00e1micas. A\u00f1ado encabezados de cach\u00e9 adecuados para im\u00e1genes, CSS y JavaScript, de modo que los navegadores realicen menos idas y venidas. Cuando sirvo respuestas de tipo streaming, tengo en cuenta la interacci\u00f3n con el almacenamiento en b\u00fafer y compruebo c\u00f3mo afectan los tama\u00f1os de los fragmentos a la latencia y al rendimiento; para ello, resulta \u00fatil la descripci\u00f3n general sobre <a href=\"https:\/\/webhosting.de\/es\/http-response-streaming-hosting-performance-chunks\/\">Respuesta en secuencias<\/a>. Para los contenidos de texto, aplico compresi\u00f3n sin comprimir innecesariamente los archivos binarios. De este modo, el flujo de solicitudes se mantiene estable, la CPU no se sobrecarga y el tiempo hasta el primer byte es breve.<\/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>Cu\u00e1ndo desactivo \u00absendfile\u00bb de forma deliberada<\/h2>\n\n<p>Cambio <strong>sendfile<\/strong> cuando los archivos se encuentran en NFS, SMB o sistemas de archivos distribuidos, que en mi prueba ofrecen un rendimiento inferior. Algunos controladores o latencias en la ruta de almacenamiento anulan la ventaja de \u00abzero-copy\u00bb, por lo que las mediciones son determinantes. Ante peculiaridades espor\u00e1dicas de la red, primero desactivo tcp_nopush para delimitar los efectos, antes de cuestionar el propio sendfile. Tambi\u00e9n pueden ser motivos para cambiar temporalmente a la ruta cl\u00e1sica de lectura y escritura algunos errores inusuales del n\u00facleo o pilas m\u00e1s antiguas. Lo importante es implementar los cambios de forma gradual y respaldarlos con 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>Fuentes de error que tengo en cuenta<\/h2>\n\n<p>Primero compruebo si <strong>tcp_nopush<\/strong> est\u00e1 activada por error, mientras que sendfile permanece desactivada, ya que en ese caso la configuraci\u00f3n no surte efecto. En el caso de las rutas din\u00e1micas, compruebo si el almacenamiento en b\u00fafer adicional aumenta la latencia y sopeso las ventajas frente al tiempo de respuesta. En redes de alta latencia, mido si los paquetes m\u00e1s grandes realmente ayudan o si debo ajustar el tama\u00f1o de los segmentos y el \u00abkeep-alive\u00bb. La configuraci\u00f3n de la MTU y las funciones de descarga de la tarjeta de red tambi\u00e9n pueden influir notablemente en el resultado. Los registros limpios, las muestras pcap y las m\u00e9tricas del sistema correlacionadas me permiten identificar r\u00e1pidamente d\u00f3nde debo realizar ajustes.<\/p>\n\n<h2>Un enfoque integral del rendimiento de NGINX: otros ajustes posibles<\/h2>\n\n<p>Adem\u00e1s de <strong>sendfile<\/strong> Merece la pena establecer el n\u00famero adecuado de worker_processes y worker_connections para no limitar artificialmente los sockets. En Linux utilizo epoll y me aseguro de que haya suficientes descriptores de archivo para que los picos de carga no provoquen cuellos de botella. Para los contenidos de texto, activo gzip o Brotli y compruebo si el nivel de compresi\u00f3n supone una carga razonable para la CPU. A nivel de transporte, mantengo las conexiones abiertas durante m\u00e1s tiempo y optimizo el \u00abkeep-alive\u00bb, tal y como indica la gu\u00eda <a href=\"https:\/\/webhosting.de\/es\/http-mantener-vivo-ajuste-optimizacion-del-rendimiento-del-servidor-flujo\/\">Ajuste de Keep Alive<\/a> ofrece pautas pr\u00e1cticas. TLS, la reutilizaci\u00f3n de sesiones y HTTP\/2 o HTTP\/3 completan la configuraci\u00f3n y permiten un alto grado de paralelismo con una latencia 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>Limitaciones y casos especiales: TLS, HTTP\/2\/3 y el uso de proxies<\/h2>\n\n<p>Tengo en cuenta que <strong>sendfile<\/strong> T\u00e9cnicamente, solo es aplicable a rutas de archivos sin cifrar o a funciones espec\u00edficas del n\u00facleo. En el TLS cl\u00e1sico, NGINX cifra los bytes en el espacio de usuario, por lo que se pierde la ventaja de \u00abzero-copy\u00bb; los n\u00facleos modernos pueden trasladar parcialmente el cifrado al n\u00facleo, lo que recupera ese efecto, pero no est\u00e1 disponible en todas las configuraciones. En <strong>HTTP\/2<\/strong> Los datos se encuentran en tramas, varias respuestas comparten una conexi\u00f3n TCP y NGINX reagrupa activamente los bytes; en este caso, sendfile tiene menos relevancia. <strong>HTTP\/3<\/strong> se basa en UDP\/QUIC y sigue otras reglas, por lo que consigo una mayor eficiencia m\u00e1s bien mediante b\u00faferes, control de congesti\u00f3n y un tama\u00f1o de fragmentos adecuado. Como <strong>Proxy inverso<\/strong> sendfile solo se aplica cuando realmente sirvo archivos desde el sistema de archivos local; respuestas de <em>proxy_pass<\/em> o <em>fastcgi_pass<\/em> De todos modos, pasan por el espacio de usuario. Por eso separo estrictamente los recursos de la ruta din\u00e1mica, para aprovechar al m\u00e1ximo el m\u00e9todo \u00abzero-copy\u00bb.<\/p>\n\n<h2>Entender bien la compresi\u00f3n: gzip\/Brotli frente a gzip_static<\/h2>\n\n<p>Cada vez que NGINX comprime contenidos sobre la marcha, tiene que leer el archivo, procesarlo y escribir el resultado, con lo que se pierde <strong>sendfile<\/strong> su ventaja. Por eso, para los recursos est\u00e1ticos, utilizo, siempre que sea posible, <em>precomprimidos<\/em> Archivos (por ejemplo, .gz o .br) y los env\u00edo directamente. De este modo se mantiene la ruta \u00abzero-copy\u00bb, ya que NGINX puede transferir el archivo precomprimido como cualquier otro recurso. De este modo, para contenidos con gran cantidad de texto que rara vez se modifican, consigo un ahorro de CPU y un rendimiento estable sin perder tiempo de transmisi\u00f3n. En el caso de los archivos binarios y los formatos ya comprimidos, me ahorro cualquier compresi\u00f3n en tiempo de ejecuci\u00f3n; aqu\u00ed lo que cuenta es el rendimiento puro de E\/S, y \u00absendfile\u00bb junto con \u00abtcp_nopush\u00bb sacan partido a sus puntos fuertes.<\/p>\n\n<h2>AIO, directio y Page Cache: patrones para archivos peque\u00f1os y grandes<\/h2>\n\n<p>Combino <strong>sendfile<\/strong> con E\/S as\u00edncrona y acceso directo al disco, para obtener el mejor rendimiento en funci\u00f3n del tama\u00f1o del archivo. Los archivos peque\u00f1os y medianos se benefician de la cach\u00e9 de p\u00e1ginas del n\u00facleo y permanecen en la ruta de `sendfile`. Por el contrario, los archivos muy grandes pueden desplazar la cach\u00e9; en ese caso, los leo espec\u00edficamente con <em>directio<\/em> fuera de la cach\u00e9 y utilizo hilos AIO. De este modo, alivio la carga de la memoria y mantengo baja la latencia para otras solicitudes. Un patr\u00f3n t\u00edpico es el siguiente:<\/p>\n\n<pre><code>http {\n    # Ruta est\u00e1ndar: copia cero desde la cach\u00e9 de p\u00e1ginas\n    sendfile on;\n    tcp_nopush on;\n    tcp_nodelay on;\n\n # Archivos grandes: sin pasar por la cach\u00e9 y lectura as\u00edncrona\n    aio threads;\n    directio 4m; # solo se aplica a archivos &gt;= 4 MiB\n    output_buffers 1 512k;    #: b\u00faferes para rutas directio\n    sendfile_max_chunk 1m;    #: equidad bajo carga elevada\n}\n<\/code><\/pre>\n\n<p>Con esta escalabilidad, los activos peque\u00f1os siguen siendo extremadamente eficientes, mientras que las transferencias muy grandes no saturan la memoria RAM. Importante: directio desactiva la ruta sendfile para los archivos afectados, tal y como yo pretendo para el caso de uso de archivos de gran tama\u00f1o.<\/p>\n\n<h2>Equidad y control del flujo bajo carga<\/h2>\n\n<p>En momentos de alta carga, quiero evitar que un solo flujo acapare la CPU o el socket. Utilizo <strong>sendfile_max_chunk<\/strong>, para que NGINX devuelva el kernel tras una cantidad definida de bytes y deje espacio para otras conexiones. Para el control del ancho de banda, son \u00fatiles <em>limit_rate<\/em> y <em>limit_rate_after<\/em>, por ejemplo, para limitar las descargas masivas, mientras que los elementos de la interfaz de usuario siguen funcionando con fluidez. Con <em>postpone_output<\/em> Controlo a partir de qu\u00e9 tama\u00f1o de respuesta NGINX comienza a enviar datos; en combinaci\u00f3n con tcp_nopush, me aseguro as\u00ed de que los paquetes se fragmenten correctamente. Adem\u00e1s, presto atenci\u00f3n a <em>lingering_close<\/em>, para que los paquetes restantes se transmitan correctamente y el socket no se cierre de forma brusca.<\/p>\n\n<h2>Sistemas de archivos, lectura anticipada y rutas de almacenamiento<\/h2>\n\n<p>Porque <strong>sendfile<\/strong> Cuando se utilizan las cach\u00e9s de p\u00e1gina, el sistema de archivos subyacente desempe\u00f1a un papel fundamental. Compruebo los valores de lectura anticipada y los mantengo de tal forma que las operaciones de lectura secuencial de archivos grandes no se vean interrumpidas, sin que ello suponga desplazar activos m\u00e1s peque\u00f1os. En <em>ext4<\/em> o <em>xfs<\/em> Observo lo bien que se adaptan el prefetching y el programador de E\/S a mi patr\u00f3n de rendimiento. En los sistemas de archivos de red (NFS\/SMB), realizo pruebas exhaustivas de rsize\/wsize, el almacenamiento en cach\u00e9 y las latencias, ya que incluso peque\u00f1as desviaciones neutralizan la ventaja del \u00abzero-copy\u00bb. Mi regla sigue siendo la misma: primero aprovechar al m\u00e1ximo las rutas locales, luego ajustar con cuidado las pilas externas y dar siempre prioridad a los datos de medici\u00f3n frente a la intuici\u00f3n.<\/p>\n\n<h2>Ajustar de forma pragm\u00e1tica la pila de red y la descarga de la tarjeta de red<\/h2>\n\n<p>Para un gran n\u00famero de conexiones, conf\u00edo en el ajuste autom\u00e1tico de los b\u00faferes de las pilas modernas, aunque, si es necesario, ajusto los b\u00faferes de env\u00edo y recepci\u00f3n. Las descargas de la tarjeta de red, como TSO, GSO y GRO, reducen notablemente la carga de la CPU; sin embargo, en las mediciones procedo con cautela, ya que las capturas de paquetes pueden verse distorsionadas por la descarga (aparentemente, pocos segmentos muy grandes). Por eso, correlaciono <em>pcap<\/em>\u2011Traces con m\u00e9tricas de NGINX y del n\u00facleo, para distinguir los tama\u00f1os reales de los datos transmitidos de los artefactos de descarga. En caso de picos de latencia, interrumpo brevemente las pruebas desactivando las descargas, documento la diferencia y luego decido qu\u00e9 opci\u00f3n resulta m\u00e1s beneficiosa en el funcionamiento continuo.<\/p>\n\n<h2>Plantillas de configuraci\u00f3n por ubicaci\u00f3n: activar y desactivar de forma selectiva<\/h2>\n\n<p>Me reservo la posibilidad de, <strong>sendfile<\/strong> sobrescribir en funci\u00f3n de la ruta o el tipo de archivo. Para los directorios est\u00e1ticos, se mantiene activado; para las rutas de streaming o din\u00e1micas, lo desactivo de forma selectiva cuando los b\u00faferes o los filtros (por ejemplo, la compresi\u00f3n) tienen prioridad. Un breve ejemplo:<\/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;\n expires 7d;\n    }\n\n # Contenido din\u00e1mico o streaming: flexibilidad antes que \u00abZero-Copy\u00bb\n    location \/api\/ {\n sendfile off;\n proxy_pass http:\/\/app_upstream;\n    }\n}\n<\/code><\/pre>\n\n<p>Esta separaci\u00f3n evita que pierda ventajas por un lado, simplemente porque otra v\u00eda plantea requisitos espec\u00edficos.<\/p>\n\n<h2>Rango, segmentos y cat\u00e1logos extensos<\/h2>\n\n<p>En el caso de inmuebles de gran tama\u00f1o, hay que tener en cuenta <strong>alcance<\/strong>-Las solicitudes sacan partido de sus puntos fuertes: el cliente solo carga las partes necesarias y las conexiones se mantienen estables. En cat\u00e1logos de contenido con archivos muy grandes, me gusta segmentar las transferencias de forma l\u00f3gica: la carga del servidor se distribuye de manera m\u00e1s uniforme y los errores, como las interrupciones, suponen una p\u00e9rdida de tiempo menor. En escenarios de almacenamiento en cach\u00e9, evito los \u201ethundering herds\u201c almacenando en b\u00fafer las respuestas de forma sensata, pero sin retener artificialmente peque\u00f1os fragmentos ni datos residuales. La interacci\u00f3n con tcp_nopush sigue siendo fundamental: mantengo grandes los segmentos iniciales, pero no dejo que el final tenga que esperar.<\/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>Estrategia de medici\u00f3n y ensayo: demostrar los efectos de forma fiable<\/h2>\n\n<p>Corroboro las optimizaciones con pruebas reproducibles. En el lado del servidor, analizo los perfiles de la CPU, <em>1TP4Hora_petici\u00f3n<\/em>, <em>1 TP4 Tbytes_enviados<\/em>, conexiones activas y cambios de contexto. En la red mido los tama\u00f1os de los segmentos, las retransmisiones y la distribuci\u00f3n del RTT; correlaciono las capturas de paquetes con las estad\u00edsticas de sockets para tener en cuenta los efectos de la descarga. Por parte del cliente, comparo el TTFB, el First Contentful Paint y los tiempos de descarga con RTT y anchos de banda realistas. Vario el MTU, la configuraci\u00f3n de Keep-Alive y los tama\u00f1os de los archivos para no limitarme a observar solo las curvas del mejor caso. Al final, bas\u00e1ndome en cifras concretas, decido si sendfile\/tcp_nopush proporcionan la estabilidad y la eficiencia deseadas en la carga de trabajo correspondiente, y realizo ajustes precisos hasta que lo consigan.<\/p>\n\n<h2>Detalles de HTTP que marcan la diferencia: \u00abRange\u00bb y \u00abStreaming\u00bb<\/h2>\n\n<p>Utilizo <strong>alcance<\/strong>-Solicitudes para archivos de gran tama\u00f1o, de modo que los clientes solo recarguen las partes necesarias y las conexiones se mantengan estables. Especialmente en el caso del avance de v\u00eddeos y la reanudaci\u00f3n de actualizaciones, un buen soporte de los rangos de bytes ayuda a distribuir el rendimiento de forma adecuada; en la p\u00e1gina sobre <a href=\"https:\/\/webhosting.de\/es\/http-range-requests-media-and-download-hosting-performance-byte\/\">Solicitudes HTTP de rango<\/a>. Para respuestas continuas con un cuerpo cada vez mayor, pruebo estrategias de streaming y me aseguro de que los b\u00faferes no retengan los datos durante demasiado tiempo de forma involuntaria. Para ello, tengo en cuenta las cach\u00e9s y establezco encabezados adecuados para que los proxies y los navegadores act\u00faen correctamente. Tengo en cuenta la interacci\u00f3n con tcp_nopush, ya que el tama\u00f1o de los paquetes y el momento del vaciado influyen directamente en la percepci\u00f3n de la velocidad.<\/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>Con <strong>sendfile<\/strong> Transmito los archivos de forma eficiente directamente al n\u00facleo y, con tcp_nopush, hago que los paquetes se llenen adecuadamente antes de que sobrecarguen la l\u00ednea. Ambas directivas se complementan, mientras que tcp_nodelay env\u00eda el \u00faltimo byte restante sin demora. Compruebo el efecto con tr\u00e1fico real, presto atenci\u00f3n a la ruta de almacenamiento, la MTU, el Keep-Alive y la compresi\u00f3n, y realizo mediciones de forma sistem\u00e1tica. En cargas de trabajo de tipo WordPress y CDN, los beneficios se aprecian con especial rapidez, ya que muchas solicitudes se refieren a recursos est\u00e1ticos. Quien utilice estos ajustes de forma espec\u00edfica obtendr\u00e1 un mayor rendimiento por n\u00facleo, reducir\u00e1 la sobrecarga y crear\u00e1 reservas para los picos de crecimiento reales.<\/p>","protected":false},"excerpt":{"rendered":"<p>Gu\u00eda pr\u00e1ctica sobre la configuraci\u00f3n de \u00absendfile\u00bb y \u00abtcp_nopush\u00bb en NGINX para obtener el m\u00e1ximo rendimiento en la entrega de archivos est\u00e1ticos y descargas de gran tama\u00f1o.<\/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\/es\/wp-json\/wp\/v2\/posts\/20906","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=20906"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20906\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20899"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20906"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20906"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20906"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}