Ontwikkeling

  • Artikel
  • 3 minuten om te lezen

Verbindings resilience en server load

Houd bij het ontwikkelen van clienttoepassingen rekening met de relevante best practices voor verbindings resilience en het beheren van serverbelasting.

Meer sleutels en kleinere waarden overwegen

Azure Cache voor Redis werkt het beste met kleinere waarden. Overweeg grotere delen van gegevens in kleinere segmenten te verdelen om de gegevens over meerdere sleutels te verdelen. Zie dit artikel voor meer informatie over de ideale waardegrootte.

Grote aanvraag- of antwoordgrootte

Een grote aanvraag/reactie kan time-outs veroorzaken. Stel bijvoorbeeld dat uw time-outwaarde die op uw client is geconfigureerd, 1 seconde is. Uw toepassing vraagt tegelijkertijd twee sleutels (bijvoorbeeld 'A' en 'B') aan (met dezelfde fysieke netwerkverbinding). De meeste clients ondersteunen aanvraag 'pipelining', waarbij aanvragen 'A' en 'B' achter elkaar worden verzonden zonder te wachten op hun antwoorden. De server verzendt de antwoorden in dezelfde volgorde terug. Als het antwoord 'A' groot is, kan het de meeste time-out voor latere aanvragen opsnuiten.

In het volgende voorbeeld worden aanvraag 'A' en 'B' snel naar de server verzonden. De server begint snel antwoorden A en B te verzenden. Vanwege tijdstippen voor gegevensoverdracht moet antwoord B wachten achter een A-reactie, ook al heeft de server snel gereageerd.

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

Deze aanvraag/reactie is moeilijk te meten. U kunt uw clientcode instrumenteert om grote aanvragen en antwoorden bij te houden.

Oplossingen voor grote antwoordgrootten zijn verschillend, maar omvatten:

  • Optimaliseer uw toepassing voor een groot aantal kleine waarden in plaats van enkele grote waarden.
  • Vergroot de grootte van uw VM om mogelijkheden voor een hogere bandbreedte te krijgen
    • Meer bandbreedte op uw client- of server-VM kan de gegevensoverdrachttijden voor grotere reacties verminderen.
    • Vergelijk uw huidige netwerkgebruik op beide computers met de limieten van uw huidige VM-grootte. Meer bandbreedte op alleen de server of alleen op de client is mogelijk niet voldoende.
  • Verhoog het aantal verbindingsobjecten dat uw toepassing gebruikt.
    • Gebruik een round robin-benadering om aanvragen te doen via verschillende verbindingsobjecten.

Sleuteldistributie

Als u van plan bent Redis-clustering te gebruiken, leest u eerst Best practices voor Redis-clustering met sleutels.

Pipelining gebruiken

Probeer een Redis-client te kiezen die ondersteuning biedt voor Redis-pipelining. Pipelining helpt efficiënt gebruik te maken van het netwerk en de best mogelijke doorvoer te krijgen.

Dure bewerkingen voorkomen

Sommige Redis-bewerkingen, zoals de opdracht KEYS, zijn duur en moeten worden vermeden. Zie Langlopende opdrachten voor enkele overwegingen met het oog op langlopende opdrachten

Een geschikte laag kiezen

Gebruik Standard of Premium-laag voor productiesystemen. Gebruik niet de basic-laag in productie. De basic-laag is een systeem met één knooppunt zonder gegevensreplicatie en geen SLA. Gebruik minimaal een C1-cache. C0-caches zijn alleen bedoeld voor eenvoudige scenario's voor dev/test, omdat:

  • ze delen een CPU-kern
  • weinig geheugen gebruiken
  • zijn gevoelig voor ruisproblemen

U wordt aangeraden prestatietests uit te voeren om de juiste laag te kiezen en de verbindingsinstellingen te valideren. Zie Prestatietests voor meer informatie.

Client in dezelfde regio als cache

Zoek uw cache-exemplaar en uw toepassing in dezelfde regio. Als er verbinding wordt gemaakt met een cache in een andere regio, kan dit leiden tot een aanzienlijk hogere latentie en kan dit ten koste gaan van de betrouwbaarheid.

Hoewel u verbinding kunt maken van buiten Azure, wordt het niet aanbevolen met name wanneer u Redis als cache gebruikt. Als u Redis-server als een sleutel/waarde-opslag gebruikt, is latentie mogelijk niet het belangrijkste probleem.

TLS-versleuteling gebruiken

Azure Cache voor Redis is standaard versleutelde TLS-communicatie vereist. TLS-versies 1.0, 1.1 en 1.2 worden momenteel ondersteund. TLS 1.0 en 1.1 zijn echter op weg naar afschaffing in de hele branche, dus gebruik indien mogelijk TLS 1.2.

Als uw clientbibliotheek of hulpprogramma geen ondersteuning biedt voor TLS, kunt u niet-versleutelde verbindingen inschakelen via de api's Azure Portal of beheer. In gevallen waarin versleutelde verbindingen niet mogelijk zijn, raden we u aan uw cache en clienttoepassing in een virtueel netwerk te plaatsen. Zie deze tabel voor meer informatie over welke poorten worden gebruikt in het scenario met de cache van het virtuele netwerk.

Clientbibliotheekspecifieke richtlijnen

Volgende stappen