{"id":18056,"date":"2026-03-03T18:23:49","date_gmt":"2026-03-03T17:23:49","guid":{"rendered":"https:\/\/webhosting.de\/http-keepalive-timeout-server-performance-konfiguration\/"},"modified":"2026-03-03T18:23:49","modified_gmt":"2026-03-03T17:23:49","slug":"konfiguracja-wydajnosci-serwera-http-keepalive-timeout","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/http-keepalive-timeout-server-performance-konfiguration\/","title":{"rendered":"HTTP Keep-Alive Timeout: Optymalna konfiguracja dla wydajno\u015bci serwera"},"content":{"rendered":"<p>Skupiaj\u0105c si\u0119 na <strong>HTTP Keep-Alive Timeout<\/strong> Poka\u017c\u0119 ci, jak ustawi\u0107 czasy bezczynno\u015bci, aby po\u0142\u0105czenia by\u0142y ponownie wykorzystywane bez blokowania w\u0105tk\u00f3w. Wyja\u015bni\u0119 konkretne warto\u015bci, poka\u017c\u0119 typowe pu\u0142apki i przedstawi\u0119 wypr\u00f3bowane i przetestowane konfiguracje dla <strong>nginx<\/strong>, Apache i system operacyjny.<\/p>\n\n<h2>Punkty centralne<\/h2>\n<ul>\n  <li><strong>R\u00f3wnowaga<\/strong>Zbyt kr\u00f3tki zwi\u0119ksza liczb\u0119 u\u015bcisk\u00f3w d\u0142oni, zbyt d\u0142ugi blokuje w\u0105tki.<\/li>\n  <li><strong>Warto\u015bci<\/strong>Przewa\u017cnie 5-15 s i 100-500 \u017c\u0105da\u0144 na po\u0142\u0105czenie.<\/li>\n  <li><strong>Koordynacja<\/strong>Koordynacja limit\u00f3w czasu klienta, LB i zapory sieciowej.<\/li>\n  <li><strong>Przypadki szczeg\u00f3lne<\/strong>WebSockets, SSE, Long Polling oddzielnie.<\/li>\n  <li><strong>Monitoring<\/strong>Monitorowanie otwartych gniazd, FD i op\u00f3\u017anie\u0144.<\/li>\n<\/ul>\n\n<h2>Kr\u00f3tkie wyja\u015bnienie HTTP Keep-Alive<\/h2>\n<p>Utrzymuj\u0119 po\u0142\u0105czenia TCP z <strong>Keep-Alive<\/strong> aby kilka \u017c\u0105da\u0144 korzysta\u0142o z tej samej linii. Oszcz\u0119dza to powtarzaj\u0105cych si\u0119 uzgodnie\u0144 TCP i TLS i zmniejsza obci\u0105\u017cenie sieci. <strong>CPU<\/strong>-zauwa\u017calnie. Jest to szczeg\u00f3lnie korzystne w przypadku wielu ma\u0142ych plik\u00f3w, takich jak ikony, JSON lub CSS. Ka\u017cde nowe po\u0142\u0105czenie, kt\u00f3rego uda\u0142o si\u0119 unikn\u0105\u0107, zmniejsza liczb\u0119 prze\u0142\u0105cze\u0144 kontekstu i odci\u0105\u017ca procedury j\u0105dra. W testach por\u00f3wnawczych z wysokim udzia\u0142em GET, og\u00f3lny czas trwania jest znacznie skr\u00f3cony, poniewa\u017c generowanych jest mniej pakiet\u00f3w SYN\/ACK, a wi\u0119cej czasu obliczeniowego przep\u0142ywa do logiki aplikacji.<\/p>\n<p>Szybko mierz\u0119 efekt: \u015brednie ruchome op\u00f3\u017anienia staj\u0105 si\u0119 p\u0142ynniejsze, a liczba nowych po\u0142\u0105cze\u0144 TCP na sekund\u0119 spada. Nie osi\u0105gam tego za pomoc\u0105 magii, ale poprzez <strong>Ponowne u\u017cycie po\u0142\u0105czenia<\/strong> i rozs\u0105dne limity. Wa\u017cne jest, aby Keep-Alive nie zast\u0119powa\u0142o szybkiego renderowania lub buforowania. Skraca czas oczekiwania na granicy sieci, podczas gdy sama aplikacja musi nadal reagowa\u0107 wydajnie. Oba te czynniki razem zwi\u0119kszaj\u0105 <strong>Wydajno\u015b\u0107<\/strong> zauwa\u017calnie.<\/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\/03\/server-optimierung-4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Zrozumienie w\u0142a\u015bciwego limitu czasu<\/h2>\n<p>Limit czasu okre\u015bla, jak d\u0142ugo nieaktywne po\u0142\u0105czenie pozostaje otwarte, zanim serwer je zamknie. <strong>zamkni\u0119cia<\/strong>. Je\u015bli ustawi\u0119 zbyt kr\u00f3tki czas, klienci b\u0119d\u0105 stale otwiera\u0107 nowe po\u0142\u0105czenia TCP, co <strong>Nad g\u0142ow\u0105<\/strong> jest podniesiony. Je\u015bli ustawi\u0119 go zbyt d\u0142ugo, bezczynne po\u0142\u0105czenia zaparkuj\u0105 cennych pracownik\u00f3w lub w\u0105tki. Sztuka polega na r\u00f3wnowadze mi\u0119dzy ponownym u\u017cyciem a zu\u017cyciem zasob\u00f3w. Testuj\u0119 praktycznie: najpierw ustawiam go z grubsza, a nast\u0119pnie dostosowuj\u0119 za pomoc\u0105 test\u00f3w obci\u0105\u017cenia.<\/p>\n<p>Zwracam r\u00f3wnie\u017c uwag\u0119 na zwi\u0105zek mi\u0119dzy czasem odpowiedzi a bezczynnymi oknami. Je\u015bli typowa interakcja u\u017cytkownika mi\u0119dzy dwoma klikni\u0119ciami wynosi 2-4 sekundy, limit czasu 5-15 sekund zwykle obejmuje rzeczywisty wzorzec. Kr\u00f3tkie wywo\u0142ania API mog\u0105 z \u0142atwo\u015bci\u0105 tolerowa\u0107 5-10 sekund, obci\u0105\u017cenia medialne 10-15 sekund. Wa\u017cne jest, aby nie przesadzi\u0107: zbyt d\u0142ugie timeouty rzadko prowadz\u0105 do wi\u0119cej <strong>Przepustowo\u015b\u0107<\/strong>, ale cz\u0119sto prowadz\u0105 do zablokowania <strong>Zasoby<\/strong>. Mog\u0119 to szybko rozpozna\u0107 po rosn\u0105cej liczbie otwartych gniazd i wysokich warto\u015bciach FD.<\/p>\n\n<h2>Czyste rozdzielenie typ\u00f3w limit\u00f3w czasu<\/h2>\n<p>Rzecznie rozr\u00f3\u017cniam mi\u0119dzy <strong>Limit czasu bezczynno\u015bci<\/strong> (Keep-Alive), <strong>Limit czasu odczytu\/nag\u0142\u00f3wka<\/strong> (jak d\u0142ugo serwer czeka na przychodz\u0105ce \u017c\u0105dania) i <strong>Limit czasu wysy\u0142ania\/zapisu<\/strong> (jak d\u0142ugo wysy\u0142anie w kierunku klienta jest tolerowane). Kategorie te spe\u0142niaj\u0105 r\u00f3\u017cne zadania:<\/p>\n<ul>\n  <li><strong>Limit czasu bezczynno\u015bci:<\/strong> Kontroluje ponowne u\u017cycie i czas parkowania nieaktywnych po\u0142\u0105cze\u0144.<\/li>\n  <li><strong>Limit czasu odczytu\/nag\u0142\u00f3wka:<\/strong> Chroni przed powolnymi klientami (slow lorises) i po\u0142owicznie wys\u0142anymi nag\u0142\u00f3wkami.<\/li>\n  <li><strong>Limit czasu wysy\u0142ania\/zapisu:<\/strong> Zapobiega nieko\u0144cz\u0105cemu si\u0119 oczekiwaniu serwera na powolny odbi\u00f3r u klienta.<\/li>\n<\/ul>\n<p>Na stronie <strong>nginx<\/strong> Celowo u\u017cywam header_timeout\/read_timeout i send_timeout na kontekst (http\/serwer\/lokalizacja) opr\u00f3cz keepalive_timeout. Od nowszych wersji opcjonalnie ustawiam <strong>keepalive_time<\/strong>, aby ograniczy\u0107 maksymalny czas \u017cycia po\u0142\u0105czenia, nawet je\u015bli pozostaje ono aktywne. W <strong>Apacz<\/strong> U\u017cywam r\u00f3wnie\u017c <strong>RequestReadTimeout<\/strong> (mod_reqtimeout) i sprawdzi\u0107 <strong>Limit czasu<\/strong> (globalny) oddzielony od <strong>KeepAliveTimeout<\/strong>. Oddzielenie to jest wa\u017cnym elementem zapobiegaj\u0105cym wi\u0105zaniu zasob\u00f3w bez \u017cadnych realnych korzy\u015bci.<\/p>\n\n<h2>Zalecane warto\u015bci w praktyce<\/h2>\n<p>Dla wydajnych \u015brodowisk ustawiam limit czasu utrzymania po\u0142\u0105czenia na 5-15 sekund i 100-500 \u017c\u0105da\u0144 na po\u0142\u0105czenie. Zakres ten zapewnia dobre wska\u017aniki ponownego wykorzystania po\u0142\u0105cze\u0144 i utrzymuje liczb\u0119 nieaktywnych po\u0142\u0105cze\u0144 na niskim poziomie. Na <strong>nginx<\/strong> U\u017cywam keepalive_timeout 10s jako warto\u015bci pocz\u0105tkowej i keepalive_requests 200. Je\u015bli ruch jest du\u017cy, zwi\u0119kszam go umiarkowanie, je\u015bli widz\u0119 zbyt wiele nowych po\u0142\u0105cze\u0144 TCP. Je\u015bli ruch jest niewielki, ponownie obni\u017cam t\u0119 warto\u015b\u0107, aby unikn\u0105\u0107 zalewu bezczynnego ruchu.<\/p>\n<p>Ci, kt\u00f3rzy wchodz\u0105 g\u0142\u0119biej, skorzystaj\u0105 z jasnego procesu dostrajania z punktami pomiarowymi. W tym celu podsumowuj\u0119 moje wytyczne w praktycznym przewodniku, kt\u00f3ry opisuje \u015bcie\u017ck\u0119 od pomiaru przez konfiguracj\u0119 do kontroli. Aby szybko rozpocz\u0105\u0107, odsy\u0142am do moich krok\u00f3w w <a href=\"https:\/\/webhosting.de\/pl\/http-keep-alive-tuning-obciazenie-serwera-optymalizacja-wydajnosci-przeplyw\/\">Optymalizacja Keep-Alive<\/a>. Jak kontrolowa\u0107 <strong>Ponowne u\u017cycie<\/strong> i unikn\u0105\u0107 niespodzianek. Ostatecznie licz\u0105 si\u0119 niskie op\u00f3\u017anienia i stabilno\u015b\u0107. <strong>Przepustowo\u015b\u0107<\/strong>.<\/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\/03\/http-keep-alive-optimierung-1723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ryzyko zwi\u0105zane z d\u0142ugimi limitami czasu<\/h2>\n<p>D\u0142ugi limit czasu sprawia, \u017ce po\u0142\u0105czenia s\u0105 sztuczne <strong>otwarty<\/strong> i blokuje pracownik\u00f3w, nawet je\u015bli nie nast\u0119puje \u017cadne \u017c\u0105danie. Powoduje to p\u0119cznienie gniazd i zwi\u0119ksza liczb\u0119 deskryptor\u00f3w plik\u00f3w. Je\u015bli proces osi\u0105gnie swoje limity, widz\u0119 odrzucanie b\u0142\u0119d\u00f3w akceptacji lub kolejki podczas nawi\u0105zywania po\u0142\u0105czenia. Pami\u0119\u0107 ro\u015bnie, garbage collectory lub alokatory kosztuj\u0105 dodatkowy czas, a op\u00f3\u017anienie wzrasta. W przypadku b\u0142\u0119du, klienci wysy\u0142aj\u0105 nast\u0119pnie do gniazd, kt\u00f3re s\u0105 ju\u017c zamkni\u0119te i otrzymuj\u0105 kryptowalut\u0119 <strong>B\u0142\u0105d<\/strong>.<\/p>\n<p>Unikam tego, ustawiaj\u0105c umiarkowane warto\u015bci i regularnie sprawdzaj\u0105c metryki. Je\u015bli liczba bezczynnych po\u0142\u0105cze\u0144 zbytnio wzrasta przy niskim obci\u0105\u017ceniu, obni\u017cam limit czasu. Je\u015bli widz\u0119 wiele nowych po\u0142\u0105cze\u0144 na sekund\u0119 podczas szczyt\u00f3w ruchu, ostro\u017cnie zwi\u0119kszam go ma\u0142ymi krokami. W ten spos\u00f3b utrzymuj\u0119 <strong>Pojemno\u015b\u0107<\/strong> U\u017cyteczno\u015b\u0107 i zapobieganie martwym po\u0142\u0105czeniom. Rezultatem jest p\u0142ynniejszy system z mniejsz\u0105 liczb\u0105 <strong>Wskaz\u00f3wki<\/strong> na zakr\u0119tach.<\/p>\n\n<h2>Konfiguracja: nginx, Apache i warstwa systemu operacyjnego<\/h2>\n<p>Zaczynam na poziomie serwera WWW i ustawiam limit czasu i limity. Na <strong>nginx<\/strong> Ustawiam keepalive_timeout 5-15s i keepalive_requests 100-500. W Apache z event-MPM \u0142\u0105cz\u0119 KeepAlive On, KeepAliveTimeout 5-15 i MaxKeepAliveRequests 100-500. Nast\u0119pnie kalibruj\u0119 worker lub pule w\u0105tk\u00f3w zgodnie z oczekiwanym obci\u0105\u017ceniem. Zapobiega to produktywno\u015bci bezczynnych keep-alives. <strong>Automaty do gry<\/strong> wi\u0105zanie.<\/p>\n<p>Zwi\u0119kszam limity i kolejki na poziomie systemu operacyjnego. Ustawiam ulimit -n na co najmniej 100 000, dostosowuj\u0119 net.core.somaxconn i tcp_max_syn_backlog i sprawdzam obs\u0142ug\u0119 TIME_WAIT. Zapewnia to, \u017ce j\u0105dro i proces maj\u0105 wystarczaj\u0105co du\u017co <strong>Zasoby<\/strong> zapewni\u0107. Na koniec weryfikuj\u0119 \u015bcie\u017cki z karty sieciowej poprzez r\u00f3wnowa\u017cenie IRQ do aplikacji. Pozwala mi to na rozpoznanie w\u0105skich garde\u0142 w odpowiednim czasie i utrzymanie <strong>Op\u00f3\u017anienie<\/strong> niski.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Komponent<\/th>\n      <th>Dyrektywa\/Ustawienie<\/th>\n      <th>Zalecenie<\/th>\n      <th>Wskaz\u00f3wka<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>nginx<\/td>\n      <td>keepalive_timeout<\/td>\n      <td>5\u201315 s<\/td>\n      <td><strong>Kr\u00f3tszy<\/strong> przy ma\u0142ym ruchu, d\u0142u\u017cej przy wielu ma\u0142ych \u017c\u0105daniach<\/td>\n    <\/tr>\n    <tr>\n      <td>nginx<\/td>\n      <td>keepalive_requests<\/td>\n      <td>100\u2013500<\/td>\n      <td>Recykling zwi\u0105zk\u00f3w i redukcja <strong>Wycieki<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Apache (zdarzenie)<\/td>\n      <td>KeepAliveTimeout<\/td>\n      <td>5\u201315 s<\/td>\n      <td>Event-MPM zarz\u0105dza bezczynno\u015bci\u0105 bardziej efektywnie ni\u017c <strong>prefork<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>System operacyjny<\/td>\n      <td>ulimit -n<\/td>\n      <td>\u2265 100.000<\/td>\n      <td>Wi\u0119cej otwartych FD dla wielu <strong>Gniazda<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>System operacyjny<\/td>\n      <td>net.core.somaxconn<\/td>\n      <td>Wzrost<\/td>\n      <td>Mniej odrzuconych po\u0142\u0105cze\u0144 pod <strong>Obci\u0105\u017cenie szczytowe<\/strong><\/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\/03\/server-optimization-http-keep-alive-4317.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Odwrotne proxy i ponowne wykorzystanie upstream<\/h2>\n<p>Zawsze my\u015bl\u0119, \u017ce keep-alive <strong>end-to-end<\/strong>. Za serwerem brzegowym cz\u0119sto znajduje si\u0119 \u0142a\u0144cuch reverse proxy \u2192 serwery aplikacji. W przypadku nginx aktywuj\u0119 w\u0142asny <strong>Baseny Keep Alive<\/strong> (upstream keepalive, keepalive_requests, keepalive_timeout), ustawi\u0107 proxy_http_version 1.1 i usun\u0105\u0107 \u201eConnection: close\u201c. To r\u00f3wnie\u017c oszcz\u0119dza mi <em>wewn\u0119trzny<\/em> handshake i odci\u0105\u017canie backend\u00f3w aplikacji (Node.js, Java, PHP-FPM). W Apache z mod_proxy utrzymuj\u0119 r\u00f3wnie\u017c trwa\u0142e po\u0142\u0105czenia z serwerami zaplecza i ograniczam je na miejsce docelowe, aby hotspot nie zmonopolizowa\u0142 puli.<\/p>\n<p>Mierz\u0119 osobno: wska\u017anik ponownego u\u017cycia Klient\u2192Edge i Edge\u2192Backend. Je\u015bli widz\u0119 dobre ponowne u\u017cycie na kraw\u0119dzi, ale wiele nowych po\u0142\u0105cze\u0144 z backendem, selektywnie zwi\u0119kszam pule upstream. Pozwala mi to na skalowanie bez globalnego zwi\u0119kszania limit\u00f3w czasu frontendu.<\/p>\n\n<h2>Pracownicy, w\u0105tki i limity systemu operacyjnego<\/h2>\n<p>Nie wymiaruj\u0119 pracownik\u00f3w, zdarze\u0144 i w\u0105tk\u00f3w wed\u0142ug po\u017c\u0105danych warto\u015bci, ale wed\u0142ug <strong>profil obci\u0105\u017cenia<\/strong>. Aby to zrobi\u0107, monitoruj\u0119 aktywne \u017c\u0105dania, bezczynnych pracownik\u00f3w, wykorzystanie p\u0119tli zdarze\u0144 i prze\u0142\u0105czniki kontekstu. Je\u015bli w\u0105tki s\u0105 zaparkowane w trybie bezczynno\u015bci, obni\u017cam limit czasu lub maksymalny czas bezczynno\u015bci na w\u0105tek. Je\u015bli widz\u0119 100 procent CPU przez ca\u0142y czas, sprawdzam kolejki akceptacji, dystrybucj\u0119 IRQ i stos sieciowy. Niewielkie korekty limit\u00f3w FD i zaleg\u0142o\u015bci cz\u0119sto robi\u0105 du\u017c\u0105 r\u00f3\u017cnic\u0119. <strong>Efekty<\/strong>.<\/p>\n<p>Planuj\u0119 headroom realistycznie. Rezerwa 20-30 procent w w\u0105tkach i FD zapewnia bezpiecze\u0144stwo w przypadku szczyt\u00f3w. Je\u015bli przesadz\u0119, strac\u0119 pami\u0119\u0107 podr\u0119czn\u0105 i zwi\u0119kszy si\u0119 marnotrawstwo. Je\u015bli go nie wykorzystam, \u017c\u0105dania wyl\u0105duj\u0105 w kolejkach lub wygasn\u0105. W\u0142a\u015bciwe przeci\u0119cie <strong>Pojemno\u015b\u0107<\/strong> i wydajno\u015b\u0107 utrzymuje op\u00f3\u017anienia na niskim poziomie i chroni <strong>Stabilno\u015b\u0107<\/strong>.<\/p>\n\n<h2>Koordynacja limit\u00f3w czasu klienta, load balancera i firewalla<\/h2>\n<p>Ustawi\u0142em limity czasowe na ca\u0142ej \u015bcie\u017cce, aby nie by\u0142o \u015blepych zau\u0142k\u00f3w. <strong>Po\u0142\u0105czenia<\/strong> s\u0105 tworzone. Klienci idealnie zamykaj\u0105 si\u0119 minimalnie wcze\u015bniej ni\u017c serwer. Load balancer nie mo\u017ce odci\u0105\u0107 kr\u00f3tszego czasu, w przeciwnym razie zobacz\u0119 nieoczekiwane resety. Uwzgl\u0119dniam warto\u015bci bezczynno\u015bci NAT i firewalla, aby po\u0142\u0105czenia nie by\u0142y tracone na \u015bcie\u017cce sieciowej. <strong>znikn\u0105\u0107<\/strong>. Strojenie to zapobiega retransmisjom i wyg\u0142adza krzywe obci\u0105\u017cenia.<\/p>\n<p>U\u017cywam przejrzystych diagram\u00f3w, aby \u0142a\u0144cuch by\u0142 zrozumia\u0142y: Klient \u2192 LB \u2192 serwer WWW \u2192 aplikacja. Dokumentuj\u0119 czasy bezczynno\u015bci, czasy odczytu\/zapisu i strategie ponawiania dla ka\u017cdego \u0142\u0105cza. Je\u015bli zmieniam warto\u015b\u0107, sprawdzam s\u0105siad\u00f3w. Dzi\u0119ki temu \u015bcie\u017cka jest sp\u00f3jna, a wyniki pomiar\u00f3w powtarzalne. Taka dyscyplina oszcz\u0119dza czas w <strong>Rozwi\u0105zywanie problem\u00f3w<\/strong> i zwi\u0119ksza <strong>niezawodno\u015b\u0107<\/strong>.<\/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\/03\/optimal_configuration_server_9837.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bezpiecze\u0144stwo: Ochrona przed powolnymi lorisami i bezczynnymi nadu\u017cyciami<\/h2>\n<p>Otwarte limity czasu, kt\u00f3re s\u0105 zbyt hojne <strong>Powierzchnie ataku<\/strong>. Dlatego ustawiam limity, kt\u00f3re pozwalaj\u0105 na legalne ponowne u\u017cycie, ale utrudniaj\u0105 z\u0142o\u015bliwe utrzymywanie ich otwartych. W nginx pomagaj\u0105 limity header i read_timeout, request_headers_size i twardy g\u00f3rny limit dla keepalive_requests. W Apache u\u017cywam mod_reqtimeout i ograniczam r\u00f3wnoleg\u0142e po\u0142\u0105czenia na IP. Limity szybko\u015bci i <strong>limit_conn<\/strong> w nginx r\u00f3wnie\u017c chroni\u0105 przed zalewem wielu bezczynnych gniazd. W przypadku d\u0142ugo dzia\u0142aj\u0105cych punkt\u00f3w ko\u0144cowych oddzielam dedykowane pule, aby ataki na strumienie nie wi\u0105za\u0142y zwyk\u0142ych pracownik\u00f3w API.<\/p>\n\n<h2>Przypadki szczeg\u00f3lne: Long Polling, SSE i WebSockets<\/h2>\n<p>D\u0142ugie strumienie zderzaj\u0105 si\u0119 z kr\u00f3tkimi <strong>Limity czasu<\/strong> i potrzebuj\u0105 w\u0142asnych regu\u0142. Technicznie oddzielam te punkty ko\u0144cowe od klasycznego API i tras zasob\u00f3w. Dla SSE i WebSockets ustawiam wy\u017csze limity czasu, dedykowane pule pracownik\u00f3w i twarde limity na IP. Utrzymuj\u0119 po\u0142\u0105czenie przy \u017cyciu za pomoc\u0105 heartbeat\u00f3w lub ping\/pong i szybko rozpoznaj\u0119 roz\u0142\u0105czenia. W ten spos\u00f3b strumienie nie blokuj\u0105 w\u0105tk\u00f3w dla regularnych <strong>Kr\u00f3tkie pro\u015bby<\/strong>.<\/p>\n<p>Ograniczam jednoczesne po\u0142\u0105czenia i aktywnie je mierz\u0119. Zbyt wysokie limity zu\u017cywaj\u0105 FD i RAM. Zbyt niskie limity odcinaj\u0105 legalnych u\u017cytkownik\u00f3w. Znajduj\u0119 najlepsze miejsce z czystymi metrykami dla otwartych, bezczynnych, aktywnych i zerwanych po\u0142\u0105cze\u0144. Ta separacja oszcz\u0119dza mi globalnego <strong>Zwi\u0119kszenia<\/strong> limit\u00f3w czasu i chroni <strong>Pojemno\u015b\u0107<\/strong>.<\/p>\n\n<h2>HTTP\/2, multipleksowanie i keep-alive<\/h2>\n<p>HTTP\/2 multipleksuje kilka strumieni za po\u015brednictwem protoko\u0142u <strong>Po\u0142\u0105czenie<\/strong>, ale pozostaje zale\u017cny od timeout\u00f3w. Utrzymuj\u0119 umiarkowane okno bezczynno\u015bci, poniewa\u017c sesje mog\u0105 r\u00f3wnie\u017c parkowa\u0107 pod HTTP\/2. Wysokie keepalive_requests s\u0105 tutaj mniej wa\u017cne, ale recykling pozostaje przydatny. Blokowanie Head-of-Line przenosi si\u0119 na poziom ramki, wi\u0119c nadal mierz\u0119 op\u00f3\u017anienie per <strong>Strumie\u0144<\/strong>. Wi\u0119cej szczeg\u00f3\u0142owych informacji na temat por\u00f3wnania mo\u017cna znale\u017a\u0107 na stronie <a href=\"https:\/\/webhosting.de\/pl\/http2-multipleksowanie-vs-http11-wydajnosc-tlo-optymalizacja\/\">Multipleksowanie HTTP\/2<\/a>.<\/p>\n<p>W HTTP\/2 zwracam szczeg\u00f3ln\u0105 uwag\u0119 na liczb\u0119 aktywnych strumieni na po\u0142\u0105czenie. Zbyt wiele r\u00f3wnoleg\u0142ych strumieni mo\u017ce przeci\u0105\u017cy\u0107 w\u0105tki aplikacji. Nast\u0119pnie spowalniam limity lub zwi\u0119kszam liczb\u0119 pracownik\u00f3w serwera. To samo dotyczy tutaj: zmierz, dostosuj, zmierz ponownie. Pozwala to utrzyma\u0107 <strong>Czasy reakcji<\/strong> rzadkie i zachowane <strong>Zasoby<\/strong>.<\/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\/03\/dev_desk_HTTP_timeout_4783.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>TLS, wznawianie sesji i HTTP\/3\/QUIC<\/h2>\n<p>U\u015bciski d\u0142oni TLS s\u0105 drogie. U\u017cywam <strong>Wznowienie sesji<\/strong> (bilety\/identyfikatory) i zszywanie OCSP, dzi\u0119ki czemu ponowne po\u0142\u0105czenia s\u0105 szybsze w przypadku zako\u0144czenia po\u0142\u0105czenia. W protokole HTTP\/3, QUIC przejmuje warstw\u0119 transportow\u0105: w tym przypadku <strong>Limit czasu bezczynno\u015bci QUIC<\/strong> podobny do Keep-Alive, ale na bazie UDP. Tutaj r\u00f3wnie\u017c utrzymuj\u0119 umiarkowane okna i mierz\u0119 retransmisje, poniewa\u017c utrata pakiet\u00f3w ma inny wp\u0142yw ni\u017c w przypadku TCP. W przypadku \u015brodowisk mieszanych (H1\/H2\/H3) wybieram znormalizowane warto\u015bci referencyjne i dokonuj\u0119 drobnych korekt dla ka\u017cdego protoko\u0142u.<\/p>\n\n<h2>Monitorowanie, metryki i testy obci\u0105\u017cenia<\/h2>\n<p>Ufam danym pomiarowym bardziej ni\u017c przeczuciom i zaczynam od jasnych danych. <strong>KPI<\/strong>. Wa\u017cne s\u0105: otwarte gniazda, wykorzystanie FD, nowe po\u0142\u0105czenia\/s, op\u00f3\u017anienia (P50\/P90\/P99), stopy b\u0142\u0119d\u00f3w i retransmisje. Uruchamiam realistyczne profile obci\u0105\u017cenia: Warmup, plateau, ramp-down. Nast\u0119pnie por\u00f3wnuj\u0119 krzywe przed i po zmianie limitu czasu. Spojrzenie na <a href=\"https:\/\/webhosting.de\/pl\/serwer-www-kolejkowanie-opoznienie-obsluga-zadan-kolejka-serwera\/\">Kolejkowanie serwer\u00f3w<\/a> pomaga w jasnej interpretacji czas\u00f3w oczekiwania.<\/p>\n<p>Dokumentuj\u0119 ka\u017cd\u0105 regulacj\u0119 za pomoc\u0105 znacznika czasu i zmierzonych warto\u015bci. Pozwala mi to zachowa\u0107 histori\u0119 i rozpozna\u0107 korelacje. Powa\u017cnie traktuj\u0119 negatywne efekty i szybko je cofam. Ma\u0142e, zrozumia\u0142e kroki oszcz\u0119dzaj\u0105 du\u017co czasu. Ostatecznie liczy si\u0119 stabilno\u015b\u0107 <strong>Op\u00f3\u017anienie<\/strong> i niski <strong>Wska\u017anik b\u0142\u0119d\u00f3w<\/strong> pod obci\u0105\u017ceniem.<\/p>\n\n<h2>Metody i narz\u0119dzia pomiarowe w praktyce<\/h2>\n<ul>\n  <li><strong>Szybkie testy:<\/strong> U\u017cywam narz\u0119dzi takich jak wrk, ab lub vegeta do sprawdzania kwot ponownego u\u017cycia (po\u0142\u0105czenie -H: keep-alive vs. close), po\u0142\u0105cze\u0144\/s i percentyli op\u00f3\u017anie\u0144.<\/li>\n  <li><strong>Widok systemu:<\/strong> ss\/netstat pokazuje statusy (ESTABLISHED, TIME_WAIT), lsof -p zu\u017cycie FD, dmesg\/syslog wskazuje spadki.<\/li>\n  <li><strong>Metryki serwera WWW:<\/strong> nginx stub_status\/VTS i Apache mod_status dostarczaj\u0105 aktywnych\/nieaktywnych\/oczekuj\u0105cych i \u017c\u0105da\u0144\/s. Na tej podstawie mog\u0119 rozpozna\u0107 szczyty bezczynno\u015bci lub w\u0105skie gard\u0142a pracownik\u00f3w.<\/li>\n  <li><strong>\u015alady:<\/strong> U\u017cywam rozproszonego \u015bledzenia do monitorowania, czy czasy oczekiwania wyst\u0119puj\u0105 na granicy sieci, czy w aplikacji.<\/li>\n<\/ul>\n\n<h2>Konfiguracja krok po kroku<\/h2>\n<p>Najpierw okre\u015blam rzeczywisty wzorzec u\u017cycia: ile \u017c\u0105da\u0144 na sesj\u0119, kt\u00f3re <strong>Interwa\u0142y<\/strong> mi\u0119dzy klikni\u0119ciami, jak du\u017ce s\u0105 odpowiedzi. Nast\u0119pnie ustawiam pocz\u0105tkowy profil: timeout 10 s, keepalive_requests 200, umiarkowana liczba pracownik\u00f3w. Nast\u0119pnie przeprowadzam testy obci\u0105\u017cenia z reprezentatywnymi danymi. Oceniam liczb\u0119 nowych po\u0142\u0105cze\u0144 na sekund\u0119 i wykorzystanie FD. Nast\u0119pnie dostosowuj\u0119 <strong>Warto\u015bci<\/strong> w 2-3 sekundowych odst\u0119pach.<\/p>\n<p>Powtarzam ten cykl, a\u017c op\u00f3\u017anienia pozostan\u0105 stabilne pod obci\u0105\u017ceniem, a szczyty FD nie osi\u0105gn\u0105 limitu. Przy du\u017cym nat\u0119\u017ceniu ruchu zwi\u0119kszam limit czasu tylko wtedy, gdy wyra\u017anie widz\u0119 mniej nowych po\u0142\u0105cze\u0144, a pracownicy nadal pozostaj\u0105 wolni. Przy niskim wykorzystaniu zmniejszam limit czasu, aby unikn\u0105\u0107 bezczynno\u015bci. W szczeg\u00f3lnych przypadkach, takich jak SSE, ustawiam dedykowane bloki serwer\u00f3w z wy\u017cszymi limitami. Ta \u015bcie\u017cka prowadzi do odpornego <strong>Ustawienie<\/strong> bez tektury.<\/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\/03\/servereinstellung-performance-1987.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kubernetes, kontenery i automatyczne skalowanie<\/h2>\n<p>W \u015brodowiskach kontenerowych u\u017cywam <strong>conntrack<\/strong>-limity, limity pod FD i zaleg\u0142o\u015bci w\u0119z\u0142\u00f3w. Zapewniam sp\u00f3jne czasy bezczynno\u015bci mi\u0119dzy Ingress, siatk\u0105 us\u0142ug\/proxy i aplikacj\u0105. W przypadku automatycznego skalowania zwracam uwag\u0119 na <strong>Czasy odp\u0142ywu<\/strong>Gdy pody s\u0105 ko\u0144czone, powinny odrzuca\u0107 nowe po\u0142\u0105czenia poprzez \u201eConnection: close\u201c i czysto obs\u0142ugiwa\u0107 istniej\u0105ce. Zbyt d\u0142ugie warto\u015bci \"Keep alive\" niepotrzebnie wyd\u0142u\u017caj\u0105 drena\u017c, a zbyt kr\u00f3tkie generuj\u0105 burze uzgodnie\u0144 podczas skalowania.<\/p>\n\n<h2>Graceful shutdown i rolling deployments<\/h2>\n<p>Ja r\u00f3wnie\u017c planuj\u0119 si\u0119 wy\u0142\u0105czy\u0107. Przed wdro\u017ceniem stopniowo zmniejszam Keep-Alive lub wysy\u0142am ukierunkowane wiadomo\u015bci. <strong>Po\u0142\u0105czenie: zamknij<\/strong> w odpowiedziach, aby klienci nie otwierali nowych bezczynnych po\u0142\u0105cze\u0144. W nginx, a <strong>worker_shutdown_timeout<\/strong> dla uruchomionych \u017c\u0105da\u0144. W Apache u\u017cywam mechanizm\u00f3w graceful i pilnuj\u0119 MaxConnectionsPerChild\/Worker, aby recykling odbywa\u0142 si\u0119 automatycznie w czasie. Zapewnia to p\u0142ynno\u015b\u0107 wdro\u017ce\u0144 bez twardego ograniczania otwartych gniazd.<\/p>\n\n<h2>Dostrajanie systemu operacyjnego: porty, timeouty, parametry j\u0105dra<\/h2>\n<ul>\n  <li><strong>porty efemeryczne:<\/strong> Wybierz szeroki zakres dla ip_local_port_range, aby kr\u00f3tkotrwa\u0142e po\u0142\u0105czenia nie napotyka\u0142y na niedobory.<\/li>\n  <li><strong>TIME_WAIT:<\/strong> Obserwuj\u0119 szczyty TW. Nowoczesne stosy dobrze sobie z tym radz\u0105; unikam podejrzanych tweak\u00f3w (tw_recycle).<\/li>\n  <li><strong>tcp_keepalive_time:<\/strong> Nie myl\u0119 tego z HTTP Keep-Alive. Jest to mechanizm j\u0105dra do rozpoznawania martwych peer\u00f3w - przydatny za NAT, ale nie zast\u0119puj\u0105cy okna bezczynno\u015bci HTTP.<\/li>\n  <li><strong>Zaleg\u0142o\u015bci i bufory:<\/strong> wymiar somaxconn, tcp_max_syn_backlog i rmem\/wmem rozs\u0105dnie, aby nie d\u0142awi\u0107 si\u0119 pod obci\u0105\u017ceniem.<\/li>\n<\/ul>\n\n<h2>Lista kontrolna rozwi\u0105zywania problem\u00f3w<\/h2>\n<ul>\n  <li><strong>Wiele nowych po\u0142\u0105cze\u0144 pomimo keep-alive:<\/strong> Zbyt kr\u00f3tki limit czasu lub wcze\u015bniejsze odci\u0119cie klient\u00f3w\/LB.<\/li>\n  <li><strong>Wysokie warto\u015bci bezczynno\u015bci i pe\u0142ne FD:<\/strong> Zbyt d\u0142ugi limit czasu lub zbyt du\u017ce pule pracownik\u00f3w w stosunku do wzorca ruchu.<\/li>\n  <li><strong>B\u0142\u0105d RST\/Timeout dla d\u0142u\u017cszych sesji:<\/strong> NAT\/firewall na zbyt kr\u00f3tkiej \u015bcie\u017cce, asymetria mi\u0119dzy \u0142\u0105czami.<\/li>\n  <li><strong>Op\u00f3\u017anienia d\u0142ugiego ogona (P99):<\/strong> Sprawd\u017a limity czasu wysy\u0142ania\/odczytu, powolnych klient\u00f3w lub przepe\u0142nione zaleg\u0142o\u015bci.<\/li>\n  <li><strong>Backendy przeci\u0105\u017cone pomimo niskiego obci\u0105\u017cenia kraw\u0119dzi:<\/strong> Brak g\u00f3rnej klatki lub jest ona zbyt ma\u0142a.<\/li>\n<\/ul>\n\n<h2>Profile treningowe i warto\u015bci pocz\u0105tkowe<\/h2>\n<ul>\n  <li><strong>API-first (kr\u00f3tkie po\u0142\u0105czenia):<\/strong> Keep-Alive 5-10 s, keepalive_requests 200-300, \u015bcis\u0142e limity czasu nag\u0142\u00f3wka\/odczytu.<\/li>\n  <li><strong>Handel elektroniczny (mieszany):<\/strong> 8-12 s, 200-400, nieco wi\u0119cej w przypadku obraz\u00f3w produkt\u00f3w i buforowania trafie\u0144.<\/li>\n  <li><strong>Assets\/CDN-like (wiele ma\u0142ych plik\u00f3w):<\/strong> 10-15 s, 300-500, silny nurt i wysokie limity FD.<\/li>\n  <li><strong>Intranet\/niskie obci\u0105\u017cenie:<\/strong> 5-8 s, 100-200, aby nie dominowa\u0142a praca na biegu ja\u0142owym.<\/li>\n<\/ul>\n\n<h2>Kr\u00f3tkie podsumowanie<\/h2>\n<p>Ustawi\u0142em limit czasu HTTP keep-alive, aby po\u0142\u0105czenia by\u0142y ponownie wykorzystywane bez blokowania w\u0105tk\u00f3w. W praktyce, 5-15 sekund i 100-500 \u017c\u0105da\u0144 na po\u0142\u0105czenie zapewniaj\u0105 bardzo dobre wyniki. Koordynuj\u0119 limity czasu klienta, load balancera i firewalla, oddzielam d\u0142ugo dzia\u0142aj\u0105ce po\u0142\u0105czenia, takie jak WebSockets i reguluj\u0119 limity systemu operacyjnego. Dzi\u0119ki czystemu monitorowaniu, realistycznym testom obci\u0105\u017cenia i ma\u0142ym krokom, osi\u0105gam niskie wyniki. <strong>Op\u00f3\u017anienia<\/strong> i wysoki <strong>Przepustowo\u015b\u0107<\/strong>. Ci, kt\u00f3rzy utrzymuj\u0105 t\u0119 dyscyplin\u0119, uzyskuj\u0105 wymiern\u0105 wydajno\u015b\u0107 z istniej\u0105cego sprz\u0119tu.<\/p>","protected":false},"excerpt":{"rendered":"<p>Zoptymalizowane ustawienia czasu oczekiwania HTTP dla lepszej wydajno\u015bci serwera. Praktyczny przewodnik po tuningu serwera WWW i zarz\u0105dzaniu po\u0142\u0105czeniami.<\/p>","protected":false},"author":1,"featured_media":18049,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-18056","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":"844","_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":"HTTP Keep-Alive Timeout","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":"18049","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/18056","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=18056"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/18056\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/18049"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=18056"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=18056"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=18056"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}