{"id":20714,"date":"2026-08-16T18:19:23","date_gmt":"2026-08-16T16:19:23","guid":{"rendered":"https:\/\/webhosting.de\/nginx-worker-processes-optimal-konfigurieren-performanceboost\/"},"modified":"2026-08-16T18:19:23","modified_gmt":"2026-08-16T16:19:23","slug":"optymalna-konfiguracja-procesow-roboczych-nginx-zwiekszenie-wydajnosci","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/nginx-worker-processes-optimal-konfigurieren-performanceboost\/","title":{"rendered":"Optymalna konfiguracja proces\u00f3w roboczych NGINX w celu uzyskania maksymalnej wydajno\u015bci"},"content":{"rendered":"<p>Konfiguruj\u0119 <strong>NGINX Worker<\/strong> tak, aby warto\u015bci worker_processes, worker_connections i worker_rlimit_nofile by\u0142y dok\u0142adnie dopasowane, a epoll dzia\u0142a\u0142 w p\u0119tli zdarze\u0144. Dzi\u0119ki temu korzystam z <strong>Rdzenie CPU<\/strong> zapewnij wydajno\u015b\u0107, umo\u017cliw planowanie skalowania liczby jednoczesnych po\u0142\u0105cze\u0144 oraz utrzymuj niskie op\u00f3\u017anienia w okresach szczytowego obci\u0105\u017cenia.<\/p>\n\n<h2>Punkty centralne<\/h2>\n<p>Poni\u017csze kluczowe aspekty pozwol\u0105 Ci od razu zorientowa\u0107 si\u0119, jak skonfigurowa\u0107 niezawodn\u0105 instancj\u0119 robocz\u0105 NGINX.<\/p>\n<ul>\n  <li><strong>worker_processes<\/strong> powi\u0105za\u0107 z liczb\u0105 rdzeni logicznych, najlepiej z opcj\u0105 \u201eauto\u201c.<\/li>\n  <li><strong>worker_connections<\/strong> ustawi\u0107 tak, aby z \u0142atwo\u015bci\u0105 pokry\u0107 rzeczywiste szczyty.<\/li>\n  <li><strong>rlimit_nofile<\/strong> oraz zwi\u0119kszy\u0107 limity systemu operacyjnego odpowiednio do przepustowo\u015bci \u0142\u0105cza.<\/li>\n  <li><strong>epoll<\/strong> oraz w\u0142\u0105czy\u0107 opcj\u0119 multi_accept, aby efektywnie wykorzysta\u0107 p\u0119tl\u0119 zdarze\u0144.<\/li>\n  <li><strong>Testy obci\u0105\u017ceniowe<\/strong> post\u0119powa\u0107 i precyzyjnie dostosowywa\u0107, wykonuj\u0105c ma\u0142e kroki.<\/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\/nginx-optimierung-serverraum-5961.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Architektura NGINX: co to s\u0105 serwery g\u0142\u00f3wne i pomocnicze<\/h2>\n<p>Rozdzielam zadania od <strong>Mistrz<\/strong> Rola serwera g\u0142\u00f3wnego i serwer\u00f3w roboczych jest jasna: serwer g\u0142\u00f3wny \u0142aduje konfiguracje, otwiera gniazda i uruchamia procesy, podczas gdy serwery robocze przetwarzaj\u0105 \u017c\u0105dania w p\u0119tli zdarze\u0144. Ka\u017cdy serwer roboczy dzia\u0142a niezale\u017cnie, reaguje na zdarzenia i mo\u017ce zarz\u0105dza\u0107 tysi\u0105cami po\u0142\u0105cze\u0144 bez powodowania blokad. Model ten sprawdza si\u0119 znakomicie, gdy odpowiednio wykorzystuj\u0119 rdzenie procesora i optymalnie obs\u0142uguj\u0119 p\u0119tl\u0119 zdarze\u0144 za pomoc\u0105 epoll. Pami\u0119tam przy tym, \u017ce ka\u017cdy dodatkowy przeskok przez serwer proxy zu\u017cywa zasoby po\u0142\u0105cze\u0144, co znajduje odzwierciedlenie w limitach. Kto rozumie te role, ten \u015bwiadomie podejmuje decyzje dotycz\u0105ce <strong>Zasoby<\/strong> i zapobiega wczesnym w\u0105skim gard\u0142om.<\/p>\n\n<h2>W\u0142a\u015bciwe po\u0142\u0105czenie trzech kluczowych wytycznych<\/h2>\n<p>Rozwa\u017cam <strong>worker_processes<\/strong>, worker_connections i worker_rlimit_nofile nigdy nie rozpatruj\u0119 osobno, lecz jako ca\u0142o\u015b\u0107. \u0141\u0105czna liczba mo\u017cliwych po\u0142\u0105cze\u0144 wynika z iloczynu liczby proces\u00f3w roboczych i liczby po\u0142\u0105cze\u0144 na jeden proces roboczy; na tej podstawie ustalam limity dla deskryptor\u00f3w plik\u00f3w. Je\u015bli te parametry nie s\u0105 ze sob\u0105 zgrane, napotykam b\u0142\u0105d \u201etoo many open files\u201c lub wyst\u0119puj\u0105 twarde limity czasu. W przypadku du\u017cego obci\u0105\u017cenia potrzebuj\u0119 sp\u00f3jnego \u0142a\u0144cucha: wystarczaj\u0105cej liczby proces\u00f3w, du\u017cej liczby po\u0142\u0105cze\u0144, odpowiednio zwi\u0119kszonej warto\u015bci rlimit_nofile oraz odpowiednich parametr\u00f3w systemu operacyjnego. W ten spos\u00f3b zapobiegam sytuacji, w kt\u00f3rej zbyt ma\u0142a <strong>Limit<\/strong> ca\u0142a wydajno\u015b\u0107 zosta\u0142a ograniczona.<\/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_worker_meeting_3021.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>worker_processes: Wybierz konkretn\u0105 liczb\u0119<\/h2>\n<p>Ustawi\u0142em <strong>worker_processes<\/strong> Zazwyczaj ustawia si\u0119 t\u0119 opcj\u0119 na \u201eauto\u201c, aby NGINX m\u00f3g\u0142 rozpozna\u0107 liczb\u0119 logicznych rdzeni procesora i wykorzysta\u0107 ka\u017cdy z nich. Jeden proces roboczy na rdze\u0144 pozwala unikn\u0105\u0107 niepotrzebnych zmian kontekstu i zapewnia r\u00f3wnomierny rozk\u0142ad obci\u0105\u017cenia, dzi\u0119ki czemu czas reakcji pozostaje przewidywalny. Na maszynach z bardzo du\u017c\u0105 liczb\u0105 rdzeni celowo testuj\u0119 r\u00f3wnie\u017c mniejsz\u0105 liczb\u0119 proces\u00f3w roboczych, aby por\u00f3wna\u0107 trafienia w pami\u0119ci podr\u0119cznej i obci\u0105\u017cenie rdzeni. Je\u015bli wska\u017aniki pokazuj\u0105, \u017ce rdzenie s\u0105 przeci\u0105\u017cone lub ro\u015bnie liczba nieudanych odwo\u0142a\u0144 do TLB, stopniowo dostosowuj\u0119 liczb\u0119 proces\u00f3w roboczych. Najpierw pomiar, potem zmiana \u2013 w ten spos\u00f3b zapewniam sobie wiarygodne <strong>Wyniki<\/strong>.<\/p>\n\n<h2>worker_connections: planowane zwi\u0119kszenie liczby po\u0142\u0105cze\u0144<\/h2>\n<p>Wybieram <strong>worker_connections<\/strong> w zale\u017cno\u015bci od ruchu docelowego i zestawu protoko\u0142\u00f3w, cz\u0119sto zaczynaj\u0105c od 2048 lub 4096. W przypadku intensywnie wykorzystywanych interfejs\u00f3w API rozwa\u017cam warto\u015b\u0107 8192, o ile pozwalaj\u0105 na to ograniczenia systemu operacyjnego i pami\u0119\u0107 RAM. Ka\u017cde zwi\u0119kszenie tej warto\u015bci sprawdzam za pomoc\u0105 test\u00f3w obci\u0105\u017ceniowych, poniewa\u017c otwarte po\u0142\u0105czenia zajmuj\u0105 pami\u0119\u0107 i wp\u0142ywaj\u0105 na wydajno\u015b\u0107 sieci upstream. Je\u015bli dominuj\u0105 uzgodnienia SSL lub du\u017ce przesy\u0142ania danych, kieruj\u0119 si\u0119 raczej profilami obci\u0105\u017cenia procesora i operacji wej\u015bcia\/wyj\u015bcia, a nie tylko sam\u0105 liczb\u0105 po\u0142\u0105cze\u0144. W ten spos\u00f3b zapewniam, \u017ce zdefiniowana na pracownika <strong>Pojemno\u015b\u0107<\/strong> pozostaje r\u00f3wnie\u017c przydatny w praktyce.<\/p>\n\n<h2>Synchronizacja parametr\u00f3w `worker_rlimit_nofile` i limit\u00f3w systemu operacyjnego<\/h2>\n<p>Dopilnuj\u0119, aby <strong>rlimit_nofile<\/strong> pokrywa co najmniej ca\u0142kowit\u0105 pojemno\u015b\u0107 obliczeniow\u0105 i cz\u0119sto jest skonfigurowany z rezerw\u0105. W scenariuszach z odwrotnym proxy uwzgl\u0119dniam drugi deskryptor do serwera upstream na ka\u017cde po\u0142\u0105czenie klienta. W zwi\u0105zku z tym ch\u0119tnie ustawiam rlimit_nofile na warto\u015b\u0107 dwukrotnie wy\u017csz\u0105 od oczekiwanej liczby jednoczesnych po\u0142\u0105cze\u0144. Limity j\u0105dra i u\u017cytkownika (ulimit -n, fs.file-max) zwi\u0119kszam tak, aby NGINX m\u00f3g\u0142 faktycznie wykorzysta\u0107 te warto\u015bci. Je\u015bli w dzienniku b\u0142\u0119d\u00f3w pojawiaj\u0105 si\u0119 komunikaty dotycz\u0105ce otwartych plik\u00f3w, szybko zwi\u0119kszam limity i obserwuj\u0119 <strong>Op\u00f3\u017anienie<\/strong> ponownie pod obci\u0105\u017ceniem.<\/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-5123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Blok wydarze\u0144: efektywne wykorzystanie epoll i multi_accept<\/h2>\n<p>W bloku \u201eWydarzenia\u201d aktywuj\u0119 <strong>epoll<\/strong> i ustawiam multi_accept na \u201eon\u201c, aby procesy robocze przyjmowa\u0142y oczekuj\u0105ce po\u0142\u0105czenia w jednym przebiegu. Epoll zmniejsza obci\u0105\u017cenie przy du\u017cej liczbie jednoczesnych gniazd i wsp\u00f3\u0142gra z nieblokuj\u0105c\u0105 architektur\u0105 NGINX. Te opcje sprawdzaj\u0105 si\u0119 podczas szczyt\u00f3w ruchu, poniewa\u017c przyspieszaj\u0105 faz\u0119 przyjmowania po\u0142\u0105cze\u0144 i pozwalaj\u0105 szybciej przej\u015b\u0107 do w\u0142a\u015bciwego przetwarzania. W systemie Linux jest to moje standardowe ustawienie, kt\u00f3re zmieniam tylko w rzadkich, szczeg\u00f3lnych przypadkach. Osoby pragn\u0105ce zg\u0142\u0119bi\u0107 ten temat mog\u0105 por\u00f3wna\u0107 model p\u0119tli zdarze\u0144 z <a href=\"https:\/\/webhosting.de\/pl\/threadpool-serwer-www-apache-nginx-litespeed-optymalizacja-konfiguracja\/\">Pula w\u0105tk\u00f3w a p\u0119tla zdarze\u0144<\/a> i wyci\u0105ga z tego wniosek, \u017ce <strong>wnioski<\/strong> dla w\u0142asnego otoczenia.<\/p>\n\n<h2>Afinno\u015b\u0107 procesora: przypisywanie proces\u00f3w roboczych do rdzeni<\/h2>\n<p>Ustawi\u0142em <strong>affinno\u015b\u0107 procesora dla procesu<\/strong> stosuj\u0119 to celowo, gdy obci\u0105\u017cenia s\u0105 sta\u0142e i zale\u017cne od procesora. Schemat przypisywania rozdzielam za pomoc\u0105 masek bitowych, aby unikn\u0105\u0107 zmian kontekstu i zwi\u0119kszy\u0107 lokalno\u015b\u0107 pami\u0119ci podr\u0119cznej. W przypadku czterech rdzeni przypisuj\u0119 maski w taki spos\u00f3b, aby ka\u017cdy proces pracuj\u0105cy otrzyma\u0142 w\u0142asny rdze\u0144. Nast\u0119pnie sprawdzam wska\u017aniki brak\u00f3w w pami\u0119ci podr\u0119cznej, mediany op\u00f3\u017anie\u0144 oraz 99. percentyl, aby wyra\u017anie dostrzec efekt. Bardziej szczeg\u00f3\u0142owe wyja\u015bnienia dotycz\u0105ce powinowactwa i NUMA znajdziesz w skr\u00f3conej formie na stronie <a href=\"https:\/\/webhosting.de\/pl\/server-process-affinity-numa-awareness-hosting-ressourcentuning\/\">Afinity procesora w praktyce<\/a>, co przy precyzyjnym dostrajaniu <strong>Pracownik<\/strong>-uk\u0142ady s\u0105 pomocne.<\/p>\n\n<h2>Planowanie wydajno\u015bci: rezerwa wydajno\u015bci i testy obci\u0105\u017ceniowe<\/h2>\n<p>W przypadku po\u0142\u0105cze\u0144 planuj\u0119 <strong>Bufor<\/strong> kt\u00f3ry znacznie przewy\u017csza obserwowane warto\u015bci szczytowe, aby kr\u00f3tkotrwa\u0142e skoki nie powodowa\u0142y bezpo\u015bredniego przekroczenia limit\u00f3w. Je\u015bli jako punkt wyj\u015bcia podwoj\u0119 obci\u0105\u017cenie szczytowe, w wielu scenariuszach zyskuj\u0119 solidny margines bezpiecze\u0144stwa. W przypadku silnie zmiennego ruchu zwi\u0119kszam bufor jeszcze bardziej, a\u017c 99. percentyle b\u0119d\u0105 przebiega\u0107 p\u0142ynnie. Nast\u0119pnie sprawdzam w\u0105skie gard\u0142a za pomoc\u0105 narz\u0119dzi takich jak wrk lub k6, obserwuj\u0119 wska\u017aniki b\u0142\u0119d\u00f3w i sprawdzam status otwartych po\u0142\u0105cze\u0144. Dopiero gdy wska\u017aniki s\u0105 sp\u00f3jne, celowo zwi\u0119kszam lub zmniejszam poszczeg\u00f3lne <strong>Warto\u015bci<\/strong>.<\/p>\n\n<h2>Konfiguracja i przyk\u0142ady oblicze\u0144<\/h2>\n<p>Obliczam przepustowo\u015b\u0107 po\u0142\u0105cze\u0144, mno\u017c\u0105c liczb\u0119 proces\u00f3w roboczych przez liczb\u0119 po\u0142\u0105cze\u0144 na jeden proces roboczy, a nast\u0119pnie ustalam limity na wy\u017cszym poziomie, wynikaj\u0105cym z tych oblicze\u0144. Przy czterech rdzeniach procesora z opcj\u0105 \u201eauto\u201d i 4096 po\u0142\u0105cze\u0144 na proces roboczy, obliczeniowo dochodz\u0119 do 16 384 jednoczesnych po\u0142\u0105cze\u0144. W scenariuszach z serwerem proxy ustawiam rlimit_nofile raczej na 32 768 lub wi\u0119cej, aby uwzgl\u0119dni\u0107 gniazda upstream. W przypadku ma\u0142ych maszyn z dwoma rdzeniami cz\u0119sto wystarcza 2048 po\u0142\u0105cze\u0144 na pracownika, o ile udzia\u0142 transferu wychodz\u0105cego i po\u0142\u0105cze\u0144 TLS pozostaje umiarkowany. Poni\u017csza tabela pomaga w klasyfikacji <strong>Warto\u015bci pocz\u0105tkowe<\/strong>:<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Rdzenie CPU<\/th>\n      <th>worker_processes<\/th>\n      <th>worker_connections (Pocz\u0105tek)<\/th>\n      <th>Min. rlimit_nofile (warto\u015b\u0107 orientacyjna)<\/th>\n      <th>Wskaz\u00f3wka<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>2<\/td>\n      <td>auto (\u22482)<\/td>\n      <td>2048<\/td>\n      <td>\u2265 4096<\/td>\n      <td><strong>Rezerwa<\/strong> zaplanowa\u0107 dla TLS\/proxy<\/td>\n    <\/tr>\n    <tr>\n      <td>4<\/td>\n      <td>auto (\u22484)<\/td>\n      <td>4096<\/td>\n      <td>\u2265 16 384<\/td>\n      <td>W przypadku serwer\u00f3w proxy cz\u0119sto wsp\u00f3\u0142czynnik 2 dla FD<\/td>\n    <\/tr>\n    <tr>\n      <td>8<\/td>\n      <td>auto (\u22488)<\/td>\n      <td>4096-8192<\/td>\n      <td>\u2265 32768<\/td>\n      <td><strong>Test obci\u0105\u017cenia<\/strong> podejmuje decyzj\u0119 o podwy\u017cce<\/td>\n    <\/tr>\n    <tr>\n      <td>16+<\/td>\n      <td>auto, ewentualnie mniej<\/td>\n      <td>8192+<\/td>\n      <td>\u2265 65535<\/td>\n      <td>Testowanie z wyczuciem i pow\u015bci\u0105gliwo\u015bci\u0105<\/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\/nginx_performance_opt_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NGINX Worker i Upstreams: w\u0142a\u015bciwe wywa\u017cenie scenariuszy<\/h2>\n<p>Rozr\u00f3\u017cniam dostarczanie statyczne, tryb odwrotnego proxy oraz obci\u0105\u017cenie bramy API, poniewa\u017c maj\u0105 one <strong>Pracownik<\/strong>-R\u00f3\u017cne wymagania konfiguracyjne. Tre\u015bci statyczne zu\u017cywaj\u0105 mniej zasob\u00f3w, podczas gdy TLS, kompresja i po\u0142\u0105czenia upstream obci\u0105\u017caj\u0105 w wi\u0119kszym stopniu procesor i deskryptory plik\u00f3w (FD). Im wi\u0119ksze klucze SSL i im wi\u0119cej procedur uzgadniania po\u0142\u0105czenia, tym wi\u0119ksze korzy\u015bci przynosi ustawienie \u201ejeden worker na rdze\u0144\u201c. Du\u017ce przesy\u0142anki powoduj\u0105 przesuni\u0119cie profilu w kierunku operacji wej\u015bcia\/wyj\u015bcia, co sprawia, \u017ce zwracam wi\u0119ksz\u0105 uwag\u0119 na rlimit_nofile i bufory sieciowe. W przypadku odczuwalnych op\u00f3\u017anie\u0144 w przyjmowaniu danych lub odpowiedzi z backendu pomocny jest mi przegl\u0105d <a href=\"https:\/\/webhosting.de\/pl\/serwer-www-kolejkowanie-opoznienie-obsluga-zadan-kolejka-serwera\/\">Kolejki i op\u00f3\u017anienia<\/a>, aby unikn\u0105\u0107 w\u0105skich miejsc <strong>ukierunkowany<\/strong> rozwi\u0105za\u0107.<\/p>\n\n<h2>Przebieg pracy w praktyce: krok po kroku do szybszego serwera<\/h2>\n<p>Zaczn\u0119 od sporz\u0105dzenia aktualnego zestawienia wszystkich istotnych <strong>Warto\u015bci<\/strong> W pliku nginx.conf sprawdzam liczb\u0119 rdzeni procesora, ustawienia ulimit oraz parametry j\u0105dra. Nast\u0119pnie ustawiam worker_processes na auto, ustalam worker_connections na przyk\u0142ad na 4096 i znacznie zwi\u0119kszam warto\u015b\u0107 rlimit_nofile. W bloku Events w\u0142\u0105czam epoll oraz multi_accept, a nast\u0119pnie po prze\u0142adowaniu sprawdzam logi. Nast\u0119pnie przeprowadzam testy obci\u0105\u017ceniowe w powtarzalnych warunkach, podczas kt\u00f3rych obserwuj\u0119 czasy odpowiedzi, wska\u017aniki b\u0142\u0119d\u00f3w i liczb\u0119 otwartych po\u0142\u0105cze\u0144. Podczas dopracowywania ustawie\u0144 zmieniam zawsze tylko jedn\u0105 zmienn\u0105, dokumentuj\u0119 ka\u017cdy krok i sprawdzam skutki w <strong>Metryki<\/strong>.<\/p>\n\n<h2>\u015arodowisko hostingowe: zasoby, j\u0105dro, sie\u0107<\/h2>\n<p>Dbam o to, by by\u0142o wystarczaj\u0105co <strong>CPU<\/strong>-rdzenie, wystarczaj\u0105ca ilo\u015b\u0107 pami\u0119ci RAM, szybkie dyski SSD lub NVMe oraz aktualne j\u0105dro systemu Linux. Tylko w ten spos\u00f3b epoll, nowoczesne stosy TCP i przydatne funkcje odci\u0105\u017cania dzia\u0142aj\u0105 niezawodnie. Parametry sieciowe, takie jak somaxconn i tcp_max_syn_backlog, dostosowuj\u0119 do docelowej liczby po\u0142\u0105cze\u0144, aby kolejki przyjmowania by\u0142y kr\u00f3tkie. Warto zdecydowa\u0107 si\u0119 na dostawc\u0119 oferuj\u0105cego wysok\u0105 wydajno\u015b\u0107 operacji wej\u015bcia\/wyj\u015bcia oraz swobodny dost\u0119p do konfiguracji systemu. Z por\u00f3wna\u0144 wynika, \u017ce us\u0142ugi o sta\u0142ej <strong>Zasoby<\/strong> Znacznie zwi\u0119kszy\u0107 mo\u017cliwo\u015bci NGINX.<\/p>\n\n<h2>Strategia keepalive: po\u0142\u0105czenia z klientem i po\u0142\u0105czenia upstream<\/h2>\n<p>Celowo wykorzystuj\u0119 Keepalive jako narz\u0119dzie do regulacji przepustowo\u015bci i op\u00f3\u017anie\u0144. Po stronie klienta ustawiam <strong>keepalive_timeout<\/strong> nie za wysoka, aby nieaktywne gniazda nie by\u0142y niepotrzebnie <em>worker_connections<\/em> zablokowa\u0107. Warto\u015bci z przedzia\u0142u 10\u201330 s cz\u0119sto stanowi\u0105 dla mnie dobry kompromis mi\u0119dzy ponownym wykorzystaniem a zaj\u0119ciem zasob\u00f3w. Z <strong>keepalive_requests<\/strong> Ograniczam liczb\u0119 \u017c\u0105da\u0144 na po\u0142\u0105czenie, aby ograniczy\u0107 d\u0142ugotrwa\u0142e po\u0142\u0105czenia i unikn\u0105\u0107 obci\u0105\u017cenia pami\u0119ci. Po stronie upstream (proxy odwrotne) utrzymuj\u0119 trwa\u0142e po\u0142\u0105czenia z <strong>keepalive<\/strong> w bloku upstream, dzi\u0119ki czemu nie s\u0105 wymagane procedury uzgadniania po\u0142\u0105czenia ani konfiguracja TCP. Przy tym ostro\u017cnie skaluj\u0119 liczb\u0119 na backend w zale\u017cno\u015bci od jego wydajno\u015bci (<em>max_conns<\/em>), w przeciwnym razie sam generuj\u0119 kolejki w upstreemie. Wa\u017cne: ka\u017cde gniazdo keepalive liczy si\u0119 jako otwarte po\u0142\u0105czenie i wymaga numer\u00f3w FD; uwzgl\u0119dniam to w <em>rlimit_nofile<\/em> oraz moje plany dotycz\u0105ce rezerwy mocy.<\/p>\n\n<h2>Optymalizacja list: reuseport, backlog i strategia akceptacji<\/h2>\n<p>R\u00f3wnomiernie rozk\u0142adam obci\u0105\u017cenie, poprzez <strong>SO_REUSEPORT<\/strong> aktywuj (listen \u2026 reuseport). Dzi\u0119ki temu ka\u017cdy worker posiada w\u0142asn\u0105 kolejk\u0119 Accept, co ogranicza zjawisko \u201ethundering herds\u201c i pozwala unikn\u0105\u0107 punkt\u00f3w przeci\u0105\u017cenia. W po\u0142\u0105czeniu z <strong>multi_accept<\/strong> znacznie przyspieszam faz\u0119 przyjmowania. Lista-<strong>zaleg\u0142o\u015bci<\/strong> (listen \u2026 backlog=) oraz odpowiadaj\u0105ce im parametry j\u0105dra (somaxconn, tcp_max_syn_backlog) ustawiam na do\u015b\u0107 wysokie warto\u015bci, aby szczytowe obci\u0105\u017cenia nie rozprasza\u0142y si\u0119 na wej\u015bciu gniazda. Opcja <strong>odroczony<\/strong> odk\u0142ada akceptacj\u0119 do momentu otrzymania danych \u2013 w przypadku wielu \u017c\u0105da\u0144 o kr\u00f3tkim czasie trwania mo\u017ce to pom\u00f3c; w pozosta\u0142ych przypadkach sprawdzam to w testach. Czy <strong>accept_mutex<\/strong> Czy jest mi to potrzebne, sprawdzam w te\u015bcie por\u00f3wnawczym: przy u\u017cyciu reuseportu zazwyczaj mo\u017cna si\u0119 bez niego obej\u015b\u0107; bez reuseportu mo\u017ce on poprawi\u0107 sprawiedliwo\u015b\u0107, ale wymaga koordynacji. Tutaj podejmuj\u0119 decyzj\u0119 w oparciu o dane, nigdy na podstawie przeczucia.<\/p>\n\n<h2>Stabilne ustawienie limit\u00f3w czasu i kolejek<\/h2>\n<p>Ustawi\u0142em <strong>Limity czasu<\/strong> tak, aby wolno dzia\u0142aj\u0105ce klienty nie przeci\u0105\u017ca\u0142y proces\u00f3w roboczych: <em>client_header_timeout<\/em> oraz <em>client_body_timeout<\/em> Ustalam je na tyle w\u0105skie, by unikn\u0105\u0107 zawiesze\u0144, ale na tyle szerokie, by by\u0142y wygodne dla prawdziwych u\u017cytkownik\u00f3w. <em>send_timeout<\/em> zapobiega blokowaniu odpowiedzi wysy\u0142anych do klienta. W kontek\u015bcie serwera proxy definiuj\u0119 <em>proxy_connect_timeout<\/em>, <em>proxy_read_timeout<\/em> oraz <em>proxy_send_timeout<\/em> rygorystycznie, aby zawieszone modu\u0142y zaplecza nie parali\u017cowa\u0142y interfejsu u\u017cytkownika. W przypadku modu\u0142\u00f3w zaplecza o ograniczonej r\u00f3wnoleg\u0142o\u015bci korzystam z <strong>kolejka<\/strong> w bloku upstream z limitem czasu, aby z\u0142agodzi\u0107 szczyty obci\u0105\u017cenia i w kontrolowany spos\u00f3b sygnalizowa\u0107 b\u0142\u0105d 503, zamiast przypisywania wszystkich proces\u00f3w roboczych do oczekuj\u0105cych gniazd upstream. Dodatkowo stabilizuj\u0119 dzia\u0142anie za pomoc\u0105 <strong>limit_req<\/strong> (Burst\/Delay) oraz <strong>limit_conn<\/strong> optymalizacja \u015bcie\u017cek, tak aby poszczeg\u00f3lne klienty lub boty nie zu\u017cywa\u0142y nieproporcjonalnie du\u017cej ilo\u015bci zasob\u00f3w.<\/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_worker_performance_8392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Buforowanie, sendfile i AIO: \u015bwiadomy wyb\u00f3r metod operacji wej\u015bcia\/wyj\u015bcia<\/h2>\n<p>Ustawi\u0142em <strong>sendfile<\/strong> dla plik\u00f3w statycznych i po\u0142\u0105cz to z <em>tcp_nopush<\/em>\/<em>tcp_nodelay<\/em> w zale\u017cno\u015bci od obci\u0105\u017cenia, aby efektywnie grupowa\u0107 pakiety lub zmniejszy\u0107 op\u00f3\u017anienia interakcji. W przypadku du\u017cych plik\u00f3w korzystam z <strong>kierunek<\/strong> powy\u017cej pewnego progu, aby unikn\u0105\u0107 zanieczyszczenia pami\u0119ci podr\u0119cznej i zapobiec wypchni\u0119ciu zawarto\u015bci pami\u0119ci podr\u0119cznej stron. W trybie proxy sam decyduj\u0119, czy <strong>buforowanie proxy<\/strong> pomaga (szybkie przekazywanie danych do klienta, oddzielny odczyt z \u017ar\u00f3d\u0142a) czy te\u017c w przypadku obci\u0105\u017ce\u0144 zwi\u0105zanych ze strumieniowaniem lepiej <em>proxy_request_buffering<\/em> zmniejszam, aby wcze\u015bnie zainicjowa\u0107 przesy\u0142anie plik\u00f3w. Rozmiary <em>proxy_buffers<\/em>, <em>proxy_buffer_size<\/em> oraz <em>du\u017ce bufory nag\u0142\u00f3wk\u00f3w klient\u00f3w<\/em> kontroluj\u0119 to \u015bwiadomie, aby zu\u017cycie pami\u0119ci na jedno po\u0142\u0105czenie nie wzros\u0142o gwa\u0142townie. Aby dost\u0119p do plik\u00f3w nie obci\u0105\u017ca\u0142 nadmiernie procesora, rozwa\u017cam <strong>aio<\/strong> (natywne lub w\u0105tki), ale nale\u017cy przeprowadzi\u0107 dok\u0142adne testy, poniewa\u017c p\u0119tla zdarze\u0144 i charakterystyka operacji wej\u015bcia\/wyj\u015bcia wzajemnie na siebie oddzia\u0142uj\u0105.<\/p>\n\n<h2>HTTP\/2\/HTTP\/3 i TLS: wp\u0142yw na wydajno\u015b\u0107 proces\u00f3w roboczych<\/h2>\n<p>Bior\u0119 pod uwag\u0119, \u017ce <strong>HTTP\/2<\/strong> oraz <strong>HTTP\/3<\/strong> Zmiana dynamiki po\u0142\u0105cze\u0144: Wiele \u017c\u0105da\u0144 jest przetwarzanych jako <em>Strumienie<\/em> poprzez niewielk\u0105 liczb\u0119 po\u0142\u0105cze\u0144 TCP lub QUIC. Zmniejsza to liczb\u0119 po\u0142\u0105cze\u0144, ale zwi\u0119ksza zapotrzebowanie na moc procesora i pami\u0119\u0107 na jedno po\u0142\u0105czenie (multipleksowanie, kompresja nag\u0142\u00f3wk\u00f3w, TLS\/QUIC). Moje <em>worker_connections<\/em> Nie interpretuj\u0119 tego zatem bezkrytycznie jako \u201etak\u0105 sam\u0105 liczb\u0119 \u017c\u0105da\u0144\u201c. Zauwa\u017cam, \u017ce <em>strumienie r\u00f3wnoleg\u0142e<\/em> na ka\u017cde po\u0142\u0105czenie i pasuje <em>keepalive_timeout<\/em> i w razie potrzeby. <em>http2_max_concurrent_streams<\/em> . Po stronie TLS zyskuj\u0119 dzi\u0119ki funkcji wznowienia sesji (bilety\/pami\u0119\u0107 podr\u0119czna) oraz OCSP-Stapling; w ten spos\u00f3b oszcz\u0119dzam na kosztownych procedurach nawi\u0105zywania po\u0142\u0105czenia i utrzymuj\u0119 niskie op\u00f3\u017anienia. Minus: d\u0142u\u017csze keepalive\u2019y zajmuj\u0105 FD i pami\u0119\u0107 RAM \u2013 dlatego planuj\u0119 <em>rlimit_nofile<\/em> oraz limity pami\u0119ci z realistycznymi rezerwami. W przypadku algorytm\u00f3w szyfruj\u0105cych obci\u0105\u017caj\u0105cych procesor warto przetestowa\u0107 opcj\u0119 powinowactwa oraz nowoczesne akceleratory kryptograficzne.<\/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-optimaler-setup-9182.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitorowalno\u015b\u0107: stan, logi i wska\u017aniki<\/h2>\n<p>Zapewniam przejrzysto\u015b\u0107 dzi\u0119ki uproszczonemu <strong>Status<\/strong>-Endpoint (np. stub_status), aby sprawdzi\u0107 aktywne po\u0142\u0105czenia, operacje odczytu\/zapisu\/oczekiwania oraz przyj\u0119te \u017c\u0105dania. W logach staram si\u0119 ogranicza\u0107 zb\u0119dne informacje: zwi\u0119z\u0142y <em>log_format<\/em> Z danymi dotycz\u0105cymi czasu, statusu, czasu przesy\u0142u w g\u00f3r\u0119 i liczby bajt\u00f3w wystarcza to do wi\u0119kszo\u015bci analiz. Przy bardzo wysokim QPS wy\u0142\u0105czam dziennik dost\u0119pu selektywnie (na podstawie lokalizacji) lub buforuj\u0119 logi asynchronicznie, aby operacje wej\u015bcia\/wyj\u015bcia nie spowalnia\u0142y systemu. Dziennik b\u0142\u0119d\u00f3w ustawiam na <em>ostrze\u017cenie<\/em> lub <em>b\u0142\u0105d<\/em> i prze\u0142\u0105cz si\u0119 na chwil\u0119 na ten tryb wy\u0142\u0105cznie w celu przeprowadzenia konkretnych analiz <em>debugowanie<\/em>. Na bie\u017c\u0105co koreluj\u0119 op\u00f3\u017anienia (mediana\/95. i 99. percentyl), otwarte po\u0142\u0105czenia, wska\u017aniki b\u0142\u0119d\u00f3w backendu oraz obci\u0105\u017cenie procesora na pracownika \u2013 na tej podstawie ustalam korekty trzech kluczowych dyrektyw i wcze\u015bnie wykrywam efekty nasycenia.<\/p>\n\n<h2>Kontenery i \u015brodowiska wirtualne: p\u0142ynne przekazywanie limit\u00f3w<\/h2>\n<p>Sprawdzam w kontenerach, czy <strong>cgroup<\/strong>-Ustal limity dla procesora, pami\u0119ci RAM i identyfikator\u00f3w PID, a nast\u0119pnie dostosuj je do ustawie\u0144 serwera NGINX. <em>ulimit -n<\/em> musi by\u0107 wystarczaj\u0105co wysoka w obr\u0119bie kontenera, w przeciwnym razie moje ustawienia rlimit_nofile nie b\u0119d\u0105 mia\u0142y znaczenia. W przypadku limit\u00f3w procesora (np. 2 vCPU) ustawiam <em>worker_processes<\/em> odpowiednio, aby harmonogramowanie nie powodowa\u0142o sztucznego spieszenia. W przypadku sieci lokalnych korzystam z tryb\u00f3w sieciowych \u201ehost\u201c, kt\u00f3re charakteryzuj\u0105 si\u0119 mniejszym op\u00f3\u017anieniem zwi\u0105zanym z obci\u0105\u017ceniem, podczas gdy sieci nak\u0142adkowe oznaczaj\u0105 dodatkowe przeskoki. Na hostach Multi-NUMA zwracam uwag\u0119 na powinowactwo i gniazda pami\u0119ci, aby procesy robocze nie dzia\u0142a\u0142y w r\u00f3\u017cnych w\u0119z\u0142ach. To samo dotyczy powinowactwa IRQ oraz RPS\/XPS: je\u015bli \u015bcie\u017cki od karty sieciowej przez IRQ a\u017c do j\u0105dra procesu roboczego s\u0105 sp\u00f3jne, szczytowe op\u00f3\u017anienia zmniejszaj\u0105 si\u0119 w wymierny spos\u00f3b.<\/p>\n\n<h2>Cykl \u017cycia po\u0142\u0105cze\u0144: porty efemeryczne, stan TIME_WAIT i rezerwy<\/h2>\n<p>Planuj\u0119 wystarczaj\u0105c\u0105 ilo\u015b\u0107 <strong>porty tymczasowe<\/strong> (ip_local_port_range), gdy NGINX dzia\u0142a jako aktywny klient w stosunku do serwer\u00f3w upstream. Przy bardzo wysokiej przepustowo\u015bci po\u0142\u0105cze\u0144 unikam nadmiernych zmian port\u00f3w dzi\u0119ki funkcji Upstream-Keepalive, co pozwala zmniejszy\u0107 stosy TIME_WAIT. Z opcji j\u0105dra dotycz\u0105cych \u201eponownego wykorzystania\u201c korzystam tylko ostro\u017cnie; nowoczesne stosy sieciowe ju\u017c teraz optymalizuj\u0105 wiele proces\u00f3w wewn\u0119trznie. Bardziej stabilnym rozwi\u0105zaniem jest kontrolowanie czasu trwania po\u0142\u0105cze\u0144 za pomoc\u0105 rozs\u0105dnych warto\u015bci keepalive i timeout oraz <em>reuseport<\/em> wykorzysta\u0107 to do sprawiedliwego podzia\u0142u. Przy obliczaniu przepustowo\u015bci zawsze bior\u0119 pod uwag\u0119 nie tylko klient\u00f3w, ale tak\u017ce stron\u0119 upstream \u2013 cz\u0119sto to w\u0142a\u015bnie tam FD stanowi\u0105 rzeczywisty czynnik ograniczaj\u0105cy, a nie frontdoor.<\/p>\n\n<h2>P\u0142ynne prze\u0142adowywanie i wdra\u017canie bez przerw w dzia\u0142aniu<\/h2>\n<p>Korzystam z modelu master\/worker do <strong>p\u0142ynne prze\u0142adowania<\/strong>: Master \u0142aduje nowe konfiguracje, stare worker\u2019y wy\u0142\u0105czaj\u0105 si\u0119, a nowe p\u0142ynnie przejmuj\u0105 ich zadania. Dzi\u0119ki <em>worker_shutdown_timeout<\/em> daj\u0119 \u017c\u0105daniom czas na prawid\u0142owe zako\u0144czenie, bez blokowania zasob\u00f3w. Wdro\u017cenia bez przestoj\u00f3w w \u015brodowisku upstream \u0142\u0105cz\u0119 z kontrolami stanu i <em>proxy_next_upstream<\/em>-Zasady, dzi\u0119ki kt\u00f3rym pojedyncze, wadliwe komponenty zaplecza nie powoduj\u0105 wzrostu og\u00f3lnego op\u00f3\u017anienia. Wprowadzaj\u0105c zmiany w konfiguracji, zawsze modyfikuj\u0119 tylko jeden parametr i weryfikuj\u0119 efekty w logach oraz metrykach \u2013 w ten spos\u00f3b unikam b\u0142\u0119d\u00f3w wynikaj\u0105cych z niejasno\u015bci i zapewniam powtarzalno\u015b\u0107 wydajno\u015bci.<\/p>\n\n<h2>Zwi\u0119z\u0142e podsumowanie<\/h2>\n<p>\u0141\u0105cz\u0119 <strong>worker_processes<\/strong> ustaw liczb\u0119 rdzeni (najlepiej automatycznie), dostosuj liczb\u0119 po\u0142\u0105cze\u0144 worker_connections do szczytowego obci\u0105\u017cenia i znacznie zwi\u0119ksz warto\u015b\u0107 rlimit_nofile wraz z limitami systemu operacyjnego. W bloku zdarze\u0144 korzystam z epoll i multi_accept, sprawdzam wszystko za pomoc\u0105 powtarzalnych test\u00f3w obci\u0105\u017ceniowych, a nast\u0119pnie dostosowuj\u0119 ustawienia ma\u0142ymi krokami. W przypadku obci\u0105\u017ce\u0144 proxy uwzgl\u0119dniam dodatkowe deskryptory i testuj\u0119 powinowactwo procesora, gdy obci\u0105\u017cenia s\u0105 sta\u0142e. R\u00f3\u017cnic\u0119 stanowi prawid\u0142owo skonfigurowany stos z odpowiednim j\u0105drem, szybkim wej\u015bciem\/wyj\u015bciem oraz sensownymi parametrami sieciowymi. W ten spos\u00f3b osi\u0105gam <strong>NGINX<\/strong> niezawodnie w zakresie wydajno\u015bci, jakiego wymagaj\u0105 zaawansowane strony internetowe i interfejsy API.<\/p>","protected":false},"excerpt":{"rendered":"<p>Dowiedz si\u0119, jak prawid\u0142owo skonfigurowa\u0107 procesy robocze NGINX i znacznie poprawi\u0107 wydajno\u015b\u0107 serwera WWW dzi\u0119ki ukierunkowanemu dostrajaniu NGINX.<\/p>","protected":false},"author":1,"featured_media":20707,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20714","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":"134","_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 Worker","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":"20707","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/20714","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/comments?post=20714"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/20714\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/20707"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=20714"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=20714"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=20714"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}