Szerkesztés

Share via


Azure Cache for Redis – kezeléssel kapcsolatos GYIK

Ez a cikk a Azure Cache for Redis kezelésével kapcsolatos gyakori kérdésekre ad választ.

Mikor érdemes engedélyezni a nem TLS-/SSL-portot a Redishez való csatlakozáshoz?

A Redis-kiszolgáló natív módon nem támogatja a TLS-t, de Azure Cache for Redis igen. Ha Azure Cache for Redis csatlakozik, és az ügyfél támogatja a TLS-t (például StackExchange.Redis), akkor használja a TLS-t.

Megjegyzés

A nem TLS-port alapértelmezés szerint le van tiltva az új Azure Cache for Redis példányok esetében. Ha az ügyfél nem támogatja a TLS-t, akkor engedélyeznie kell a nem TLS-portot a Gyorsítótár konfigurálása Azure Cache for Redis cikkben található Access-portok szakasz útmutatásait követve.

A Redis-eszközök, például redis-cli nem működnek a TLS-porttal, de egy olyan segédprogrammal, mint például stunnel az eszközök biztonságos csatlakoztatása a TLS-porthoz, a Redis előzetes kiadásának bejelentése ASP.NET Munkamenetállapot-szolgáltató előzetes kiadásához című blogbejegyzés útmutatásait követve.

A Redis-eszközök letöltésével kapcsolatos utasításokért lásd a Hogyan futtathatom a Redis-parancsokat? című szakaszt .

Mik az éles környezetben ajánlott eljárások?

A StackExchange.Redis ajánlott eljárásai

  • Állítsa hamis AbortConnect értékre, majd hagyja, hogy a ConnectionMultiplexer automatikusan újracsatlakozjon.
  • Használjon egyetlen, hosszú élettartamú ConnectionMultiplexer példányt ahelyett, hogy minden kéréshez új kapcsolatot hoz létre. A kapcsolat kezeléséről a Csatlakozás a RedisConnectiongyorsítótárhoz Újrakapcsolattal című témakörben talál példát.
  • A Redis kisebb értékekkel működik a legjobban, ezért fontolja meg a nagyobb adatok több kulcsba való feldarabolását. Ebben a Redis-vitafórumban a 100 kb nagynak számít. További információ: Ajánlott eljárások fejlesztése.
  • Konfigurálja a ThreadPool beállításait az időtúllépések elkerülése érdekében.
  • Használjon legalább 5 másodperces alapértelmezett connectTimeout értéket. Ez az időköz elegendő időt ad a StackExchange.Redis számára a kapcsolat újbóli létrehozásához, ha van hálózati pont.
  • Vegye figyelembe a különböző futtatott műveletekhez kapcsolódó teljesítményköltségeket. A parancs például KEYS egy O(n) művelet, amelyet el kell kerülni. A redis.io webhely részletes információkat tartalmaz az egyes támogatott műveletek időbeli összetettségéről. Válassza ki az egyes parancsokat az egyes műveletek összetettségének megtekintéséhez.

Konfiguráció és fogalmak

  • Használja a standard vagy prémium szintű éles rendszereket. Az Alapszint egyetlen csomópontot tartalmaz adatreplikáció nélkül, és SLA sem tartozik hozzá. Ezen kívül használjon legalább C1 szintű gyorsítótárat. A C0-gyorsítótárakat általában egyszerű fejlesztési/tesztelési forgatókönyvekhez használják.
  • Ne feledje, hogy a Redis egy memóriabeli adattár. További információ: Adatvesztés elhárítása Azure Cache for Redis, hogy tisztában legyen az adatvesztéssel kapcsolatos forgatókönyvekkel.
  • Úgy fejlesztheti a rendszert, hogy kezelni tudja a javítás és a feladatátvétel által okozott kapcsolati hibákat.

Teljesítménytesztelés

  • Első lépésként redis-benchmark.exe használja a lehetőséget a lehetséges átviteli sebességre, mielőtt saját perf teszteket ír. Mivel redis-benchmark nem támogatja a TLS-t, a teszt futtatása előtt engedélyeznie kell a nem TLS-portot a Azure Portal. Példák: Hogyan mérhetem és tesztelhetem a gyorsítótáram teljesítményét?
  • A teszteléshez használt ügyfél virtuális gépnek ugyanabban a régióban kell lennie, mint a Azure Cache for Redis példánynak.
  • Javasoljuk, hogy a Dv2 virtuálisgép-sorozatot használja az ügyfélhez, mivel jobb hardverrel rendelkeznek, és a legjobb eredményt kell adniuk.
  • Győződjön meg arról, hogy a választott ügyfél virtuális gép legalább annyi számítási és sávszélesség-képességgel rendelkezik, mint a tesztelt gyorsítótár.
  • Ha Windows rendszeren van, engedélyezze a VRSS-t az ügyfélszámítógépen. A részleteket itt találja.
  • A prémium szintű Redis-példányok jobb hálózati késéssel és átviteli sebességgel rendelkeznek, mert jobb hardveren futnak mind a PROCESSZOR, mind a hálózat számára.

