Velký port má hodnotu jen tehdy, když jej aplikace, úložiště, procesor, síťová cesta a příjemci dokážou využít. Naplánujte pracovní sadu a souběžnost, změřte každou omezující fázi a definujte provozní hranice. Označení katalogu 40, 100 a 200 Gbps jsou třídy portů, nikoli univerzální záruky přenosu nebo dostupnosti.
Převeďte port na datové měřítko
U desítkových jednotek odpovídají 40, 100 a 200 Gbps aritmetice přenosové rychlosti 5, 12.5 a 25 GB za sekundu. Jde o referenční převody před vlivem protokolu a implementace. Popisují měřítko okolního návrhu, nikoli naměřenou rychlost nebo příslib, že origin dodá takové množství obsahu aplikace.
U distribučního projektu odhadněte souběžné požadavky, velikosti objektů a pracovní sadu. Služba opakovaně doručující malou oblíbenou sadu se liší od služby streamující necachované archivy. Předpoklady vyslovte výslovně. Velký port zakoupený bez těchto předpokladů může ponechat limity úložiště, aplikace nebo příjemců nedotčené, zatímco zvýší opakující se náklady projektu.
| Uvedená třída portu | Hrubý desítkový převod | Důsledek pro plánování |
|---|---|---|
| 40 Gbps | 5 GB/s před režií | Změřte cestu obsahu a aplikace |
| 100 Gbps | 12.5 GB/s před režií | Prozkoumejte úložiště, souběžnost a zpracování |
| 200 Gbps | 25 GB/s před režií | Ověřte každou fázi a kapacitu příjmu |
Modelujte pracovní sadu a chování cache
Určete, který obsah je požadován často a který se musí načítat z úložiště na vyžádání. Teplá cache může poskytnout výsledek, který studený start nedokáže udržet. Otestujte oba stavy, když na nich projektu záleží. Udržujte datovou sadu dostatečně velkou a realistickou, aby měření odpovědělo na otázku, kterou skutečně potřebujete vyřešit.
Představte si zákonný origin pro stahování softwaru s oblíbenými vydáními a starším archivem. Porovnejte rušné okno vydání s běžným přístupem k archivu. Rezervujte kapacitu pro publikování, generování kontrolních součtů a záložní provoz tam, kde se tyto operace překrývají. Tento původní scénář poskytuje rámec pro plánování; neurčuje, že by nějaký konkrétní hardware nebo služba cache byla součástí SwissOctet.
Měřte úložiště nezávisle
Začněte měřením úložných operací, které aplikace provádí. Sekvenční čtení velkých souborů a mnoho malých náhodných čtení může odhalit různé limity. Dokumentace fio popisuje parametry zátěže, které mohou tyto vzory reprezentovat. Použijte řízené testovací soubory a nastavení, která vyhovují systému, a vyhněte se destruktivním testům na produkčních datech.
Zaznamenejte rozložení úložiště, velikost datové sady a testovací podmínky. Benchmark zahrnující cachovaná data není ekvivalentní trvalému čtení ze základních zařízení. Poté jej zopakujte se skutečnou cestou obsahu aplikace. Větší kapacita automaticky nezvyšuje rychlost doručování a několik vybraných disků neurčuje konkrétní uspořádání pole ani naměřenou propustnost.
Sledujte limity procesoru a front
Při vysokých přenosových rychlostech může vedle využití CPU aplikací záležet i na zpracování a obsluze přerušení. Linux dokumentuje škálování na straně příjmu a související mechanismy pro rozdělení síťové práce mezi fronty a procesory. Jejich přítomnost a chování závisí na hardwaru a konfiguraci. Použijte tyto dokumenty k interpretaci měření, místo abyste na každý server aplikovali obecný postup ladění.
Sledujte, zda se jeden CPU, pracovník nebo fronta příjmu nezaneprázdní dříve než agregovaný systém. Zahrňte do testu šifrování, kompresi a zpracování požadavků, když je produkční služba používá. Nečinný průměrný údaj CPU může skrývat nasycenou komponentu. Měňte vždy jeden faktor a zachovejte základní měření, aby byl účinek srozumitelný.
Ověřte aplikaci poskytující obsah
Server musí dělat více než přesouvat bajty v síťovém benchmarku. Ověřte připojení, parsování požadavků, autorizaci, čtení obsahu a dokončení odpovědi se zamýšleným softwarem. Nginx dokumentuje ovládání přenosu souborů a připojení pro vlastní implementaci; jiný software má různá nastavení. Přečtěte si dokumentaci pro skutečnou verzi, kterou budete provozovat.
Testujte realistickou souběžnost a sledujte jak agregovaný výstup, tak doby dokončení v ocasu. Velké agregované číslo může existovat společně s jednotlivými požadavky, které vyprší. Stanovte limit, při kterém se služba stále chová přijatelně, a poté ponechte provozní rezervu, místo abyste se snažili provozovat každou komponentu po celý den na jejím teoretickém maximu.
Porovnejte skutečné specifikace Transit
Rodiny Transit od SwissOctet zachovávají zemi Švýcarsko, ale uvádějí různé základy procesoru, paměti a úložiště. Přečtěte si přesný plán: Transit 100 uvádí úložiště SSD, zatímco jiné základní specifikace Transit uvádějí NVMe. Další možnosti disku mají vlastní označení. Nenechte třídu portu nahradit kontrolu zbytku konfigurace.
Také si u skutečné služby potvrďte dostupnost, podmínky provozu, administrativní odpovědnosti a proces obnovy. Neomezený provoz popisuje model provozu, nikoli povolení k libovolné aktivitě nebo příslib dostupnosti. Zátěže s velkým objemem potřebují jasné provozní podmínky a práva distribuovat obsah, stejně jako ty menší.
Připravte provoz před otevřením provozu
Definujte, kdo může publikovat obsah, měnit konfiguraci a spravovat origin. Chraňte tato rozhraní, shromažďujte užitečná provozní měření a nastavte prahové hodnoty pro přetížení. Ponechte si způsob, jak snížit provoz nebo vrátit vydání zpět, pokud se aplikace chová neočekávaně. Velké rozhraní může zesílit důsledky běžné softwarové nebo přístupové chyby.
Proveďte postupně naplánované cvičení s autorizovanými příjemci a dohodnutými limity a poté zvyšujte směrem k plánované zátěži. Uchovejte výsledky, nezodpovězené otázky a rezervu prostředků v záznamu o nasazení. Větší port zvolte jen tehdy, když to tento důkaz podporuje; kompletní, změřený návrh je užitečnější než největší číslo dostupné v katalogu.
Váš praktický kontrolní seznam.
- Převeďte třídu portu, aniž byste ji považovali za doručování užitečného zatížení.
- Modelujte zásahy cache, studená čtení a souběžné požadavky.
- Proveďte benchmark úložiště s neškodnými testovacími daty.
- Sledujte CPU, pracovníky a síťové fronty.
- Otestujte aplikaci poskytující obsah a kapacitu příjemců.
- Nasaďte provoz postupně a zachovejte postup pro vrácení zpět.
Podrobnosti, na kterých záleží.
Je největší port vždy nejbezpečnější volbou?+
Ne. Vycházejte z naměřené poptávky a limitů kompletního systému. Větší port nevyřeší nedostatečné úložiště, procesor nebo kapacitu aplikace.
Používá každá rodina Transit NVMe?+
Ne. Přečtěte si skutečný plán. Základní specifikace Transit 100 uvádí SSD; jiné základní plány a možnosti dalších disků mají vlastní popisy.
Proč testovat se studenými daty i s cachovanými daty?+
Odhalují různé provozní podmínky. Vydání, restart nebo měnící se pracovní sada mohou vyvolat úložnou aktivitu, které se benchmark s teplou cache vyhne.
Jděte ke zdroji.
Tyto zdroje podporují technické koncepty v tomto průvodci. Před změnou produkčního systému se řiďte aktuální dokumentací.
- Jádro Linux: Škálování v síťovém zásobníku docs.kernel.org
- fio: Dokumentace zátěže a měření fio.readthedocs.io
- Nginx: Základní modul HTTP nginx.org
Redakční vedení od SwissOctet. Příklady jsou ilustrativní. Specifikace služeb, dostupné možnosti a smluvní podmínky je nutné ověřit samostatně.