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.