{"id":18433,"date":"2026-03-26T18:39:08","date_gmt":"2026-03-26T17:39:08","guid":{"rendered":"https:\/\/webhosting.de\/connection-limits-webhosting-serverlast-optimierungshub\/"},"modified":"2026-03-26T18:39:08","modified_gmt":"2026-03-26T17:39:08","slug":"limity-polaczen-webhosting-optymalizacja-obciazenia-serwera-hub","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/connection-limits-webhosting-serverlast-optimierungshub\/","title":{"rendered":"Limity po\u0142\u0105cze\u0144 w hostingu: optymalizacja jednoczesnych po\u0142\u0105cze\u0144 i obci\u0105\u017cenia serwera"},"content":{"rendered":"<p><strong>Limity po\u0142\u0105cze\u0144<\/strong> w hostingu internetowym, aby kontrolowa\u0107, ile jednoczesnych \u017c\u0105da\u0144 serwer mo\u017ce niezawodnie przetworzy\u0107, zanim wyst\u0105pi\u0105 op\u00f3\u017anienia i b\u0142\u0119dy. Poka\u017c\u0119 ci, jak mierzy\u0107 i optymalizowa\u0107 limity, jednoczesne po\u0142\u0105czenia i obci\u0105\u017cenie serwera oraz jak niezawodnie je kontrolowa\u0107 poprzez ukierunkowane strojenie.<\/p>\n\n<h2>Punkty centralne<\/h2>\n<p>Poni\u017csze kluczowe punkty stanowi\u0105 zwi\u0119z\u0142y przegl\u0105d tre\u015bci i korzy\u015bci p\u0142yn\u0105cych z tego artyku\u0142u.<\/p>\n<ul>\n  <li><strong>Ograniczenie<\/strong> Jednoczesne po\u0142\u0105czenia chroni\u0105 przed przeci\u0105\u017ceniem i komunikatami o b\u0142\u0119dach.<\/li>\n  <li><strong>Zasoby<\/strong> takie jak CPU, RAM i I\/O okre\u015blaj\u0105 efektywny limit.<\/li>\n  <li><strong>Strojenie<\/strong> z parametrami Sysctl, Nginx\/Apache i DB zwi\u0119ksza wydajno\u015b\u0107.<\/li>\n  <li><strong>Monitoring<\/strong> wcze\u015bnie rozpoznaje w\u0105skie gard\u0142a i zapobiega awariom.<\/li>\n  <li><strong>Skalowanie<\/strong> i buforowanie zmniejszaj\u0105 obci\u0105\u017cenie serwera podczas szczytowego ruchu.<\/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\/03\/serverraum-verbindungen-8356.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Co oznaczaj\u0105 limity po\u0142\u0105cze\u0144?<\/h2>\n\n<p>Limit po\u0142\u0105czenia ustawia <strong>warto\u015b\u0107 progowa<\/strong> dla liczby jednoczesnych po\u0142\u0105cze\u0144 TCP, kt\u00f3re host akceptuje, zanim nowe \u017c\u0105dania zostan\u0105 odrzucone lub umieszczone w kolejce. Za ka\u017cdym po\u0142\u0105czeniem kryje si\u0119 <strong>TCP<\/strong>-U\u015bcisk d\u0142oni, bufor i jednostka przetwarzania, kt\u00f3ra kosztuje zasoby. Bez limitu, system szybko przestaje dzia\u0142a\u0107 podczas szczyt\u00f3w lub zg\u0142asza \u201eOdmowa po\u0142\u0105czenia\u201c. W zale\u017cno\u015bci od j\u0105dra i konfiguracji, typowe warto\u015bci pocz\u0105tkowe wynosz\u0105 od 128 do 4096, co pozostaje zbyt niskie dla wielu projekt\u00f3w. Dlatego najpierw sprawdzam, ile otwartych gniazd, plik\u00f3w i proces\u00f3w system mo\u017ce niezawodnie obs\u0142u\u017cy\u0107, a nast\u0119pnie ustawiam limit, kt\u00f3ry zmniejsza szczyty obci\u0105\u017cenia, ale nie blokuje niepotrzebnie legalnego ruchu.<\/p>\n\n<h2>Jednoczesne po\u0142\u0105czenia i obci\u0105\u017cenie serwera<\/h2>\n\n<p>Ka\u017cde otwarte po\u0142\u0105czenie zu\u017cywa <strong>Zasoby<\/strong> w procesorze, pami\u0119ci RAM, sieci i prawdopodobnie w bazie danych. Przy du\u017cym obci\u0105\u017ceniu, prze\u0142\u0105czanie kontekstu wzrasta, kolejki j\u0105dra zape\u0142niaj\u0105 si\u0119, a serwer wstrzymuje przyjmowanie nowych \u017c\u0105da\u0144. Keep-Alive zmniejsza liczb\u0119 u\u015bcisk\u00f3w d\u0142oni, ale zwi\u0119ksza zapotrzebowanie na pami\u0119\u0107 na gniazdo podczas d\u0142ugich limit\u00f3w czasu. Zbyt ma\u0142e zaleg\u0142o\u015bci (SYN i Accept) prowadz\u0105 do spadk\u00f3w przed aplikacj\u0105. Dlatego te\u017c monitoruj\u0119 aktywne po\u0142\u0105czenia, poziomy zape\u0142nienia backlog\u00f3w i retransmisje oraz optymalizuj\u0119 timeouty tak, aby unika\u0107 czasu bezczynno\u015bci, ale szybko zwalnia\u0107 po\u0142\u0105czenia po u\u017cyciu.<\/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\/webhosting_besprechung_2398.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dostrajanie wydajno\u015bci w celu zwi\u0119kszenia przepustowo\u015bci<\/h2>\n\n<p>W przypadku wi\u0119kszej liczby jednoczesnych u\u017cytkownik\u00f3w najpierw podnosz\u0119 limity j\u0105dra i zgadzam si\u0119 na <strong>Sie\u0107<\/strong>-buffer. Parametr net.core.somaxconn cz\u0119sto wynosi 128 i spowalnia akceptacj\u0119 nowych po\u0142\u0105cze\u0144, wi\u0119c ustawiam go znacznie wy\u017cej w zale\u017cno\u015bci od systemu, cz\u0119sto na 4096 lub wi\u0119cej. Zwi\u0119kszam kolejk\u0119 dla p\u00f3\u0142otwartych po\u0142\u0105cze\u0144 za pomoc\u0105 net.ipv4.tcp_max_syn_backlog, aby szczyty przechodzi\u0142y czysto. Dostosowuj\u0119 bufory odbioru i wysy\u0142ania (rmem_max, wmem_max) do przepustowo\u015bci razy RTT, aby \u017cadne pakiety nie zacina\u0142y si\u0119 w przestrzeni u\u017cytkownika. Dzi\u0119ki skoordynowanym limitom czasu i czystej kolejce akceptacji, liczba stabilnie przetwarzanych \u017c\u0105da\u0144 zauwa\u017calnie wzrasta bez konieczno\u015bci polegania na <strong>jako\u015b\u0107<\/strong> w czasie reakcji.<\/p>\n\n<h2>Konfiguracja serwera WWW: Nginx i Apache<\/h2>\n\n<p>Z Nginx zwi\u0119kszam <strong>worker_connections<\/strong> i ustawi\u0107 worker_rlimit_nofile tak, aby odpowiada\u0142 limitowi systemowemu, aby limity deskryptor\u00f3w plik\u00f3w nie kolidowa\u0142y wcze\u015bnie. Keepalive_timeout wynosz\u0105cy oko\u0142o jednej minuty utrzymuje po\u0142\u0105czenia otwarte efektywnie, bez utrzymywania bezczynnych gniazd zbyt d\u0142ugo. W przypadku Apache u\u017cywam Event-MPM i wymiaru MaxRequestWorkers, aby rezerwacje pami\u0119ci RAM odpowiada\u0142y rozmiarowi proces\u00f3w PHP. G\u0142\u0119bsze zrozumienie proces\u00f3w pomi\u0119dzy prefork, worker i event daje zauwa\u017calne r\u00f3\u017cnice w przepustowo\u015bci. Przegl\u0105d mocnych stron poszczeg\u00f3lnych modeli mo\u017cna znale\u017a\u0107 w artykule <a href=\"https:\/\/webhosting.de\/pl\/webserver-worker-models-prefork-worker-event-mpm-serverperf\/\">MPM zdarze\u0144 i modele pracownik\u00f3w<\/a>, co pomaga mi wybra\u0107 w\u0142a\u015bciwe podej\u015bcie.<\/p>\n\n<h2>Po\u0142\u0105czenia z baz\u0105 danych i limity czasu<\/h2>\n\n<p>W bazie danych ograniczam po\u0142\u0105czenia za pomoc\u0105 <strong>max_connections<\/strong> i zaplanowa\u0107 wystarczaj\u0105c\u0105 ilo\u015b\u0107 bufor\u00f3w w puli bufor\u00f3w InnoDB, aby aktywne rekordy znajdowa\u0142y si\u0119 w pami\u0119ci RAM. Monitoruj\u0119 anulowania, czasy oczekiwania na blokad\u0119 i kolejki po\u0142\u0105cze\u0144 aplikacji, poniewa\u017c zbyt wysoki limit powoduje zbyt du\u017ce obci\u0105\u017cenie procesora przy zbyt wielu aktywnych sesjach. Utrzymuj\u0119 kr\u00f3tki czas trwania transakcji i limit czasu puli, aby po\u0142\u0105czenia by\u0142y szybko zwracane do puli. W przypadku typowych stos\u00f3w internetowych, umiarkowanie ustawione warto\u015bci id\u0105 znacznie dalej ni\u017c \u015blepo wysokie maksima. Je\u015bli chcesz zag\u0142\u0119bi\u0107 si\u0119 we wzorce b\u0142\u0119d\u00f3w, takie jak 500 przy zbyt wielu sesjach DB, mo\u017cesz znale\u017a\u0107 informacje na stronie <a href=\"https:\/\/webhosting.de\/pl\/ograniczenia-polaczenia-z-baza-danych-500-blad-hosting-optimus\/\">Limity po\u0142\u0105cze\u0144 z baz\u0105 danych<\/a>, co cz\u0119sto przyspiesza moj\u0105 diagnoz\u0119.<\/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\/webhosting-connection-limits-2947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Buforowanie, HTTP\/2\/3 i Keep-Alive<\/h2>\n\n<p>Czyste buforowanie zmniejsza dynamik\u0119 <strong>Obci\u0105\u017cenie<\/strong> natychmiast, poniewa\u017c wymagana jest mniejsza liczba wywo\u0142a\u0144 PHP i DB. Pami\u0119\u0107 podr\u0119czna stron, fragment\u00f3w i obiekt\u00f3w zmniejsza nacisk na baz\u0119 danych o bardzo du\u017c\u0105 cz\u0119\u015b\u0107, w zale\u017cno\u015bci od aplikacji. Dzi\u0119ki HTTP\/2 lub HTTP\/3 przegl\u0105darka \u0142\u0105czy wiele \u017c\u0105da\u0144 w kilka po\u0142\u0105cze\u0144, co drastycznie zmniejsza liczb\u0119 gniazd na klienta. Kompresja (Gzip\/Brotli) oszcz\u0119dza przepustowo\u015b\u0107 i skraca czas transferu, o ile dost\u0119pne s\u0105 rezerwy procesora. Dzi\u0119ki rozs\u0105dnym timeoutom keep-alive, zbieram zyski z ponownie wykorzystywanych po\u0142\u0105cze\u0144 bez wi\u0105zania pami\u0119ci zbyt d\u0142ugimi fazami bezczynno\u015bci, co zmniejsza obci\u0105\u017cenie procesora. <strong>Wydajno\u015b\u0107<\/strong> dalsze wzrosty.<\/p>\n\n<h2>Dostrajanie sprz\u0119tu i sieci<\/h2>\n\n<p>U\u017cytkownicy o du\u017cej liczbie jednoczesnych po\u0142\u0105cze\u0144 korzystaj\u0105 z <strong>CPU<\/strong>-w\u0105tk\u00f3w, pami\u0119ci RAM i szybkich dysk\u00f3w SSD NVMe, poniewa\u017c czas oczekiwania na operacje wej\u015bcia\/wyj\u015bcia jest kr\u00f3tszy. Od 16 w\u0105tk\u00f3w i 64 GB pami\u0119ci RAM, du\u017ce szczyty mog\u0105 by\u0107 uruchamiane z czystym op\u00f3\u017anieniem. W sieci op\u0142aca si\u0119 10 Gb\/s, zw\u0142aszcza przy nowoczesnej kontroli przeci\u0105\u017cenia, takiej jak BBR. Minimalizuj\u0119 us\u0142ugi dzia\u0142aj\u0105ce w tle, ustawiam odpowiednie harmonogramy I\/O i dbam o aktualno\u015b\u0107 j\u0105dra i sterownik\u00f3w. Wyra\u017ane oddzielenie wolumin\u00f3w danych i dziennik\u00f3w pozwala unikn\u0105\u0107 efektu \u201eha\u0142a\u015bliwego s\u0105siada\u201c i utrzymuje <strong>Czas reakcji<\/strong> stabilny.<\/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\/ConnectionLimitsTechOffice1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>PHP-FPM i limity proces\u00f3w<\/h2>\n\n<p>Wiele stron internetowych zale\u017cy od PHP-FPM, wi\u0119c wprowadzam <strong>pm.max_children<\/strong> w zale\u017cno\u015bci od rozmiaru procesu i dost\u0119pnej pami\u0119ci RAM. Zbyt wysoka liczba blokuje pami\u0119\u0107 RAM i prowadzi do wymiany, co znacznie zwi\u0119ksza op\u00f3\u017anienia. Liczba, kt\u00f3ra jest zbyt niska, powoduje 503 podczas szczyt\u00f3w obci\u0105\u017cenia, chocia\u017c pojemno\u015b\u0107 procesora by\u0142aby dost\u0119pna. Dostosowuj\u0119 warto\u015bci pocz\u0105tkowe, zapasowe i maksymalne, aby kolejki pozosta\u0142y kr\u00f3tkie, a procesy dzia\u0142a\u0142y p\u0142ynnie. Je\u015bli chcesz bardziej precyzyjnie ustawi\u0107 szczeg\u00f3\u0142y tego modu\u0142u, mo\u017cesz znale\u017a\u0107 praktyczne wskaz\u00f3wki na stronie <a href=\"https:\/\/webhosting.de\/pl\/php-fpm-zarzadzanie-procesami-pm-max-children-optymalizacja-rdzenia\/\">PHP-FPM pm.max_children<\/a>, co znacznie upraszcza rozwi\u0105zywanie problem\u00f3w.<\/p>\n\n<h2>Monitorowanie i testy obci\u0105\u017ceniowe<\/h2>\n\n<p>Osi\u0105gam trwa\u0142\u0105 stabilno\u015b\u0107 poprzez <strong>Monitoring<\/strong> i powtarzalne testy obci\u0105\u017cenia. Sprawdzam wykorzystanie procesora, czas kradzie\u017cy w \u015brodowiskach wirtualnych, limity pami\u0119ci RAM, op\u00f3\u017anienia dysk\u00f3w i b\u0142\u0119dy sieciowe. Kolejki akceptacji, zaleg\u0142o\u015bci SYN i retransmisje pokazuj\u0105, czy limit jest zbyt w\u0105ski lub czy aplikacja zwalnia. Do test\u00f3w obci\u0105\u017cenia u\u017cywam narz\u0119dzi takich jak \u201ehey\u201c lub \u201ewrk\u201c i stopniowo zwi\u0119kszam liczb\u0119 u\u017cytkownik\u00f3w, a\u017c znajd\u0119 za\u0142amanie krzywej. Na tej podstawie zmieniam limity, sprawdzam ponownie i zachowuj\u0119 <strong>Stabilno\u015b\u0107<\/strong> w realistycznych warunkach.<\/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_webhosting_7654.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktyczne warto\u015bci orientacyjne i tabela<\/h2>\n\n<p>Do konfiguracji startowych u\u017cywam <strong>Warto\u015bci standardowe<\/strong>, kt\u00f3ry p\u00f3\u017aniej dostrajam za pomoc\u0105 pomiar\u00f3w. W przypadku Nginx cz\u0119sto zaczynam od 2048 worker_connections i ustawiam odpowiednio wy\u017cszy limit otwartych plik\u00f3w. W przypadku Apache wybieram model zdarze\u0144 i utrzymuj\u0119 MaxRequestWorkers w zakresie odpowiadaj\u0105cym rozmiarowi proces\u00f3w PHP. Zaczynam konserwatywnie w bazie danych i zwi\u0119kszam j\u0105 tylko wtedy, gdy op\u00f3\u017anienia pozostaj\u0105 stabilne. Podnosz\u0119 limity j\u0105dra, a nast\u0119pnie testuj\u0119 pod szczytowym obci\u0105\u017ceniem i sprawdzam <strong>Wp\u0142yw<\/strong> na kolejkach i czasach reakcji.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametry<\/th>\n      <th>Komponent<\/th>\n      <th>warto\u015b\u0107 pocz\u0105tkowa<\/th>\n      <th>Wp\u0142yw<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>net.core.somaxconn<\/td>\n      <td>J\u0105dro<\/td>\n      <td>4096+<\/td>\n      <td>Zwi\u0119ksza akceptacj\u0119 nowych po\u0142\u0105cze\u0144<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_max_syn_backlog<\/td>\n      <td>J\u0105dro<\/td>\n      <td>Wysoka warto\u015b\u0107 czterocyfrowa<\/td>\n      <td>Redukuje spadki przy p\u00f3\u0142otwartych gniazdach<\/td>\n    <\/tr>\n    <tr>\n      <td>rmem_max \/ wmem_max<\/td>\n      <td>J\u0105dro<\/td>\n      <td>do przepustowo\u015bci x RTT<\/td>\n      <td>Zapobiega zatorom dzi\u0119ki szybkiej sieci<\/td>\n    <\/tr>\n    <tr>\n      <td>worker_connections<\/td>\n      <td>Nginx<\/td>\n      <td>2048<\/td>\n      <td>Zwi\u0119ksza wsp\u00f3\u0142bie\u017cno\u015b\u0107 na pracownika<\/td>\n    <\/tr>\n    <tr>\n      <td>MaxRequestWorkers<\/td>\n      <td>Apache (Wydarzenie)<\/td>\n      <td>150-400<\/td>\n      <td>Procesy kontrolne w bud\u017cecie RAM<\/td>\n    <\/tr>\n    <tr>\n      <td>keepalive_timeout<\/td>\n      <td>Nginx\/Apache<\/td>\n      <td>~60s<\/td>\n      <td>Zmniejsza obci\u0105\u017cenie zwi\u0105zane z u\u015bciskiem d\u0142oni<\/td>\n    <\/tr>\n    <tr>\n      <td>max_connections<\/td>\n      <td>Baza danych<\/td>\n      <td>~1000<\/td>\n      <td>R\u00f3wnowa\u017cenie obci\u0105\u017cenia sesji<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Ograniczenia systemu operacyjnego: deskryptory, porty i stany<\/h2>\n\n<p>Opr\u00f3cz oczywistych parametr\u00f3w sieci <strong>Deskryptory plik\u00f3w<\/strong> i limity proces\u00f3w s\u0105 parametrami krytycznymi. Ustawi\u0142em nofile (ulimit) dla u\u017cytkownik\u00f3w i us\u0142ug, aby serwer WWW, PHP-FPM i baza danych mog\u0142y otworzy\u0107 wystarczaj\u0105c\u0105 liczb\u0119 gniazd i plik\u00f3w. Og\u00f3lna warto\u015b\u0107 j\u0105dra fs.file-max musi si\u0119 z tym zgadza\u0107; w przeciwnym razie procesy osi\u0105gn\u0105 koniec przedwcze\u015bnie pomimo prawid\u0142owych ustawie\u0144 us\u0142ugi. Liczba dozwolonych proces\u00f3w\/w\u0105tk\u00f3w (nproc) jest r\u00f3wnie wa\u017cna, aby pod obci\u0105\u017ceniem nie wyst\u0105pi\u0142y nieoczekiwane b\u0142\u0119dy rozwidlenia.<\/p>\n\n<p>Drugie spojrzenie <strong>Porty efemeryczne<\/strong> (ip_local_port_range) i stany TCP, takie jak TIME_WAIT. Przy du\u017cej liczbie po\u0142\u0105cze\u0144 wychodz\u0105cych (np. jako proxy lub z mikrous\u0142ugami), dost\u0119pny zakres port\u00f3w mo\u017ce sta\u0107 si\u0119 w\u0105skim gard\u0142em. Wybieram szeroki, rozs\u0105dny zakres i ustawiam limity czasu, aby nieaktywne po\u0142\u0105czenia by\u0142y szybko zwalniane bez u\u017cycia agresywnych lub niebezpiecznych prze\u0142\u0105cznik\u00f3w j\u0105dra. Kluczem jest zminimalizowanie czasu bezczynno\u015bci i promowanie ponownego u\u017cycia (keep-alive, HTTP\/2\/3, database pooling) zamiast ci\u0105g\u0142ego nawi\u0105zywania nowych po\u0142\u0105cze\u0144.<\/p>\n\n<h2>Poziom odwrotnego serwera proxy i load balancera<\/h2>\n\n<p>Pomi\u0119dzy klientem a aplikacj\u0105 cz\u0119sto wyst\u0119puje <strong>Odwrotne proxy<\/strong> lub load balancer. Tam te\u017c ustawiam rozs\u0105dne backlogi, timeouty i keep-alive na <em>w g\u00f3r\u0119 rzeki<\/em>-page. W Nginx pula keepalive upstream zapewnia, \u017ce po\u0142\u0105czenia z aplikacj\u0105 s\u0105 ponownie wykorzystywane, co zmniejsza obci\u0105\u017cenie zar\u00f3wno port\u00f3w, jak i procesora. U\u017cywam ograniczania po\u0142\u0105cze\u0144 (limit_conn) i ograniczania szybko\u015bci opartego na \u017c\u0105daniach (limit_req) w dawkach, aby okie\u0142zna\u0107 poszczeg\u00f3lnych klient\u00f3w bez ograniczania legalnego obci\u0105\u017cenia. Wyra\u017any zwrot b\u0142\u0119du (429 zamiast 503 dla ograniczania szybko\u015bci) pomaga przeanalizowa\u0107 przyczyn\u0119 podczas pracy.<\/p>\n\n<p>Na stronie <strong>Proces po\u0142\u0105czenia<\/strong> Podczas wdro\u017ce\u0144 lub skalowania u\u017cywam opr\u00f3\u017cniania po\u0142\u0105cze\u0144 lub \u0142agodnego zamykania: nowe \u017c\u0105dania nie s\u0105 ju\u017c akceptowane, a istniej\u0105ce s\u0105 ko\u0144czone w czysty spos\u00f3b. W ten spos\u00f3b unikam skok\u00f3w op\u00f3\u017anie\u0144 i poziom\u00f3w b\u0142\u0119d\u00f3w podczas zast\u0119powania wersji lub zmniejszania liczby instancji.<\/p>\n\n<h2>Zako\u0144czenie TLS, szczeg\u00f3\u0142y HTTP\/2\/3 i wykorzystanie procesora<\/h2>\n\n<p>U\u015bciski d\u0142oni TLS kosztuj\u0105 procesor i op\u00f3\u017anienia. Ko\u0144cz\u0119 TLS tak daleko, jak to mo\u017cliwe <strong>blisko klienta<\/strong> (np. na brzegowym serwerze proxy) i u\u017cywa\u0107 wznawiania sesji, zszywania OCSP i nowoczesnych, wysokowydajnych zestaw\u00f3w szyfr\u00f3w. Oszcz\u0119dza to u\u015bciski d\u0142oni i skraca czas do pierwszego bajtu. W protokole HTTP\/2\/3 warto zwraca\u0107 uwag\u0119 na kompresj\u0119 nag\u0142\u00f3wk\u00f3w i priorytetyzacj\u0119: Nieprawid\u0142owe priorytety strumieni mog\u0105 zwi\u0119kszy\u0107 op\u00f3\u017anienia, nawet je\u015bli wsp\u00f3\u0142bie\u017cno\u015b\u0107 jest wysoka. Upewniam si\u0119 r\u00f3wnie\u017c, \u017ce limity czasu keep-alive i limity na pochodzenie s\u0105 wybrane w taki spos\u00f3b, \u017ce nie mo\u017ce wyst\u0105pi\u0107 blokowanie head-of-line.<\/p>\n\n<p>Zw\u0142aszcza w przypadku szyfr\u00f3w o du\u017cym obci\u0105\u017ceniu procesora lub poziom\u00f3w Brotli, u\u017cywam test\u00f3w por\u00f3wnawczych, aby znale\u017a\u0107 punkt, w kt\u00f3rym kompresja <strong>wykorzystuje zamiast hamulc\u00f3w<\/strong>. Podczas szczytowego ruchu tymczasowo obni\u017cam poziom kompresji, gdy procesor jest w\u0105skim gard\u0142em, i ponownie go podnosz\u0119 podczas normalnego ruchu.<\/p>\n\n<h2>Ruch w czasie rzeczywistym: WebSockets, SSE i d\u0142ugie odpytywanie<\/h2>\n\n<p>Po\u0142\u0105czenia, kt\u00f3re pozostaj\u0105 otwarte przez d\u0142ugi czas (WebSockets, zdarzenia wysy\u0142ane przez serwer, d\u0142ugie odpytywanie) maj\u0105 silny wp\u0142yw na planowanie przepustowo\u015bci. Oddzielam takie po\u0142\u0105czenia <strong>D\u0142ugowieczny<\/strong>-po\u0142\u0105czenia z klasycznych \u015bcie\u017cek \u017c\u0105danie\/odpowied\u017a, wymiarowanie dedykowanych pracownik\u00f3w i ustawianie bardziej rygorystycznych limit\u00f3w. Wa\u017cne jest, aby na jedno po\u0142\u0105czenie przypada\u0142o niewiele zasob\u00f3w: Lekkie stosy protoko\u0142\u00f3w, w\u0105skie bufory i konserwatywne strategie keep-alive s\u0105 tutaj obowi\u0105zkowe. Mierz\u0119 osobno wed\u0142ug typu po\u0142\u0105czenia, aby klasyczne ods\u0142ony nie ucierpia\u0142y z powodu sta\u0142ych po\u0142\u0105cze\u0144.<\/p>\n\n<h2>Kontenery i chmura: Conntrack, limity pod\u00f3w i rozgrzewka<\/h2>\n\n<p>W \u015brodowiskach kontenerowych cz\u0119sto spotykam si\u0119 z <strong>Conntrack<\/strong>-limits. nf_conntrack_max i rozmiar skr\u00f3tu musz\u0105 by\u0107 zgodne z oczekiwan\u0105 liczb\u0105 po\u0142\u0105cze\u0144, w przeciwnym razie pakiety b\u0119d\u0105 ju\u017c spada\u0107 w j\u0105drze. Limity pod\u00f3w (CPU\/Memory Requests &amp; Limits) r\u00f3wnie\u017c okre\u015blaj\u0105, ile jednoczesnych \u017c\u0105da\u0144 instancja mo\u017ce faktycznie obs\u0142u\u017cy\u0107. Planuj\u0119 fazy rozgrzewki, aby \u015bwie\u017co uruchomione pody mog\u0142y zape\u0142ni\u0107 pami\u0119ci podr\u0119czne, zanim otrzymaj\u0105 pe\u0142ny ruch. Na poziomie w\u0119z\u0142a upewniam si\u0119, \u017ce warto\u015bci ulimit i sysctl docieraj\u0105 do kontener\u00f3w (np. poprzez initContainer lub DaemonSets) i nie utkn\u0105 na ho\u015bcie.<\/p>\n\n<p>Na stronie <strong>Skalowanie poziome<\/strong> U\u017cywam op\u00f3\u017anie\u0144 p95\/p99 jako wyzwalaczy, nie tylko CPU. W ten spos\u00f3b reaguj\u0119 na rzeczywiste do\u015bwiadczenia u\u017cytkownik\u00f3w i zapobiegam zniekszta\u0142caniu \u015bredniej przez pojedyncze \u201eg\u0142o\u015bne\u201c kapsu\u0142y. Drenowanie po\u0142\u0105czenia w Ingress\/Service zapewnia p\u0142ynne przej\u015bcia podczas skalowania w g\u00f3r\u0119 i w d\u00f3\u0142.<\/p>\n\n<h2>Obrazy b\u0142\u0119d\u00f3w i szybka diagnostyka<\/h2>\n\n<p>Typowe objawy rozpoznaj\u0119 po wyra\u017anych wzorcach:<\/p>\n<ul>\n  <li><strong>Wysoka liczba retransmisji \/ spadk\u00f3w SYN:<\/strong> Zbyt ma\u0142e zaleg\u0142o\u015bci, utrata pakiet\u00f3w lub zbyt kr\u00f3tkie kolejki akceptacji.<\/li>\n  <li><strong>Wiele 502\/504:<\/strong> Upstream timeouts, zbyt ma\u0142e pule PHP FPM\/DB lub blokowanie wywo\u0142a\u0144 aplikacji.<\/li>\n  <li><strong>503 pod obci\u0105\u017ceniem:<\/strong> Wyczerpane pule pracownik\u00f3w lub proces\u00f3w, osi\u0105gni\u0119to limit pami\u0119ci RAM, zbyt w\u0105skie limity.<\/li>\n  <li><strong>Skoki w TIME_WAIT:<\/strong> Nadmierna liczba nowych konstrukcji zamiast ponownego wykorzystania; sprawd\u017a utrzymanie aktywno\u015bci\/pooling.<\/li>\n  <li><strong>Zwi\u0119kszenie op\u00f3\u017anie\u0144 p99 przy stabilnym p50:<\/strong> Efekty kolejkowania, hotspoty, konkurencja blokad.<\/li>\n<\/ul>\n<p>Dla <strong>Szybka diagnoza<\/strong> \u0141\u0105cz\u0119 metryki (zaleg\u0142o\u015bci, stany po\u0142\u0105cze\u0144, op\u00f3\u017anienia) z kr\u00f3tkim profilowaniem i pr\u00f3bkami log\u00f3w. Zapisuj\u0119 dzienniki dost\u0119pu w spos\u00f3b buforowany lub selektywny, aby zapobiec sytuacji, w kt\u00f3rej wej\u015bcia\/wyj\u015bcia staj\u0105 si\u0119 w\u0105skim gard\u0142em. Je\u015bli logi staj\u0105 si\u0119 w\u0105skim gard\u0142em, przenosz\u0119 je asynchronicznie i agreguj\u0119 centralnie.<\/p>\n\n<h2>Planowanie wydajno\u015bci: zapas, SLO i profile testowe<\/h2>\n\n<p>Planuj\u0119 z <strong>Headroom<\/strong> 20-40% powy\u017cej typowego dziennego obci\u0105\u017cenia, aby kr\u00f3tkie szczyty nie powodowa\u0142y natychmiastowego przekroczenia limit\u00f3w. W przypadku aplikacji krytycznych dla biznesu uruchamiam rezerwy N-1: je\u015bli jedna instancja ulegnie awarii, pojemno\u015b\u0107 pozosta\u0142ych instancji jest nadal wystarczaj\u0105ca dla akceptowalnych SLO. Definiuj\u0119 mierzalne cele (np. 99% \u017c\u0105da\u0144 poni\u017cej 300 ms, wska\u017anik b\u0142\u0119d\u00f3w &lt; 0,1%) i testuj\u0119 je.<\/p>\n\n<p>Prze\u0142\u0105czam si\u0119 mi\u0119dzy profilami podczas test\u00f3w obci\u0105\u017ceniowych:<\/p>\n<ul>\n  <li><strong>Krok \u0142adowania:<\/strong> Zwi\u0119kszaj co 1-5 minut, aby wyra\u017anie zobaczy\u0107 punkty za\u0142amania.<\/li>\n  <li><strong>Testy nasi\u0105kliwo\u015bci:<\/strong> Kilka godzin pod sta\u0142ym, wysokim obci\u0105\u017ceniem w celu wykrycia wyciek\u00f3w i dryftu.<\/li>\n  <li><strong>Testy seryjne:<\/strong> Symulacja kr\u00f3tkoterminowych szczyt\u00f3w w celu sprawdzenia rezerw i limit\u00f3w zaleg\u0142o\u015bci.<\/li>\n<\/ul>\n<p>Mierz\u0119 nie tylko przepustowo\u015b\u0107, ale tak\u017ce <strong>Czasy oczekiwania w kolejkach<\/strong>, kradzie\u017c procesora w maszynach wirtualnych, op\u00f3\u017anienie dysku i b\u0142\u0119dy sieci. Tylko kombinacja pokazuje, czy system jest stabilny systemowo, czy tylko szybki w kr\u00f3tkim okresie.<\/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\/hosting-serverraum-7432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Skalowanie i szczyty ruchu<\/h2>\n\n<p>W przypadku nag\u0142ych szczyt\u00f3w \u0142\u0105cz\u0119 <strong>R\u00f3wnowa\u017cenie obci\u0105\u017cenia<\/strong>, buforowanie i outsourcing tre\u015bci. Metody round robin lub weighted rozdzielaj\u0105 \u017c\u0105dania na wiele instancji. Przeci\u0105gam pliki statyczne do CDN, aby serwer \u017ar\u00f3d\u0142owy mia\u0142 wolny procesor do dynamicznych odpowiedzi. Autoskalowanie na poziomie aplikacji lub kontenera uzupe\u0142nia te \u015brodki i skraca czas reakcji na skoki obci\u0105\u017cenia. U\u017cywam kwot i ograniczania szybko\u015bci, aby chroni\u0107 platform\u0119 przed zalewem zaleg\u0142o\u015bci i utrzymywa\u0107 <strong>Dost\u0119pno\u015b\u0107<\/strong> wysoki.<\/p>\n\n<h2>Moja podstawowa mapa drogowa: Oto jak post\u0119puj\u0119<\/h2>\n\n<p>Najpierw okre\u015blam pr\u0105d <strong>Limit<\/strong>, Mierz\u0119 op\u00f3\u017anienia, wska\u017aniki b\u0142\u0119d\u00f3w i d\u0142ugo\u015bci kolejek oraz rejestruj\u0119 twarde w\u0105skie gard\u0142a. Nast\u0119pnie stopniowo zwi\u0119kszam limity j\u0105dra i serwera WWW, dostosowuj\u0119 keep-alive i bufory oraz sprawdzam efekt pod obci\u0105\u017ceniem. W trzecim kroku integruj\u0119 buforowanie, aktywuj\u0119 HTTP\/2 lub HTTP\/3 i optymalizuj\u0119 parametry bazy danych. W czwartym kroku harmonizuj\u0119 procesy PHP FPM i limity deskryptor\u00f3w plik\u00f3w z bud\u017cetem pami\u0119ci RAM. Wreszcie, ustanawiam sta\u0142y monitoring, regularnie powtarzam testy obci\u0105\u017cenia i w ten spos\u00f3b utrzymuj\u0119 moje <strong>Po\u0142\u0105czenie<\/strong> Limity na sta\u0142e w zielonym zakresie.<\/p>\n\n<h2>Podsumowanie: Stabilny z rezerwami zamiast na kraw\u0119dzi<\/h2>\n\n<p>Limity po\u0142\u0105cze\u0144 nie s\u0105 pojedynczym prze\u0142\u0105cznikiem, ale <strong>Interakcja<\/strong> od kolejek j\u0105dra, ustawie\u0144 serwera WWW, pul proces\u00f3w, strojenia baz danych, \u015bcie\u017cek sieciowych i sprz\u0119tu. Podnoszenie limit\u00f3w w izolacji cz\u0119sto tylko odsuwa problem w czasie. Dlatego te\u017c stosuj\u0119 podej\u015bcie holistyczne: najpierw mierz\u0119, potem zwi\u0119kszam w ukierunkowany spos\u00f3b, zawsze testuj\u0119 w odniesieniu do rzeczywistych wzorc\u00f3w obci\u0105\u017cenia i wspieram monitorowaniem. W ten spos\u00f3b przepustowo\u015b\u0107 i niezawodno\u015b\u0107 rosn\u0105 razem, a serwer pozostaje stabilny nawet przy szczytowych obci\u0105\u017ceniach. <strong>przewidywalna wydajno\u015b\u0107<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Limity po\u0142\u0105cze\u0144 w hostingu internetowym zarz\u0105dzaj\u0105 jednoczesnymi po\u0142\u0105czeniami i zmniejszaj\u0105 obci\u0105\u017cenie serwera poprzez dostrajanie wydajno\u015bci. Pozwala to na p\u0142ynne skalowanie.<\/p>","protected":false},"author":1,"featured_media":18426,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-18433","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"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":"712","_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":"Connection Limits","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":"18426","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/18433","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=18433"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/18433\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/18426"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=18433"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=18433"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=18433"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}