Milyen szempontokat érdemes figyelembe venni a gyakori Redis-parancsok használatakor?

  • Ne használjon olyan Redis-parancsokat, amelyek végrehajtása hosszú időt vesz igénybe, hacsak nem ismeri teljes mértékben ezeknek a parancsoknak az eredményét. Például ne futtassa a KEYS parancsot éles környezetben. A kulcsok számától függően hosszú időt vehet igénybe a visszatérés. A Redis egy egyszálas kiszolgáló, és egyenként dolgozza fel a parancsokat. Ha a KULCSok után más parancsok is ki vannak adva, azok csak akkor lesznek feldolgozva, ha a Redis feldolgozza a KEYS parancsot. A redis.io webhely részletes információkat tartalmaz az egyes támogatott műveletek időbeli összetettségéről. Válassza ki az egyes parancsokat az egyes műveletek összetettségének megtekintéséhez.
  • Kulcsméretek – használjon kis kulcsokat/értékeket vagy nagy kulcsokat/értékeket? Ez a forgatókönyvtől függ. Ha a forgatókönyvben nagyobb kulcsok szükségesek, módosíthatja a ConnectionTimeoutot, majd újrapróbálkozhat az értékekkel, és módosíthatja az újrapróbálkozási logikát. A Redis-kiszolgáló szempontjából a kisebb értékek jobb teljesítményt biztosítanak.
  • Ezek a szempontok nem jelentik azt, hogy nem tárolhat nagyobb értékeket a Redisben; tisztában kell lennie a következő szempontokkal. A késések magasabbak lesznek. Ha egy nagyobb és egy kisebb adatkészlettel rendelkezik, több ConnectionMultiplexer-példányt is használhat. Konfigurálja mindegyiket különböző időtúllépési és újrapróbálkozási értékekkel, az előző Mit tesz a StackExchange.Redis konfigurációs beállításai című szakaszban leírtak szerint.

Hogyan mérhetem és tesztelhetem a gyorsítótáram teljesítményét?

  • Engedélyezze a gyorsítótár-diagnosztikát, hogy megfigyelhesse a gyorsítótár állapotát. Megtekintheti a metrikákat a Azure Portal, és letöltheti és áttekintheti őket a választott eszközökkel.
  • Az redis-benchmark.exe használatával betöltheti a Redis-kiszolgáló tesztelését.
  • Győződjön meg arról, hogy a terheléstesztelési ügyfél és a Azure Cache for Redis ugyanabban a régióban vannak.
  • Használja redis-cli.exe, és figyelje a gyorsítótárat az INFO paranccsal.
  • Ha a terhelés nagy memóriatöredezettséget okoz, nagyobb gyorsítótárméretre kell skáláznia.
  • A Redis-eszközök letöltésével kapcsolatos utasításokért lásd a Hogyan futtathatom a Redis-parancsokat? című szakaszt .

Íme néhány példa a redis-benchmark.exe használatára. Futtassa ezeket a parancsokat a gyorsítótárral azonos régióban lévő virtuális gépről a pontos eredmények érdekében.cache-development-faq.yml

  • Folyamatalapú SET-kérések tesztelése 1k hasznos adat használatával

    redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t SET -n 1000000 -d 1024 -P 50

  • Tesztelje a folyamatalapú GET-kérelmeket egy 1k hasznos adat használatával.

Megjegyzés

A gyorsítótár feltöltéséhez futtassa a fent látható SET tesztet

redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t GET -n 1000000 -d 1024 -P 50

A szálkészlet növekedésével kapcsolatos fontos részletek

A CLR ThreadPool két száltípussal rendelkezik: "Feldolgozó" és "I/O befejezési port" (IOCP) szálak.

  • A munkavégző szálak olyan dolgokhoz használatosak, mint a , vagy ThreadPool.QueueUserWorkItem(…) a Task.Run(…)metódusok feldolgozása. Ezeket a szálakat a CLR különböző összetevői is használják, amikor háttérszálon kell dolgozni.
  • Az IOCP-szálak akkor használatosak, amikor aszinkron I/O történik, például a hálózatról való olvasáskor.

A szálkészlet igény szerint (szabályozás nélkül) új feldolgozószálakat vagy I/O-befejezési szálakat biztosít, amíg el nem éri az egyes száltípusok "Minimum" beállítását. Alapértelmezés szerint a szálak minimális száma a rendszeren lévő processzorok számára van beállítva.

Ha a meglévő (foglalt) szálak száma eléri a szálak "minimális" számát, a ThreadPool 500 ezredmásodpercenként egy szálba injektálja az új szálakat. Ha a rendszer általában egy IOCP-szálra szoruló munkacsúcsot kap, az gyorsan feldolgozható lesz. Ha azonban a teljesítménycsúcs nagyobb, mint a konfigurált "Minimum" beállítás, a munka egy részének feldolgozása késik, mivel a ThreadPool a két lehetőség egyikére vár:

  • Egy meglévő szál szabadon feldolgozhatja a munkát.
  • Egyetlen meglévő szál sem lesz ingyenes 500 ms-ra, és létrejön egy új szál.

