VPN orqali Redis sekin tuyuladi: har bir so'rovdagi aylanishlarni kamaytiring

Mahalliy Redis bilan 200 ms ichida javob beradigan sahifa, mijoz VPN ortida o'tirishi bilan to'rt soniya oladi, server hisoblagichlari esa bo'sh turadi. Slow Log bir millisekunddan yuqori hech narsa ko'rsatmaydi, CPU grafigi tekis va instans boshqa mijozlarga shikoyatsiz xizmat qiladi. O'zgargan narsa masofa, masofani esa ko'paytiruvchi narsa kodingizning to'xtab kutishlar soni. So'rov yo'lini mijozdan tashqariga qarab yuring va tuzatish deyarli har doim tezroq server emas, balki kamroq ketma-ket kutishdir.

Server metrikalaridan emas, mijozdan boshlang

Birinchi buyruq bilan oxirgi buyruq orasida mijoz jarayonini kuzating. Agar iz javob, pauza va keyin keyingi buyruqni ko'rsatsa, siz har bir buyruq uchun to'liq aylanish to'layapsiz va hech qanday server sozlashi buni o'zgartirmaydi. Slow Log bu yerda noto'g'ri asbob, chunki u bajarilish vaqtini yozadi va aloqa I/O'sini ataylab chiqarib tashlaydi. Sekin endpoint yonidagi toza Slow Log aylanish muammosining belgisidir.

Kodga tegishdan oldin yo'lni o'zini o'lchang. redis-cli -h redis.example.internal --latency takroriy PING yuboradi va so'rov hamda javobning o'rtacha vaqtini chiqaradi, bu sizning har bir almashinuv narxingizdir. Uni bitta foydalanuvchi amalidagi ketma-ket buyruqlar soniga ko'paytiring va endpoint uchun pastki chegara olasiz.

Bitta foydalanuvchi amali haqiqatda qancha aylanish talab qilishini sanang

Bitta endpointni oling va har bir Redis chaqiruvini tartib bilan yozing, ORM, session middleware yoki feature flag qidiruvi ichida yashiringanlarini ham. Sekin endpointlarning ko'pchiligi uchta yetadigan joyda yigirma yoki o'ttiz chaqiruv qiladi, yashiringanlari esa odatda ko'pchilikni tashkil qiladi.

Bog'liqlik zanjirini yig'ish mumkin emas: agar ikkinchi buyruqqa birinchisi qaytargan kalit kerak bo'lsa, kutish haqiqiy va yagona variantlar boshqa ma'lumotlar modeli yoki butun qadamni bir zumda ifodalovchi server tomonidagi operatsiya. Mustaqil o'qishlar boshqa holat, chunki ikkinchisini yuborishdan oldin birinchi javobni kutishga hech narsa majburlamaydi. Biror narsani tahrirlashdan oldin har bir chaqiruvni bog'liq yoki mustaqil deb belgilang, tuzatishning shakli ko'rinadi.

Muhim raqam ketma-ket kutishlar, umumiy buyruqlar emas. Bitta batch'dagi o'ttiz buyruq baribir bitta kutishga tushadi.

Faqat bir-biriga bog'liq bo'lmagan buyruqlarni batch qiling

Pipeline mustaqil buyruqlarni navbatga qo'yadi va javoblarni tartib bilan yig'adi, N kutishni bittaga aylantiradi. Ko'pchilik mijozlar uni alohida ulanish rejimi emas, blok, callback yoki context manager sifatida taqdim etadi, shuning uchun o'rnatilgan versiyangiz beradigan API'ni tekshiring. Foyda aylanish vaqti bilan o'sadi, shuning uchun VPN'da muhim va localhost'da deyarli sezilmaydi.

import redis

r = redis.Redis(host="redis.example.internal", port=6379, socket_timeout=2)
pipe = r.pipeline(transaction=False)
for key in ("user:1001", "user:1002", "user:1003"):
    pipe.get(key)
print(pipe.execute())

Faqat batching kerak bo'lganda transaction=False ni bering. Standart sozlamada mijoz batch'ni MULTI va EXEC ichiga o'raydi, bu uni atomar qiladi va boshqa mijozlar parvoz paytida nima ko'rishini o'zgartiradi. Atomarlik bu ishlash tugmasi emas, to'g'rilik qarori, va pipeline ikkalasi ham aylanishlarni kamaytirgani uchun tranzaksiya emas.

Har bir javobni o'qing, faqat batch topshirig'ini emas. Navbatdagi buyruq batch umuman tugayotganda xato qaytarishi mumkin, javoblar ro'yxatini tashlab yuborgan mijoz esa muvaffaqiyatsiz yozuvni jim yozuvga aylantiradi. Javoblar ro'yxati uzunligini navbatga qo'ygan buyruqlaringiz soni bilan solishtiring.

Ulanishni amallar orasida tirik tuting

Har bir yangi ulanish nomni aniqlash, TCP handshake, TLS handshake va AUTH uchun to'laydi, VPN ustida esa ularning har biri batch qilib bo'lmaydigan aylanishdir. Mijozni jarayon boshiga bir marta yarating va qayta ishlating, yoki kutubxonangiz taqdim etadigan pool'ni cheklangan hajm bilan ishlating. Har bir so'rov uchun qayta ulanish bu belgining har bir buyruq kutishidan keyingi ikkinchi eng keng tarqalgan sababidir.

Maxfiy hostname'ni sozlamada saqlang, to'g'ridan-to'g'ri manzil sifatida emas. Sertifikat tekshiruvi va xizmat identifikatsiyasi xususiy tarmoqda ham amal qiladi, IP'ni qotirib qo'yish esa provayder subnet'ni qayta raqamlagan zahoti buziladi. Agar sekin qism nomni aniqlash bo'lsa, ulanish satri emas, resolver yo'lini tuzating.

Tiqilib qolgan tunnel worker'ni osib qo'yish o'rniga tez yiqilishi uchun aniq socket timeout belgilang. Keyin mijozda ulanish yaratilishini jurnalga yozib, pool haqiqatan qayta ishlatilishini tasdiqlang.

Batch hajmini xotira muammosiga aylanishidan oldin o'lchab oling

Redis navbatdagi javoblarni batch davomida ushlab turadi, mijoz esa keyin tahlil qilingan natijani ushlab turadi. O'n ming katta qiymatdan iborat pipeline tarmoq kutishlarini xotira sakrashlari va ikkala uchda uzoq pauzalar bilan almashtiradi.

Batch hajmini buyruqlar soniga emas, javoblar hajmiga qarab tanlang. Bitta batch'da bir necha yuz kichik buyruq odatda qulay, yuzlab ko'p kilobaytli payload esa emas. Baytlar va son bo'yicha ham bo'ling, har bir batch'ni endpoint haqiqatan ega bo'lgan kechikish byudjeti ichida tuting.

O'zgarishdan keyin boshidan oxirigacha o'lchang: redis-cli -h redis.example.internal --latency-history yo'lning o'zi barqarorligini ko'rsatadi, o'z so'rov taymeringiz esa endpoint yaxshilanganini ko'rsatadi. Agar endpoint hali ham sekin bo'lsa-yu kechikish tarixi tekis bo'lsa, qolgan xarajat server tomonidagi ish yoki sizning serializatsiyangiz, keyingi qadam esa batch'ning yana bir o'zgarishi emas, handler profilidir.