Vývoj

  • Článek
  • 3 min ke čtení

Odolnost připojení a zatížení serveru

Při vývoji klientských aplikací nezapomeňte vzít v úvahu příslušné osvědčené postupy pro odolnost připojení a správu zatížení serveru.

Zvažte více klíčů a menších hodnot.

Azure Cache for Redis s menšími hodnotami funguje nejlépe. Zvažte rozdělení větších bloků dat do menších bloků dat, aby se data rozdělla do více klíčů. Další informace o ideální velikosti hodnoty najdete v tomto článku.

Velká velikost požadavku nebo odpovědi

Velký požadavek/odpověď může způsobit časové limity. Předpokládejme například, že hodnota časového limitu nakonfigurovaná na klientovi je 1 sekunda. Vaše aplikace požaduje dva klíče (například "A" a "B") současně (pomocí stejného fyzického síťového připojení). Většina klientů podporuje požadavek "pipelining", kdy se požadavky A i B odesílají jeden po druhém, aniž by se čekalo na jejich odpovědi. Server odešle odpovědi zpět ve stejném pořadí. Pokud je odpověď "A" velká, může většinu časového limitu vyžádá pro pozdější požadavky.

V následujícím příkladu se na server rychle posílají požadavky A a B. Server začne rychle odesílat odpovědi "A" a "B". Z důvodu doby přenosu dat musí odpověď "B" čekat za odezvou "A", i když server odpověděl rychle.

|-------- 1 Second Timeout (A)----------|
|-Request A-|
     |-------- 1 Second Timeout (B) ----------|
     |-Request B-|
            |- Read Response A --------|
                                       |- Read Response B-| (**TIMEOUT**)

Tento požadavek a odpověď je obtížné změřit. Kód klienta můžete instrumentovat tak, aby sledoval velké požadavky a odpovědi.

Řešení pro velké velikosti odpovědí se liší, ale zahrnují:

  • Optimalizujte aplikaci pro velký počet malých hodnot, nikoli několik velkých hodnot.
  • Zvětšením velikosti virtuálního počítače získáte možnosti větší šířky pásma.
    • Větší šířka pásma na virtuálním počítači klienta nebo serveru může zkrátit dobu přenosu dat u větších odpovědí.
    • Porovnejte aktuální využití sítě na obou počítačích s limity vaší aktuální velikosti virtuálního počítače. Větší šířka pásma jenom na serveru nebo jenom na klientovi nemusí stačit.
  • Zvyšte počet objektů připojení, které vaše aplikace používá.
    • Pomocí kruhového dotazování můžete provádět požadavky na různé objekty připojení.

Distribuce klíčů

Pokud plánujete používat clustering Redis, přečtěte si nejprve osvědčené postupy clusteringu Redis s klíči.

Použití pipeliningu

Zkuste zvolit klienta Redis, který podporuje pipelining Redis. Pipelining pomáhá efektivně využívat síť a zajistit co nejlepší propustnost.

Vyhněte se nákladných operacím

Některé operace Redis, jako je příkaz KEYS, jsou nákladné a měli byste se jim vyhnout. Informace o dlouhotr běžících příkazech najdete v tématu o dlouhotr běžících příkazech.

Zvolte vhodnou úroveň.

Pro produkční systémy Premium úroveň Standard nebo Standard. V produkčním prostředí nepoužívejte úroveň Basic. Úroveň Basic je systém s jedním uzlem bez replikace dat a bez smlouvy SLA. Jako mezipaměť použijte aspoň C1. Mezipaměti C0 jsou určeny pouze pro jednoduché scénáře vývoje a testování, protože:

  • Sdílejí jádro procesoru.
  • použití malé paměti
  • jsou náchylné k problémům s hlučným sousedem

Doporučujeme testování výkonnosti, abyste zvolili správnou úroveň a ověřili nastavení připojení. Další informace najdete v tématu Testování výkonnosti.

Klient ve stejné oblasti jako mezipaměť

Vyhledejte instanci mezipaměti a aplikaci ve stejné oblasti. Pokud byste se připojovali k mezipaměti v jiné oblasti, výrazně byste tím zvýšili latenci a snížili spolehlivost.

I když se můžete připojit z oblasti mimo Azure, nedoporučuje se to zejména při použití Redis jako mezipaměti. Pokud jako úložiště typu klíč/hodnota používáte server Redis, latence nemusí být hlavní obavou.

Použití šifrování TLS

Azure Cache for Redis vyžaduje ve výchozím nastavení šifrovanou komunikaci TLS. Aktuálně se podporují protokoly TLS verze 1.0, 1.1 a 1.2. Protokoly TLS 1.0 a 1.1 se však na cestě k vymazávání v celém oboru nachází, proto pokud je to možné, použijte protokol TLS 1.2.

Pokud vaše klientská knihovna nebo nástroj protokol TLS nepodporuje, je možné povolit nešifrovaná připojení prostřednictvím rozhraní API Azure Portal správy. V případech, kdy šifrovaná připojení nejsou možná, doporučujeme umístit mezipaměť a klientskou aplikaci do virtuální sítě. Další informace o tom, které porty se používají ve scénáři mezipaměti virtuální sítě, najdete v této tabulce.

Pokyny pro konkrétní klientskou knihovnu

Další kroky