Alapvetően, ha a foglalt szálak száma nagyobb, mint a Min szál, valószínűleg 500 ms késleltetést fizet, mielőtt az alkalmazás feldolgozta a hálózati forgalmat. Továbbá, ha egy meglévő szál 15 másodpercnél hosszabb ideig tétlen marad, az törlődik, és ez a növekedési és zsugorodási ciklus megismétlhető.

Ha a StackExchange.Redis (1.0.450-ös vagy újabb build) egy példa hibaüzenetét vizsgáljuk meg, azt látjuk, hogy most már a ThreadPool statisztikáit nyomtatja. Lásd alább az IOCP és a WORKER adatait.

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

Ahogy a példában látható, az IOCP-szál esetében hat elfoglalt szál van, és a rendszer úgy van konfigurálva, hogy négy minimális szálat engedélyezzen. Ebben az esetben az ügyfél valószínűleg két 500 ms-os késést észlelt volna, mert 6 > 4.

Megjegyzés

A StackExchange.Redis időtúllépéseket okozhat, ha az IOCP- vagy a WORKER-szálak növekedése szabályozva lesz.

Ajánlás

Ezen információk alapján határozottan javasoljuk, hogy az ügyfelek az IOCP- és WORKER-szálak minimális konfigurációs értékét az alapértelmezett értéknél nagyobb értékre állítsa. Nem adhatunk egy méretre illeszkedő útmutatást arról, hogy mi legyen ennek az értéknek az értéke, mert az egyik alkalmazás megfelelő értéke valószínűleg túl magas vagy alacsony lesz egy másik alkalmazáshoz. Ez a beállítás hatással lehet a bonyolult alkalmazások más részeinek teljesítményére is, így minden ügyfélnek finomhangolnia kell ezt a beállítást az igényeiknek megfelelően. Egy jó kiindulási hely 200 vagy 300, majd tesztelje és finomhangolni, ha szükséges.

A beállítás konfigurálása:

  • Azt javasoljuk, hogy programozott módon módosítsa ezt a beállítást a ThreadPool.SetMinThreads (...) metódus használatával a fájlban global.asax.cs. Például:

    private readonly int minThreads = 200;
    void Application_Start(object sender, EventArgs e)
    {
        // Code that runs on application startup
        AreaRegistration.RegisterAllAreas();
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        ThreadPool.SetMinThreads(minThreads, minThreads);
    }
    

    Megjegyzés

    A metódus által megadott érték egy globális beállítás, amely a teljes AppDomaint érinti. Ha például egy négymagos géppel rendelkezik, és a minWorkerThreads és a minIoThreads 50-et szeretne beállítani processzoronként futásidőben, használja a ThreadPool.SetMinThreads(200, 200) parancsot.

  • A minimális szálbeállítást a minIoThreads vagy a minWorkerThreads konfigurációs beállítással is megadhatja a <processModel> () konfigurációs elemében.Machine.config Machine.config általában a következő helyen található: %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\. A minimális szálak számának ilyen módon történő beállítása nem ajánlott, mert rendszerszintű beállítás.

    Megjegyzés

    Az ebben a konfigurációs elemben megadott érték egy magonkénti beállítás. Ha például egy 4 magos géppel rendelkezik, és azt szeretné, hogy a minIoThreads beállítás futásidőben 200 legyen, használja a következőt <processModel minIoThreads="50"/>: .

Engedélyezze a kiszolgálói GC-t, hogy több átviteli sebességet kapjon az ügyfélen a StackExchange.Redis használatakor

A kiszolgálói GC engedélyezése optimalizálhatja az ügyfelet, és jobb teljesítményt és átviteli sebességet biztosíthat a StackExchange.Redis használatakor. A kiszolgálói csoportházirend-objektumról és annak engedélyezéséről az alábbi cikkekben talál további információt:

A kapcsolatok teljesítményével kapcsolatos megfontolandó szempontok

Minden tarifacsomag különböző korlátozásokkal rendelkezik az ügyfélkapcsolatokra, a memóriára és a sávszélességre vonatkozóan. Bár a gyorsítótár minden mérete legfeljebb néhány kapcsolatot tesz lehetővé, a Redishez való minden kapcsolat többletterheléssel jár. Ilyen többletterhelés lehet például a processzor- és memóriahasználat a TLS/SSL-titkosítás miatt. Az adott gyorsítótárméret maximális kapcsolati korlátja enyhén betöltött gyorsítótárat feltételez. Ha a kapcsolat többletterhelése és az ügyfélműveletek terhelése meghaladja a rendszer kapacitását, a gyorsítótár akkor is kapacitásproblémákat tapasztalhat, ha nem lépte túl az aktuális gyorsítótárméret csatlakozási korlátját.

További információ az egyes szintek különböző kapcsolati korlátairól: Azure Cache for Redis díjszabás. További információ a kapcsolatokról és az egyéb alapértelmezett konfigurációkról: Alapértelmezett Redis-kiszolgáló konfigurációja.

Következő lépések

További Azure Cache for Redis gyakori kérdések.