VPN வழியாக Redis மெதுவாகத் தோன்றுகிறது: ஒரு கோரிக்கைக்கான சுற்றுப்பயணங்களைக் குறைக்கவும்

உள்ளூர் Redis-க்கு எதிராக 200 ms-ல் பதிலளிக்கும் பக்கம், கிளையண்ட் VPN-க்குப் பின்னால் அமர்ந்தவுடன் நான்கு வினாடிகள் எடுக்கிறது, அதே நேரத்தில் சேவையகத்தின் கணக்குகள் சும்மா இருக்கின்றன. Slow Log ஒரு மில்லி வினாடிக்கு மேல் எதையும் காட்டவில்லை, CPU வரைபடம் தட்டையானது, மேலும் இன்ஸ்டன்ஸ் மற்ற கிளையண்டுகளுக்கு குறையின்றி சேவை செய்கிறது. மாறியது தூரம், தூரத்தைப் பெருக்குவது உங்கள் குறியீடு நின்று காத்திருக்கும் முறைகளின் எண்ணிக்கை. கோரிக்கையின் பாதையை கிளையண்டிலிருந்து வெளியே நடந்து பாருங்கள், திருத்தம் எப்போதும் கிட்டத்தட்ட வேகமான சேவையகம் அல்ல, குறைவான தொடர்ச்சியான காத்திருப்புகளே.

சேவையக அளவீடுகளிலிருந்து அல்ல, கிளையண்டிலிருந்து தொடங்குங்கள்

முதல் கட்டளைக்கும் கடைசி கட்டளைக்கும் இடையில் கிளையண்ட் செயல்முறையைப் பாருங்கள். தடயம் ஒரு பதிலையும், ஒரு இடைவெளியையும், பிறகு அடுத்த கட்டளையையும் காட்டினால், ஒவ்வொரு கட்டளைக்கும் முழு சுற்றுப்பயணத்தைச் செலுத்துகிறீர்கள், எந்த சேவையக சீரமைப்பும் அதை மாற்றாது. Slow Log இங்கே தவறான கருவி, ஏனெனில் அது இயக்க நேரத்தைப் பதிவு செய்கிறது, தொடர்பு I/O-ஐ வேண்டுமென்றே விலக்குகிறது. மெதுவான endpoint-க்கு அருகில் தூய்மையான Slow Log இருப்பது சுற்றுப்பயணச் சிக்கலின் அடையாளம்.

குறியீட்டைத் தொடும் முன் பாதையையே அளவிடுங்கள். redis-cli -h redis.example.internal --latency மீண்டும் மீண்டும் PING அனுப்பி கோரிக்கை மற்றும் பதிலின் சராசரி நேரத்தை அச்சிடுகிறது, அதுதான் ஒரு பரிமாற்றத்திற்கான உங்கள் செலவு. அதை ஒரு பயனர் செயலில் உள்ள தொடர்ச்சியான கட்டளைகளின் எண்ணிக்கையால் பெருக்குங்கள், endpoint-க்கு ஒரு அடிமட்டம் கிடைக்கும்.

ஒரு பயனர் செயலுக்கு உண்மையில் எத்தனை சுற்றுப்பயணங்கள் தேவை என்பதை எண்ணுங்கள்

ஒரு endpoint எடுத்து ஒவ்வொரு Redis அழைப்பையும் வரிசையாக எழுதுங்கள், ORM, session middleware அல்லது feature flag தேடலுக்குள் மறைந்திருப்பவை உட்பட. பெரும்பாலான மெதுவான endpoint மூன்று போதுமான இடத்தில் இருபது அல்லது முப்பது அழைப்புகள் செய்கின்றன, மறைந்தவை பொதுவாக பெரும்பான்மையாக இருக்கும்.

சார்புச் சங்கிலியை ஒன்றாகச் சுருக்க முடியாது: இரண்டாவது கட்டளைக்கு முதல் திருப்பிய அளவுகோல் தேவைப்பட்டால், காத்திருப்பு உண்மையானது, ஒரே வழிகள் வேறு தரவு மாதிரி அல்லது முழு படிநிலையையும் ஒரே நேரத்தில் வெளிப்படுத்தும் சேவையகப் பக்கம் செயல். சுயாதீன வாசிப்புகள் வேறு நிலை, ஏனெனில் இரண்டாவதை அனுப்பும் முன் முதல் பதிலுக்குக் காத்திருக்க எதுவும் உங்களை கட்டாயப்படுத்தாது. எதையும் திருத்தும் முன் ஒவ்வொரு அழைப்பையும் சார்ந்தது அல்லது சுயாதீனம் எனக் குறியுங்கள், திருத்தத்தின் வடிவம் தெளிவாகும்.

முக்கியமான எண் தொடர்ச்சியான காத்திருப்புகள், மொத்த கட்டளைகள் அல்ல. ஒரு batch-ல் முப்பது கட்டளைகள் இன்னும் ஒரு காத்திருப்பை மட்டுமே செலவாக்கும்.

ஒன்றையொன்று சாராத கட்டளைகளை மட்டும் batch செய்யுங்கள்

Pipeline சுயாதீன கட்டளைகளை வரிசையில் வைத்து பதில்களை வரிசையாகச் சேகரிக்கிறது, N காத்திருப்புகளை ஒன்றாக மாற்றுகிறது. பெரும்பாலான கிளையண்டுகள் அதை தனி இணைப்பு முறையாக அல்ல, block, callback அல்லது context manager ஆக வெளிப்படுத்துகின்றன, எனவே நீங்கள் நிறுவிய பதிப்பு வழங்கும் API-ஐச் சரிபாருங்கள். லாபம் சுற்றுப்பயண நேரத்துடன் வளர்கிறது, அதனால்தான் VPN-ல் இது முக்கியம், localhost-ல் கிட்டத்தட்ட தெரியவில்லை.

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())

