Przejdź do treści 
Dzięki potokowi Redis łączę kilka poleceń w ramach jednej rundy komunikacji, co pozwala znacznie skrócić czas oczekiwania między aplikacją a serwerem Redis. To przyspiesza Przepustowość wyraźnie w górę, zwłaszcza w przypadku wielu niewielkich, niezależnych dostępów do Schowek i sesje.
Punkty centralne
Zanim przejdę do szczegółów, pokrótce podsumuję najważniejsze tezy, abyś mógł szybciej zorientować się w kolejnych akapitach i ukierunkowany można zastosować. Punkty te pokazują, gdzie działa pipelining, czym różni się od alternatywnych rozwiązań oraz na co należy zwrócić uwagę podczas wdrażania go w środowisku produkcyjnym ósmy.
- Mniej podróży w obie strony: Łączenie poleceń, oszczędzanie ścieżek sieciowych, zmniejszanie opóźnień.
- Większa przepustowość: Wiele drobnych operacji odczytu i zapisu przebiega zauważalnie szybciej.
- Wyraźne korzyści: sesje, liczniki, trafienia w pamięci podręcznej, operacje masowego zapisu.
- Brak zamiennika: Potok danych optymalizuje przesyłanie, a transakcje zapewniają atomowość.
- Testy pragmatyczne: Mierzyć wielkość partii, monitorować wskaźniki, definiować limity.
Korzystam z pipeliningu przede wszystkim wtedy, gdy polecenia są od siebie niezależne, a ich wyniki zebrane razem wystarczają do wykonania kolejnego kroku start. W ten sposób przy niewielkich zmianach uzyskuję zauważalnie szybsze Czas reakcji.
Jak działa pipelining w Redis
W przypadku pipeliningu wysyłam kilka poleceń Redis jedno po drugim, nie czekając na odpowiedzi między poszczególnymi poleceniami; odpowiedzi otrzymuję następnie zbiorczo i mogę je przetworzyć za jednym razem przetwarzać. Dzięki temu oszczędzam na operacjach sieciowych, które w przeciwnym razie spowalniają każdą pojedynczą operację i znacznie wydłużają rzeczywisty czas odpowiedzi, mimo że serwer działa wewnętrznie bardzo szybko prace. Procedura ta nie zmienia modeli danych, lecz sposób, w jaki klient i serwer komunikują się ze sobą oraz liczbę dialogów wymaganych na jedną operację. Sam potok nie gwarantuje atomowości ani żadnej konkretnej kolejności wykraczającej poza semantykę poleceń; przyspiesza jednak transmisję i odciąża aplikację od ciągłego oczekiwania. W stosach internetowych z wieloma szczegółowymi zapytaniami opłaca się to, ponieważ krótszy czas oczekiwania na linii zazwyczaj oznacza bardziej odczuwalną wydajność w punkcie końcowym, zwłaszcza gdy opóźnienie sieciowe ma znaczenie upadki.
Dlaczego pipelining skraca czas odpowiedzi
Każda wymiana danych generuje koszty stałe: obciążenie protokołu TCP, opóźnienie, zmiana kontekstu – czynniki, które w przypadku wielu małych poleceń sumują się i zmniejszają korzyści płynące z szybkiego dostępu do pamięci zmniejszać się. Łącząc kilka poleceń, rzadziej ponoszę te koszty stałe, dzięki czemu wzrasta ilość danych użytkowych na operację sieciową, a czas oczekiwania na żądanie spadki. Efekt ten jest szczególnie wyraźny na większych odległościach lub w topologiach chmurowych, gdzie dodatkowe przeskoki i zapory sieciowe wpływają na synchronizację. Nawet jeśli serwer Redis znajduje się blisko i działa szybko, każda mini-runda zajmuje więcej czasu niż to konieczne; dzięki pipeliningowi przez to samo łącze przepływa więc większa ilość danych. Krótko mówiąc: przenoszę wąskie gardło z sieci w stronę przetwarzania serwerowego, które w przypadku Redis jest zazwyczaj bardzo wydajne służy.
Wpływ wydajności w testach porównawczych
Raporty z praktyki wskazują na znaczny wzrost liczby zapytań na sekundę, gdy aplikacje grupują wiele małych poleceń, co powoduje, że potok Użyj. Jako przykład podano wzrost z około 97 370 do 1 351 351 żądań na sekundę – ogromny zysk wynikający ze skrócenia czasu przesyłu w obie strony oraz bardziej efektywnego wykorzystania Nad głową. Takie wartości zależą oczywiście od sprzętu, opóźnienia, rozmiaru pakietu i implementacji klienta; traktuję je zatem jako wskazówkę, a nie jako wiążącą obietnicę. Kluczowe znaczenie ma fakt, że operacje sieciowe są bardziej kosztowne niż szybkie operacje w pamięci, dlatego mniejsza liczba operacji sieciowych prawie zawsze pozwala uzyskać większą wydajność netto. Kto korzysta z własnego środowiska pomiarowego, szybko dostrzeże ten efekt na histogramach opóźnień i krzywych przepustowości, zwłaszcza przy wysokim poziomie „chattiness” Obciążenia.
Typowe scenariusze zastosowań w aplikacjach internetowych
Korzystam z pipeliningu przede wszystkim w przypadku wielu niezależnych operacji: odczytu wielu kluczy, gromadzenia wartości z pamięci podręcznej, inkrementowania liczników, sprawdzania tokenów lub masowych operacji zapisu podczas rozgrzewania Skrytki. W interfejsach sklepów internetowych, panelach kontrolnych, punktach końcowych śledzenia lub bramkach API często na każdą akcję użytkownika przypada kilka drobnych czynności, które pojedynczo zajmują niewiele czasu, ale łącznie są odczuwalne Hamulec. Jeśli nie potrzebuję odpowiedzi od razu dla każdego pojedynczego kroku, grupuję polecenia i przetwarzam wyniki zbiorczo. W ten sposób oszczędzam czas oczekiwania, ograniczam nadmierną aktywność gniazd sieciowych i zwiększam przepustowość bez konieczności gruntownej przebudowy architektury. Szczególnie w ścieżkach żądań, które wywołują kolejno wiele metod getter i setter, zapewnia to bardziej stabilny profil opóźnień i zauważalnie szybsze Odpowiedzi.
Pipelining w klastrze Redis i przy shardingu
W konfiguracjach klastrowych zwracam uwagę, aby polecenia połączone za pomocą potoków pasujący do komina , czyli w miarę możliwości trafiają na te same sloty hashowe, a tym samym na ten sam węzeł w ramach każdego potoku. Wiele nowoczesnych klientów automatycznie rozpoznaje docelowe sloty i wewnętrznie dzieli duży potok na Podpotoki na każdy węzeł. Pozwala to uniknąć błędów związanych z krzyżowaniem slotów i ogranicza zbędne obejścia wynikające z przekierowań MOVED/ASK. Podczas reorganizacji (resharding, przełączenie awaryjne) spodziewam się częściowych odpowiedzi lub przerw w połączeniu i dostosowuję logikę ponownych prób idempotentny, aby powtórzenia nie powodowały podwójnych efektów. Polecenia Multi-Key działają w klastrze tylko wtedy, gdy wszystkie klucze znajdują się w tym samym slocie; planuję klucze w taki sposób, aby w razie potrzeby móc korzystać z tagowania hashowego ({…} (w kluczu) świadomie tworzę grupy dostosowane do klastrów oraz potoki bez zbędnego rozproszenia wysłać.
Współpraca z językiem Lua i funkcjami po stronie serwera
Skrypty Lua (EVAL/EVALSHA) działają w Redis atomowy i w tym czasie blokują przetwarzanie kolejnych poleceń. Stosuję je celowo, gdy logika wymaga ścisłego powiązania, unikam jednak długich lub wymagających dużej ilości pamięci skryptów, ponieważ mogą one powodować skoki opóźnień dla wszystkich klientów. Pipelining i Lua wzajemnie się uzupełniają: najpierw ładuję skrypty (EVALSHA), a następnie stosuję pipelining tylko do niewielkich wywołań SHA z parametrami, zamiast za każdym razem wysyłać treść skryptu – pozwala to zaoszczędzić przepustowość. Tam, gdzie wcześniej stosowałem potokowanie wielu kroków przyrostowych, czasami konsoliduję je w jeden krótki skrypt, aby jeszcze bardziej skrócić czas przesyłu w obie strony obniżać oraz utrzymywanie spójnej semantyki w jednym miejscu. Dokładnie sprawdzam, czy czas blokady pozostaje na akceptowalnym poziomie i czy wartości p99 poprawa.
Potok, przetwarzanie wsadowe i transakcja: różnice
Terminy te brzmią podobnie, ale mają różne cele, które celowo rozróżniam, aby uniknąć błędnych założeń Unikać. Potok łączy polecenia w celu zmniejszenia liczby cykli komunikacyjnych i przyspieszenia transmisji; nie gwarantuje jednak atomowości. Transakcja za pomocą MULTI/EXEC wymusza wspólne wykonanie; jest to bardziej kosztowne, ale może być konieczne z technicznego punktu widzenia. Termin „batching” często odnosi się jedynie do grupowania po stronie klienta, bez specjalnej semantyki serwera. Kto zależy na wydajności, wybiera potok; kto potrzebuje reguł spójności, stosuje transakcję – a kto umiejętnie równoważy oba te aspekty, odpowiednio planuje przebieg procesów. czysty.
| Tryb | Cel | Opóźnienie | Sekwencja | Atomowość | Typowe zastosowanie |
|---|---|---|---|---|---|
| Pojedyncze wywołania | Prosty dialog dla każdego polecenia | Wysoki poziom przy dużej liczbie połączeń | Naturalna realizacja | Nie | Sporadyczne operacje odczytu/zapisu |
| Rurociąg | Oszczędzać na podróżach w obie strony | Niski poziom przy wielu opcjach call | Zebrane odpowiedzi | Nie | Wiele niezależnych poleceń |
| Transakcja | Wspólna realizacja | Wyżej niż rurociąg | Potwierdzono za pomocą EXEC | Tak | Etapy powiązane merytorycznie |
Nie podejmuję więc decyzji w sposób ogólny, lecz kieruję się potrzebami merytorycznymi i celem nauczania: jeśli chodzi przede wszystkim o tempo, wybieram Rurociąg; jeśli potrzebuję opcji „wszystko albo nic”, używam Transakcja. W ścieżkach mieszanych rozdzielam poszczególne kroki, tak aby tylko operacje rzeczywiście zależne od siebie trafiały do transakcji, podczas gdy pozostałe są wykonywane w trybie potokowym. Takie rozdzielenie skraca czasy oczekiwania i zapewnia szybką reakcję aplikacji. Dzięki temu semantyka pozostaje poprawna, a transfer przebiega sprawnie, bez konieczności wybierania jednego kosztem drugiego zamiana.
Unikanie ograniczeń i ryzyka
Nie każdy wzorzec przynosi korzyści: jeśli potrzebuję natychmiastowego wyniku każdego polecenia, korzyść płynąca z Rurociąg. Zbyt duże partie mogą zapełnić bufory serwera i klienta, spowodować przekroczenie limitów czasu lub zająć pamięć, której brakuje w innych miejscach; dlatego staram się utrzymywać ich rozmiar na umiarkowanym poziomie i dokładnie monitoruję wskaźniki dotyczące Informacje zwrotne. Obsługa błędów pozostaje ważna: starannie weryfikuję odpowiedzi, w sposób uporządkowany rejestruję odchylenia i w razie potrzeby zatrzymuję proces po osiągnięciu określonej liczby błędnych elementów. W przypadku zauważalnych opóźnień sprawdzam czynniki zewnętrzne, takie jak DNS, MTU, Nagle/Delayed ACK, odciążanie TLS czy łańcuchy serwerów proxy. Często prawdziwymi hamulcami są Typowe błędne konfiguracje, samo rurociągiowanie nie wystarczy leczy.
Najlepsze praktyki w codziennym życiu
Łączę tylko niezależne polecenia, a kroki zależne uruchamiam osobno, aby w pełni wykorzystać zalety komunikacji użycie. Pula połączeń pozwala uniknąć kosztownych procedur nawiązywania połączeń i utrzymuje połączenie aktywne, nie dopuszczając jednocześnie do nadmiernego wzrostu liczby równoległych połączeń. Wskaźniki takie jak cmdstat, histogramy opóźnień i wskaźniki błędów powinny znaleźć się na każdym pulpicie nawigacyjnym, abym mógł natychmiast dostrzec skutki i szybko zaplanować działania zaradcze. Na poziomie aplikacji zwracam uwagę na limity czasu, strategie ponownych prób z mechanizmem backoff oraz projekt idempotentny, aby powtórzenia nie powodowały skutków ubocznych wytwarzać. W przypadku dużych zadań dzielę pakiety robocze na stałe części i delikatnie ograniczam ich wydajność, jeśli wydłuża się czas oczekiwania lub zaczyna brakować pamięci.
Bufor wyjściowy, ciśnienie zwrotne i rozmiary ładunku
Pipelining zwiększa liczbę odpowiedzi, które serwer buforuje na jedno połączenie. Zachowuję Bufor wyjściowy klienta Zwracam na to uwagę, aby nie przekroczyć limitów miękkich i twardych. Duże odpowiedzi zbiorcze (np. szerokie skróty, duże listy lub wartości binarne) łączę w potoku tylko w umiarkowanym stopniu, aby ani serwer, ani klient nie musiały się nadmiernie wysilać. Wraz ze wzrostem bufora wyjściowego rosną opóźnienia, ponieważ serwer poświęca czas na wysyłanie danych zamiast na ich przetwarzanie. Dlatego staram się, by ładunki danych były przejrzyste, w razie potrzeby stosuję kompresję aplikacyjną (gdy dostępny jest czas procesora) oraz oddzielam operacje odczytu od zapisu, aby ciężkie odpowiedzi nie mieszały się z wieloma małymi poleceniami zahaczyć się. Gdy zauważę przeciążenie (rosnące kolejki wysyłania, spowolnienia podczas opróżniania), tymczasowo zmniejszam rozmiary partii lub zwiększam równoległość poprzez wykorzystanie kilku połączeń z mniejszymi potokami, zamiast stosować jeden mega-potok, aby jechać.
RESP3, buforowanie po stronie klienta i pipelining
Dzięki RESP3 i buforowaniu po stronie klienta mogę jeszcze bardziej zmniejszyć obciążenie związane z odczytem ulga, ponieważ serwer wysyła do klienta powiadomienia o unieważnieniu w przypadku zmian. W tym przypadku pipelining nadal się sprawdza: nadal grupuję wiele operacji odczytu, podczas gdy pamięć podręczna obsługuje już część z nich lokalnie. Ważne jest, aby starannie oddzielić powiadomienia push (o unieważnieniu) od strumienia odpowiedzi przetwarzanych w trybie pipeliningu i poprawnie je demultipleksować. W przypadku obciążeń charakteryzujących się dużą liczbą powtarzających się odczytów łączę oba rozwiązania: rozgrzewkę za pomocą potoku, a następnie większość żądań jest obsługiwana z pamięci podręcznej klienta; tylko w przypadku braku trafień lub unieważnionych kluczy żądania trafiają do Redis. W ten sposób liczba cykli round-trip nadal maleje, bez utraty elastyczności potoku zrezygnować.
Określenie i pomiar optymalnej wielkości partii
Odpowiedni rozmiar zależy od opóźnienia, typu zadania, zasobów serwera oraz implementacji klienta; dlatego też systematycznie przeprowadzam pomiary w warunkach rzeczywistego obciążenia i dokonuję oceny Kwantyle. Zamiast skupiać się wyłącznie na wartościach średnich, sprawdzam opóźnienia p95/p99 i obserwuję, od kiedy zaczynają się wydłużać kolejki lub wzrastać liczbę przekroczeń limitu czasu, ponieważ ma to zauważalny wpływ na użytkownika spotkania. Prosta heurystyka: zaczynam od małych wartości, stopniowo je zwiększam i zatrzymuję się, gdy krzywa się spłaszcza lub wartości odstające stają się wyraźnie gorsze. W przypadku ścieżek mieszanych, o ile pozwala na to protokół, rozdzielam pakiety odczytu i zapisu, aby jeszcze bardziej wyrównać przebieg operacji. Konfiguracje projektuję z uwzględnieniem flag funkcji, aby w razie potrzeby móc dokonywać precyzyjnych regulacji w czasie wykonywania i płynnie radzić sobie ze szczytami obciążenia. poduszka.
Integracja ze strategiami buforowania
Kto korzysta z pamięci podręcznej po stronie serwera, zyskuje podwójnie: Redis zapewnia niskie opóźnienia, a potok zmniejsza obciążenie przy wielu operacjach związanych z pamięcią podręczną na Żądanie. Podczas rozgrzewki tworzę duże grupy odczytu, aby pierwszy skok ruchu nie rozpoczynał się „na zimno”, a czasy odpowiedzi szybciej się ustabilizowały; to samo dotyczy zbiorczych unieważnień, które uruchamiam zbiorczo puszka. W przypadku WordPressa, systemów CMS typu headless lub bram API stosuje się Zalety pamięci podręcznej obiektów Dzięki pipeliningowi często widać różnicę między płynną obsługą wielu zapytań o szczegóły a powolnym dodawaniem milisekund. Dbam o to, by nie spowalniać działania skrótów klawiszowych, na przykład przez nadmierne aktualizacje TTL w dużych seriach. Przejrzysta strategia kluczy i spójne wartości TTL zapewniają płynność działania i wysoki współczynnik trafień wysoki.
Działanie i optymalizacja ścieżki sieciowej
Podczas pracy ograniczam do minimum niepotrzebne źródła opóźnień wzdłuż ścieżki: funkcja Keep-Alive oraz realistyczne limity czasu bezczynności na serwerach proxy zapobiegają zrywaniu połączeń podczas długich Kolejki oczekujące. TLS jest dziś standardem; mimo to czerpię korzyści z potoków, ponieważ zmniejsza się liczba uzgodnień i punktów ponownego generowania klucza. Sprawdzam, czy klienci TCP_NODELAY prawidłowo ustawić i sprawdzić, czy wykrywanie MTU/PMTU działa bez zarzutu, aby duże odpowiedzi nie były fragmentowane i opóźniane. W środowiskach kontenerowych zwracam uwagę na dodatkową wirtualizację sieci (overlay, eBPF, CNI), ponieważ łatwo mogą się tu pojawić ukryte przeskoki, które wpływają na kwantyle rozsypywać . Ważniejsza od jednorazowego dostrojenia jest obserwacja w czasie: mapy cieplne opóźnień z kilku dni/tygodni pokazują, czy zmiany przynoszą trwałe korzyści, czy tylko doraźne wygładzać.
Skalowanie w środowiskach chmurowych i kontenerowych
W środowiskach VPC z zaporami sieciowymi, NAT i kanałami bocznymi warto stosować pipelining, ponieważ mniejsza liczba cykli round-trip zmniejsza wpływ dodatkowych przeskoków zmniejszyć. Połączenia między strefami (Cross-AZ) lub między regionami (Cross-Region) tworzę tylko w razie potrzeby; w przeciwnym razie umieszczam klienta i Redis blisko siebie, aby opóźnienia pozostały na akceptowalnym poziomie, a potok danych mógł w pełni wykorzystać swój potencjał rozwija się. W poziomie skaluję czytniki na wielu klientach i utrzymuję połączenia na tyle krótkotrwałe, by w razie zakłóceń były one poprawnie odnawiane bez generowania zalewu ponownych prób. W środowiskach mieszanych porównuję rozwiązania z alternatywami, na przykład Redis kontra Memcached, aby zrozumieć odpowiedni punkt wdrożenia i przewidywane czasy bezczynności. Dokładnie dokumentuję ścieżki sieciowe, ponieważ ukryte urządzenia pośredniczące są często przyczyną rozrzutu opóźnień i przepustowości są.
Strategie postępowania w przypadku błędów i ponownych prób w praktyce
W przypadku scenariuszy błędów rozróżniam trzy kategorie: tymczasowo (przekroczenie limitu czasu, przeciążenie), stały (błąd klawisza/polecenia) oraz topologiczny (przekierowanie klastrowe, przełączanie awaryjne). Próbuję łagodzić skutki błędów tymczasowych za pomocą wykładniczego opóźnienia z dodatnim jitterem i ograniczam całkowity czas trwania, aby użytkownicy nie musieli czekać w nieskończoność. Stałe błędy rejestruję w uporządkowany sposób, zaznaczam dotknięte elementy w partii i kontynuuję przetwarzanie pozostałych wyników, o ile jest to dopuszczalne z technicznego punktu widzenia. W przypadku przekierowań pozostawiam modernim klientom zadanie przekierowania i powtarzam tylko minimalnie niezbędne polecenia, najlepiej idempotentny. Aby zapewnić idempotencję, stosuję unikalne identyfikatory żądań lub wykorzystuję polecenia takie jak SET z parametrami NX/XX i TTL w taki sposób, aby ich powtórzenie nie spowodowało żadnych szkód powoduje. Przypisuję odpowiedzi ściśle do wysłanych poleceń (mapowanie pozycji), dzięki czemu w przypadku częściowych błędów wiem dokładnie, który element należy ponownie na tym jest.
Wskazówki dotyczące wdrażania w popularnych klientach
Szczegóły różnią się w zależności od biblioteki. W języku Python często korzystam z potoków za pomocą transakcja=False, aby uzyskać czyste pakiety transportowe; transakcje włączam tylko w razie potrzeby. W Node.js preferuję klienty obsługujące pipelining wyraźnie obsługiwać i sterować operacją flush (np. gromadzenie danych do następnego taktu pętli zdarzeń lub do osiągnięcia limitu bajtów). W Javie zwracam uwagę na asynchroniczne interfejsy API i multipleksowanie, aby nie być uzależnionym od blokuującego wątku przy każdym opróżnieniu potoku. W Go rozdzielam potok (Pipeline) i TxPipeline, wybierając wariant odpowiedni do pożądanej semantyki. W każdym przypadku sprawdzam, czy strategie automatycznego opróżniania (oparte na czasie lub rozmiarze) pasują do moich obciążeń, i w razie potrzeby dostosowuję je z dużą precyzją do.
Szybsze rozpoznawanie symptomów usterek
Jeśli brakuje wyników lub pojawiają się z opóźnieniem, najpierw sprawdzam kolejkę klienta i czy odpowiedzi są poprawnie odczytywane, ponieważ pipelining z natury rzeczy powoduje, że wiele wyników jest zwracanych seryjnie materiały eksploatacyjne. Wyraźne skoki opóźnienia p99 często wskazują na problemy ze ścieżką sieciową, zbyt duże partie danych lub operacje blokujące w tej samej pętli zdarzeń, dlatego równolegle analizuję logi i metryki poprawny. Ustawiam limity czasu na niskie, ale realistyczne wartości, aby klient mógł szybko znaleźć alternatywę i nie musiał niepotrzebnie czekać. Ponadto w przypadku nieprawidłowości stopniowo zmniejszam wielkość partii, aby sprawdzić, od kiedy wskaźniki ponownie mieszczą się w dobrym przedziale. Te małe kroki pomagają mi zawęzić zakres przyczyn, zamiast zmieniać zbyt wiele parametrów jednocześnie, aby obrócić.
Kiedy pipelining nie przynosi większych korzyści
Pojedyncze duże wartości, których przesłanie wymaga już kilku cykli RTT, nie odnoszą z tego prawie żadnych korzyści; w tym przypadku liczy się przede wszystkim przepustowość. Również nieodpowiednie są ścieżki o ścisłych Zależność krok po kroku, w których każda odpowiedź natychmiast steruje nowymi danymi wejściowymi. W przypadku modelu Pub/Sub stosuję pipelining z umiarem: polecenie SUBSCRIBE przełącza połączenie w specjalny tryb, w którym priorytet mają ciągłe strumienie komunikatów; wysyłanie wielu równoległych poleceń przez tę samą linię rzadko jest tam dobrym pomysłem. W przypadku strumieni (XADD/XREADGROUP) można co prawda grupować operacje, jednak staram się wyraźnie oddzielić stronę producenta od strony konsumenta, aby uniknąć blokad typu „head-to-head” i niejasnych skoków opóźnień, Unikać.
Krótkie podsumowanie
Pipelining łączy niezależne polecenia, ogranicza liczbę cykli komunikacji i wyraźnie przyspiesza działanie aplikacji internetowych, ponieważ mniejsza liczba interakcji sieciowych pozwala na wykonanie większej ilości pracy netto w jednostce czasu włączyć. Stosuję tę technikę wszędzie tam, gdzie występuje wiele drobnych operacji odczytu/zapisu i gdzie przeprowadzam zbiorczą analizę odpowiedzi puszka. Wybór między potokiem a transakcją podejmuję w oparciu o kryteria techniczne: szybkość kontra atomowość – oba te aspekty są wyraźnie rozdzielone i jasno uzasadnione. Dzięki umiarkowanym rozmiarom partii, prawidłowej obsłudze połączeń i konsekwentnemu monitorowaniu utrzymuję szczytowe wartości opóźnień na niskim poziomie, a przepustowość na wysokim. Kto zastosuje się do tych zasad, uzyska większą wydajność z istniejącej infrastruktury bez konieczności przebudowywania aplikacji i zapewni użytkownikom szybsze Reakcje.
