{"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":"reuseport-linux-servidor-web-optimizacion-del-rendimiento-nucleo","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/so-reuseport-linux-webserver-performance-optimierung-core\/","title":{"rendered":"SO_REUSEPORT en Linux: mayor rendimiento para los servidores web"},"content":{"rendered":"<p>Voy a mostrar c\u00f3mo SO_REUSEPORT acelera los servidores web de Linux con muchas conexiones simult\u00e1neas y elimina los cuellos de botella en el <strong>Acepte<\/strong> eliminado. Para ello, apuesto por m\u00e9todos pr\u00e1cticos y claros, para que puedas sacar m\u00e1s partido a los sistemas multin\u00facleo <strong>Actuaci\u00f3n<\/strong> lo sacas.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<ul>\n  <li><strong>Cuota de admisi\u00f3n<\/strong> Evitar y reducir la latencia<\/li>\n  <li><strong>Multin\u00facleo<\/strong> Aprovechamiento eficiente de la capacidad mediante la distribuci\u00f3n del n\u00facleo<\/li>\n  <li><strong>Cocina atronadora<\/strong> reducir considerablemente<\/li>\n  <li><strong>Arquitectura<\/strong> Simplificar sin un dispatcher de Userland<\/li>\n  <li><strong>Nginx<\/strong> y utilizar directamente otros 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>Qu\u00e9 resuelve SO_REUSEPORT desde el punto de vista t\u00e9cnico<\/h2>\n\n<p>SO_REUSEPORT asigna a cada worker su propio socket de escucha, por lo que puedo utilizar el cl\u00e1sico <strong>cuello de botella<\/strong> en el Accept central. Antes, todo depend\u00eda de un \u00fanico socket, lo que provocaba que los subprocesos compitieran entre s\u00ed y aumentaran los tiempos de espera. Hoy en d\u00eda, el n\u00facleo distribuye las nuevas conexiones directamente entre varios sockets, lo que reduce la <strong>Latencia<\/strong> lo reduce notablemente. De este modo, elimino la necesidad de procesos de dispatcher independientes y evito los cambios de contexto. Bajo una carga elevada, los tiempos de respuesta se mantienen m\u00e1s constantes, ya que ning\u00fan listener concreto ralentiza el sistema.<\/p>\n\n<h2>SO_REUSEPORT frente a SO_REUSEADDR: una breve comparaci\u00f3n<\/h2>\n\n<p>SO_REUSEADDR me ayuda a reiniciar r\u00e1pidamente, ya que puedo utilizar los puertos a pesar de <strong>TIME_WAIT<\/strong> puede volver a enlazarse. SO_REUSEPORT resuelve otra cosa: varios listeners simult\u00e1neos en la misma combinaci\u00f3n de IP y puerto. Solo si establezco SO_REUSEPORT antes de la llamada a bind(), el n\u00facleo permite el funcionamiento paralelo <strong>Bind<\/strong>-Operaci\u00f3n. Es importante tener en cuenta el orden: si un puerto est\u00e1 ocupado sin esta opci\u00f3n, no se podr\u00e1n a\u00f1adir m\u00e1s sockets. Por lo tanto, para los trabajadores en paralelo, SO_REUSEPORT es una opci\u00f3n clave.<\/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>Funcionamiento en el n\u00facleo: grupos de Reuseport y hash<\/h2>\n\n<p>Todos los sockets con una combinaci\u00f3n id\u00e9ntica de IP y puerto y con la opci\u00f3n SO_REUSEPORT activada se agrupan en un <strong>Grupo<\/strong>. El n\u00facleo calcula, por cada nueva conexi\u00f3n, un hash a partir de los par\u00e1metros de origen y destino. Sobre esta base, asigna la conexi\u00f3n a un listener adecuado y, de este modo, la distribuye de forma relativamente equitativa. Me beneficio de una mejor localidade de la cach\u00e9, ya que cada CPU procesa \u201esus\u201c conexiones con mayor frecuencia. Para casos especiales, BPF puede <strong>Selecci\u00f3n<\/strong> seguir adapt\u00e1ndolo, por ejemplo, para aplicar estrategias propias.<\/p>\n\n<h2>Pr\u00e1ctica: Configurar Nginx correctamente<\/h2>\n\n<p>En Nginx, activo \u00abreuseport\u00bb con la directiva \u00ablisten\u00bb y utilizo varios <strong>Trabajador<\/strong>-Procesos. Un ejemplo: establecer \u201eworker_processes\u201c en el n\u00famero de n\u00facleos y, en el bloque \u00abserver\u00bb, \u00ablisten 80 reuseport;\u00bb. De este modo, cada proceso de trabajo dispone de su propio listener y el n\u00facleo distribuye autom\u00e1ticamente las nuevas conexiones. Para obtener m\u00e1s detalles sobre el n\u00famero \u00f3ptimo de procesos de trabajo, remito a la <a href=\"https:\/\/webhosting.de\/es\/configuracion-optima-de-los-procesos-de-trabajo-de-nginx-para-mejorar-el-rendimiento\/\">Procesos de trabajo de Nginx<\/a>. De este modo consigo mayores tasas de solicitudes y una carga de trabajo uniforme en los n\u00facleos.<\/p>\n\n<h2>Aprovechar de forma eficiente las CPU multin\u00facleo<\/h2>\n\n<p>Con varios trabajadores y SO_REUSEPORT, utilizo <strong>Multin\u00facleo<\/strong>-Sistemas m\u00e1s uniformes. Asigno los trabajadores a los n\u00facleos mediante la afinidad de la CPU para reducir el \u201ecache-hopping\u201c. El RSS\/RPS de la tarjeta de red ayuda a distribuir adecuadamente los paquetes entrantes entre las colas. De este modo, las conexiones suelen acabar en los n\u00facleos \u00abadecuados\u00bb, lo que mejora la <strong>Rendimiento<\/strong>-Aumenta la tasa. El efecto se nota especialmente cuando hay muchas conexiones breves y intercambios de datos 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>Supervisi\u00f3n, reinicios progresivos y dificultades<\/h2>\n\n<p>Planifico los reinicios progresivos con cautela, ya que cerrar un socket de escucha puede provocar la p\u00e9rdida de <strong>atraso<\/strong>-entradas. Antes de cerrar los workers, dejo que sus colas se vac\u00eden por completo y solo entonces los retiro del servicio. Para los registros, elijo archivos separados para cada worker, de modo que pueda hacer un seguimiento de la distribuci\u00f3n m\u00e1s adelante. Las herramientas de monitorizaci\u00f3n deben tener en cuenta varios procesos; de lo contrario, las m\u00e9tricas pueden resultar enga\u00f1osas. En cuanto a las direcciones IP, presto atenci\u00f3n a la coherencia, ya que, de lo contrario, 0.0.0.0 y las direcciones IP espec\u00edficas <strong>Conflictos<\/strong> pueden generar.<\/p>\n\n<h2>SO_REUSEPORT m\u00e1s all\u00e1 de HTTP<\/h2>\n\n<p>Este principio tambi\u00e9n me ayuda a <strong>UDP<\/strong>-servicios como el DNS, el streaming o los servidores de videojuegos. De este modo, muchos paquetes nuevos por segundo se distribuyen entre varios listeners sin que necesite un equilibrador de carga en el espacio de usuario. Los proxies TCP, las puertas de enlace y las plataformas de IoT tambi\u00e9n se benefician de ello. Es importante contar con el n\u00famero adecuado de workers para que el hardware y el software funcionen al un\u00edsono. Combino esta configuraci\u00f3n con claras <strong>L\u00edmites<\/strong> para los descriptores de archivo y los valores de tiempo de espera correctos.<\/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>Ajuste de la pila de red: IRQ, descargas, b\u00faferes<\/h2>\n\n<p>Estoy comprobando la distribuci\u00f3n de IRQ de la tarjeta de red para que las colas se asignen a los <strong>CPU<\/strong>-n\u00facleos. Cuando me parece oportuno, utilizo GRO\/LRO y descargas, pero siempre compruebo la latencia. Configuro los b\u00faferes de socket de forma deliberada, ya que unos valores demasiado bajos ralentizan el sistema en los picos de carga y unos valores demasiado altos desperdician memoria; m\u00e1s informaci\u00f3n al respecto en <a href=\"https:\/\/webhosting.de\/es\/servidor-socket-buffers-hosting-tuning-bufferopti\/\">Memoria intermedia<\/a>. Tambi\u00e9n compruebo que los par\u00e1metros de sysctl, como somaxconn y net.core.somaxconn, se ajusten al perfil de carga de trabajo. Mido el efecto de cada cambio de forma aislada para obtener resultados reales <strong>Ganancias<\/strong> para ver.<\/p>\n\n<h2>Comparativa de las configuraciones m\u00e1s habituales de servidores web<\/h2>\n\n<p>La siguiente tabla muestra las caracter\u00edsticas t\u00edpicas de distintos modelos de listener y me ayuda a <strong>Elecci\u00f3n<\/strong> del dise\u00f1o. Me centro en la ruta de aceptaci\u00f3n, la latencia bajo carga, las caracter\u00edsticas de escalabilidad, el esfuerzo de arquitectura y la utilizaci\u00f3n de la CPU. As\u00ed puedo identificar r\u00e1pidamente qu\u00e9 configuraci\u00f3n se adapta a mi perfil de tr\u00e1fico. Distingo la teor\u00eda de la pr\u00e1ctica comprobando despu\u00e9s las m\u00e9tricas reales. La <strong>Matriz<\/strong> Sirve como punto de partida para realizar pruebas espec\u00edficas.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Configurar<\/th>\n      <th>Ruta Accept<\/th>\n      <th>Latencia bajo carga<\/th>\n      <th>Escala<\/th>\n      <th>Gastos de arquitectura<\/th>\n      <th>Utilizaci\u00f3n de la CPU<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Un listener sin SO_REUSEPORT<\/td>\n      <td>A <strong>Z\u00f3calo<\/strong><\/td>\n      <td>sale temprano<\/td>\n      <td>limitado<\/td>\n      <td>bajo<\/td>\n      <td>desigual<\/td>\n    <\/tr>\n    <tr>\n      <td>Varios trabajadores con SO_REUSEPORT<\/td>\n      <td>N\u00facleo-<strong>Distribuci\u00f3n<\/strong><\/td>\n      <td>m\u00e1s constante<\/td>\n      <td>alta<\/td>\n      <td>bajo<\/td>\n      <td>m\u00e1s uniforme<\/td>\n    <\/tr>\n    <tr>\n      <td>Distribuidor de Userland<\/td>\n      <td>recepci\u00f3n centralizada<\/td>\n      <td>medio<\/td>\n      <td>medio<\/td>\n      <td>alta<\/td>\n      <td>cambiante<\/td>\n    <\/tr>\n    <tr>\n      <td>SO_REUSEPORT + l\u00f3gica BPF<\/td>\n      <td>selecci\u00f3n personalizada<\/td>\n      <td>muy constante<\/td>\n      <td>Muy alta<\/td>\n      <td>medio<\/td>\n      <td>muy 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>Planificar bien las pruebas de rendimiento<\/h2>\n\n<p>Realizo pruebas con y sin SO_REUSEPORT para obtener resultados reales <strong>Diferencias<\/strong> que se pueden observar. Los indicadores relevantes son las solicitudes por segundo, las latencias p95\/p99 y la utilizaci\u00f3n de la CPU por n\u00facleo. Vario el n\u00famero de trabajadores y compruebo el punto \u00f3ptimo entre los cambios de contexto y la carga de trabajo. Selecciono datos de prueba que se ajusten a la realidad, incluyendo TLS, Keep-Alive y contenidos tanto est\u00e1ticos como din\u00e1micos. Registro los resultados de forma reproducible para poder, m\u00e1s adelante, <strong>Cambios<\/strong> se puede comparar.<\/p>\n\n<h2>Apache: c\u00f3mo sacar el m\u00e1ximo partido al MPM Event<\/h2>\n\n<p>Apache tambi\u00e9n se beneficia cuando desacoplo la ruta \u00abAccept\u00bb y el <strong>Evento<\/strong>-Utilizar MPM correctamente. La elecci\u00f3n entre Event-MPM y Worker-MPM depende del perfil de conexi\u00f3n y de los recursos. Tengo en cuenta el keep-alive, los grupos de subprocesos y los l\u00edmites para los clientes. Para hacerme una idea general, me sirve de ayuda este resumen: <a href=\"https:\/\/webhosting.de\/es\/mpm-event-de-apache-frente-a-mpm-worker-ajuste-y-optimizacion-del-servidor-web\/\">MPM de eventos frente a MPM de trabajadores<\/a>. En combinaci\u00f3n con SO_REUSEPORT, trabajo de forma espec\u00edfica para lograr una distribuci\u00f3n uniforme <strong>Carga<\/strong> por proceso.<\/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>L\u00edmites y matices de la distribuci\u00f3n<\/h2>\n<p>SO_REUSEPORT distribuye las conexiones entrantes mediante un hash de forma relativamente equitativa, aunque no perfectamente uniforme. Los picos de carga pueden afectar m\u00e1s a determinados trabajadores de forma temporal si los par\u00e1metros de origen y destino provocan una distribuci\u00f3n desfavorable. Por ello, realizo un seguimiento mediante las m\u00e9tricas de los trabajadores (conexiones aceptadas, conexiones activas, CPU) y ajusto el n\u00famero de trabajadores, las afinidades y las colas RSS. Las conexiones Keep-Alive permanecen en el listener original, lo que aporta la localidad de cach\u00e9 deseada, pero tambi\u00e9n puede dar lugar a patrones de carga \u201esticky\u201c. Para solicitudes muy heterog\u00e9neas (con una carga mixta de CPU y E\/S), preveo b\u00faferes para amortiguar picos breves.<\/p>\n\n<h2>La ruta \u00abAccept\u00bb en detalle: Backlog, somaxconn y colas SYN<\/h2>\n<p>Distingo entre la cola de lista (SYN-Backlog) y la cola de aceptaci\u00f3n. Par\u00e1metros como net.ipv4.tcp_max_syn_backlog, tcp_syncookies y net.core.somaxconn influyen en el n\u00famero de intentos de conexi\u00f3n y de sockets completamente establecidos que se mantienen. El backlog se aplica por separado a cada socket de escucha; con SO_REUSEPORT, la capacidad te\u00f3rica del b\u00fafer se multiplica entre todos los trabajadores. Sin embargo, en la pr\u00e1ctica, la tarjeta de red y la carga de la CPU son las que imponen el l\u00edmite. Mantengo los backlogs de forma coherente y mido las tasas de p\u00e9rdida y retransmisi\u00f3n para detectar a tiempo los cuellos de botella.<\/p>\n\n<h2>Detalles de Nginx: accept_mutex, cierre de trabajadores y TLS<\/h2>\n<p>En cuanto utilizo reuseport, desactivo accept_mutex en Nginx, ya que el kernel se encarga de la asignaci\u00f3n equitativa. En el reinicio progresivo, elijo la opci\u00f3n \u201egraceful\u201c y espero a que finalicen las conexiones Keep-Alive, para que no se interrumpan las transferencias largas. En cuanto a TLS, me aseguro de que haya claves de ticket comunes entre los trabajadores e instancias, para que la reanudaci\u00f3n y los ID de sesi\u00f3n funcionen independientemente del listener asignado. Compruebo que los trabajadores no crezcan demasiado (huella de cach\u00e9 y memoria) para evitar cach\u00e9s fr\u00edas en los cambios de proceso.<\/p>\n\n<h2>Activaci\u00f3n de sockets en systemd, contenedores y orquestaci\u00f3n<\/h2>\n<p>Si systemd abre sockets por adelantado, debe establecer SO_REUSEPORT; de lo contrario, se bloquean las conexiones paralelas. En entornos de contenedores, me aseguro de que, por cada pod o contenedor, se cree realmente el n\u00famero deseado de procesos de trabajo y de que la asignaci\u00f3n de CPU del cgroup se ajuste a la estrategia de afinidad. En los orquestadores, planifico la estrategia de actualizaci\u00f3n progresiva de tal forma que el grupo Reuseport se mantenga estable durante los despliegues y no bloquee ning\u00fan puerto de forma exclusiva. Las comprobaciones de estado no deben generar ruido innecesario por cada trabajador ni distorsionar la distribuci\u00f3n.<\/p>\n\n<h2>Reconocimiento de NUMA y localidad de la memoria<\/h2>\n<p>En sistemas NUMA, asigno los trabajadores a los n\u00facleos del mismo nodo NUMA y me aseguro de que las IRQ de las tarjetas de red se dirijan preferentemente all\u00ed. Superviso los accesos a la memoria remota y las migraciones de p\u00e1ginas, ya que provocan picos de latencia. Si la carga de trabajo se ampl\u00eda considerablemente, puede resultar conveniente una r\u00e9plica por nodo NUMA con su propio puerto\/front-end; en combinaci\u00f3n con SO_REUSEPORT, consigo latencias muy estables, siempre y cuando las rutas de datos y de c\u00f3digo permanezcan locales al nodo.<\/p>\n\n<h2>HTTP\/3 y el enfoque en UDP<\/h2>\n<p>Con HTTP\/3 (QUIC) me beneficio especialmente de SO_REUSEPORT en la ruta UDP: muchos handshakes y conexiones breves se distribuyen sin necesidad de un equilibrador de carga adicional en el espacio de usuario. Me aseguro de que los b\u00faferes UDP tengan un tama\u00f1o suficiente y compruebo los contadores de paquetes perdidos por cola. Dado que QUIC vincula las conexiones l\u00f3gicamente a la 5-tupla, la distribuci\u00f3n se mantiene estable; no obstante, me aseguro de aplicar estrategias consistentes de reintentos y tokens para que la selecci\u00f3n del trabajador siga siendo transparente y eficiente.<\/p>\n\n<h2>Ajuste preciso de eBPF para Reuseport<\/h2>\n<p>Con un programa BPF de Reuseport puedo controlar a\u00fan m\u00e1s la selecci\u00f3n de sockets, por ejemplo, seg\u00fan el nombre de host de destino (SNI), las prioridades locales o la carga por trabajador. Solo lo utilizo cuando la distribuci\u00f3n por hash predeterminada no es suficiente, ya que la l\u00f3gica adicional aumenta la complejidad. Para la resoluci\u00f3n de problemas, compruebo si los programas BPF se han cargado realmente y funcionan sin errores, y tengo preparada una estrategia de reserva por si es necesario descargar la pol\u00edtica.<\/p>\n\n<h2>Resistencia y seguridad DDoS<\/h2>\n<p>SO_REUSEPORT aumenta la capacidad de recepci\u00f3n, lo cual supone tanto una ventaja como un riesgo. Establezco l\u00edmites de velocidad y de conexiones por trabajador para evitar que los procesos individuales se saturen de forma desequilibrada. En combinaci\u00f3n con SYN-cookies, tiempos de espera moderados y l\u00edmites L7 bien definidos, evito que los picos de carga consuman recursos de forma permanente. Separo los registros para detectar m\u00e1s r\u00e1pidamente los patrones de uso indebido por trabajador y, si es necesario, utilizo iptables\/nftables para limitar el tr\u00e1fico de fuentes maliciosas desde el principio.<\/p>\n\n<h2>Depuraci\u00f3n y verificaci\u00f3n<\/h2>\n<p>Compruebo la configuraci\u00f3n con ss -ltnp (TCP) o ss -lunp (UDP), respectivamente, para ver si hay varios listeners en la misma combinaci\u00f3n de IP y puerto. Con perf, top\/htop y mpstat verifico que el uso de la CPU sea uniforme. Los contadores de netstat\/ss, los mensajes de dmesg y las estad\u00edsticas de paquetes descartados de la tarjeta de red (ethtool -S) indican si las colas se desbordan. Para an\u00e1lisis m\u00e1s detallados, tcpdump y los eventos de Perf ofrecen informaci\u00f3n sobre las rutas de aceptaci\u00f3n, las retransmisiones y los reintentos. La correlaci\u00f3n sigue siendo fundamental: hay que analizar siempre las m\u00e9tricas por trabajador, por CPU y por cola.<\/p>\n\n<h2>Evitar errores de configuraci\u00f3n habituales<\/h2>\n<ul>\n  <li>Un worker que no tenga SO_REUSEPORT se conecta primero y bloquea a todos los dem\u00e1s.<\/li>\n  <li>Se utiliza una combinaci\u00f3n de 0.0.0.0 y direcciones IP espec\u00edficas; los oyentes se agrupan en grupos separados.<\/li>\n  <li>\u00abaccept_mutex\u00bb se activa en Nginx a pesar de \u00abreuseport\u00bb: serializaci\u00f3n innecesaria.<\/li>\n  <li>Backlogs inadecuados: el somaxconn es menor que el backlog establecido en el servidor.<\/li>\n  <li>Sin una configuraci\u00f3n conjunta de los tickets TLS: la tasa de reanudaci\u00f3n se desploma.<\/li>\n  <li>RSS mal dimensionado: la carga de IRQ se concentra en unos pocos n\u00facleos.<\/li>\n<\/ul>\n\n<h2>Planificaci\u00f3n de la capacidad: tama\u00f1o de los trabajadores y l\u00edmites de FD<\/h2>\n<p>Equilibro el n\u00famero de trabajadores con la memoria RAM por trabajador, los archivos abiertos y el n\u00famero de conexiones. Demasiados procesos aumentan los cambios de contexto y la presi\u00f3n sobre la cach\u00e9; muy pocos desperdician el potencial de paralelismo. Establezco los l\u00edmites de descriptores de archivo de forma generosa y coherente (ulimit, l\u00edmites de systemd, l\u00edmites duros\/blandos), ya que cada proceso necesita sus propios descriptores de archivo para sockets, registros y conexiones ascendentes. Adem\u00e1s, preveo un n\u00famero suficiente de puertos ef\u00edmeros y superviso el volumen de TIME_WAIT para que los picos de tr\u00e1fico a corto plazo no se pierdan en la nada.<\/p>\n\n<h2>Pruebas de rendimiento: errores t\u00edpicos<\/h2>\n<p>Precaliento los servidores y las cach\u00e9s, calibro el generador de carga (para evitar cuellos de botella ocultos) y separo la red de control de la de datos. Las pruebas duran lo suficiente como para medir de forma estable los valores p99\/p999, y var\u00edo los tiempos de reflexi\u00f3n, las tasas de keep-alive y los par\u00e1metros TLS. Registro la configuraci\u00f3n del n\u00facleo y del servidor para que las ejecuciones posteriores sean comparables. Cuando utilizo pol\u00edticas eBPF, documento su versi\u00f3n y su efecto por separado para no confundir causa y efecto.<\/p>\n\n<h2>Lista de control para el inicio<\/h2>\n\n<p>Primero compruebo la versi\u00f3n del n\u00facleo y me aseguro de que SO_REUSEPORT est\u00e9 disponible y sea correcto <strong>establecido<\/strong> . A continuaci\u00f3n, activo la opci\u00f3n en la configuraci\u00f3n del servidor web y configuro el n\u00famero deseado de trabajadores. Compruebo somaxconn, los l\u00edmites de descriptores de archivo y las colas de la NIC. Despu\u00e9s, realizo pruebas de carga, comparo m\u00e9tricas y repito el proceso. Por \u00faltimo, optimizo el registro, la estrategia de reinicio y <strong>afinidad<\/strong> de.<\/p>\n\n<h2>Resumen<\/h2>\n\n<p>SO_REUSEPORT elimina el cuello de botella de Accept, distribuye las nuevas conexiones mediante un hash del n\u00facleo y ofrece un mayor rendimiento en sistemas multin\u00facleo <strong>Rendimiento<\/strong> . Utilizo varios listeners por puerto, evito el problema del \u201eThundering Herd\u201c y me ahorro tener que usar un dispatcher independiente. En Nginx, esto se consigue con \u00ablisten \u2026 reuseport\u00bb y un n\u00famero adecuado de trabajadores. Junto con la afinidad de CPU, una distribuci\u00f3n adecuada de las IRQ y unos b\u00faferes razonables, me aseguro de que haya una <strong>Latencias<\/strong> bajo carga. Quien compruebe, pruebe y ajuste con precisi\u00f3n estos pasos, mejorar\u00e1 el rendimiento sin incurrir en costes adicionales de hardware en euros.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubre c\u00f3mo SO_REUSEPORT mejora el rendimiento de tu servidor web en Linux. Aprende c\u00f3mo funciona esta opci\u00f3n de socket y c\u00f3mo utilizarla en Nginx y otros servicios.<\/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":"108","_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\/es\/wp-json\/wp\/v2\/posts\/20890","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=20890"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20890\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20883"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20890"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20890"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20890"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}