batching மட்டுமே வேண்டுமெனில் transaction=False அனுப்புங்கள். இயல்புநிலையில் கிளையண்ட் batch-ஐ MULTI மற்றும் EXEC-ல் சுருட்டுகிறது, இது அதை அணுவாக்குகிறது, மற்ற கிளையண்டுகள் பயணத்தின் நடுவில் என்ன பார்க்கலாம் என்பதை மாற்றுகிறது. அணுத்தன்மை என்பது செயல்திறன் பொத்தான் அல்ல, சரியான தன்மை பற்றிய முடிவு, இரண்டுமே சுற்றுப்பயணங்களைக் குறைப்பதால் மட்டும் pipeline ஒரு பரிவர்த்தனை ஆகாது.

batch சமர்ப்பிப்பை மட்டும் அல்ல, ஒவ்வொரு பதிலையும் படியுங்கள். வரிசையில் உள்ள கட்டளை முழு batch முடியும் போது பிழையைத் திருப்பித் தரலாம், பதில் பட்டியலைத் தூக்கி எறியும் கிளையண்ட் தோல்வியடைந்த எழுத்தை அமைதியான எழுத்தாக மாற்றுகிறது. பதில் பட்டியலின் நீளத்தை நீங்கள் வரிசையில் வைத்த கட்டளைகளின் எண்ணிக்கையுடன் ஒப்பிடுங்கள்.

செயல்களுக்கு இடையே இணைப்பை உயிர்ப்புடன் வையுங்கள்

ஒவ்வொரு புதிய இணைப்பும் பெயர் தீர்மானம், TCP handshake, TLS handshake மற்றும் AUTH-க்கு செலுத்துகிறது, VPN-ல் அவை ஒவ்வொன்றும் நீங்கள் batch செய்ய முடியாத சுற்றுப்பயணம். கிளையண்டை ஒரு செயல்முறைக்கு ஒருமுறை உருவாக்கி மீண்டும் பயன்படுத்துங்கள், அல்லது உங்கள் நூலகம் வழங்கும் pool-ஐ வரம்பான அளவுடன் பயன்படுத்துங்கள். ஒவ்வொரு கோரிக்கைக்கும் மீண்டும் இணைவது, ஒவ்வொரு கட்டளைக்கும் காத்திருப்புக்கு அடுத்தபடியாக இந்த அறிகுறியின் இரண்டாவது பொதுவான காரணம்.

தனியுரிம hostname-ஐ நேரடி முகவரியாக அல்ல, உள்ளமைவில் வையுங்கள். சான்றிதழ் சரிபார்ப்பும் சேவை அடையாளமும் தனியுரிம வலையமைப்பிலும் பொருந்தும், ஒரு IP-ஐ பொருத்துவது வழங்குநர் subnet-ஐ மீண்டும் எண்ணிடும் அந்த நொடியில் உடைகிறது. மெதுவான பகுதி பெயர் தீர்மானம் என்றால், இணைப்பு சரத்தை அல்ல, resolver பாதையைச் சரிசெய்யுங்கள்.

சிக்கிய சுரங்கப்பாதை ஒரு worker-ஐ தொங்கவிடாமல் விரைவாகத் தோல்வியடைய தெளிவான socket timeout அமையுங்கள். பிறகு கிளையண்டில் இணைப்பு உருவாக்கத்தைப் பதிவு செய்து pool உண்மையில் மீண்டும் பயன்படுத்தப்படுகிறதா என்பதை உறுதிப்படுத்துங்கள்.

batch நினைவகச் சிக்கலாகும் முன் அதன் அளவை நிர்ணயம் செய்யுங்கள்

Redis batch-ன் முழு காலமும் வரிசைப்படுத்தப்பட்ட பதில்களை வைத்திருக்கிறது, அதன் பிறகு கிளையண்ட் பகுப்பாய்வு செய்யப்பட்ட முடிவை வைத்திருக்கிறது. பத்தாயிரம் பெரிய மதிப்புகள் கொண்ட pipeline வலையமைப்பு காத்திருப்புகளை நினைவக எழுச்சிகளுக்கும் இரு முனைகளிலும் நீண்ட இடைவெளிகளுக்கும் மாற்றுகிறது.

batch அளவை கட்டளை எண்ணிக்கையின் அடிப்படையில் அல்ல, பதில் அளவின் அடிப்படையில் தேர்ந்தெடுங்கள். ஒரு batch-ல் சில நூறு சிறிய கட்டளைகள் பொதுவாக வசதியானவை, நூறு பல கிலோபைட் payload அல்ல. பைட்டுகள் மற்றும் எண்ணிக்கை இரண்டின் அடிப்படையிலும் பிரியுங்கள், ஒவ்வொரு batch-ஐயும் endpoint உண்மையில் கொண்டுள்ள தாமத வரவுசெலவுத் திட்டத்திற்குள் வையுங்கள்.

மாற்றத்திற்குப் பிறகு தொடக்கம் முதல் இறுதி வரை அளவிடுங்கள்: redis-cli -h redis.example.internal --latency-history பாதையே நிலையானதா என்பதைக் காட்டும், உங்கள் சொந்த கோரிக்கை நேரங்காட்டி endpoint மேம்பட்டதா என்பதைக் காட்டும். endpoint இன்னும் மெதுவாக இருக்கும்போது தாமத வரலாறு தட்டையாக இருந்தால், மீதமுள்ள செலவு சேவையகப் பக்கம் வேலை அல்லது உங்கள் சொந்த serialization, அடுத்த படி இன்னொரு batch மாற்றம் அல்ல, handler-ன் profile.