VPN દ્વારા Redis ધીમું લાગે છે: પ્રતિ વિનંતી રાઉન્ડ ટ્રિપ ઘટાડવી

સ્થાનિક Redis સામે 200 ms માં જવાબ આપતું પૃષ્ઠ ક્લાઇન્ટ VPN પાછળ બેસતાં જ ચાર સેકન્ડ લે છે, જ્યારે સર્વરના કાઉન્ટર નિષ્ક્રિય રહે છે. ધીમો લોગ એક મિલિસેકન્ડથી ઉપર કંઈ દર્શાવતો નથી, CPU ગ્રાફ સપાટ છે, અને ઇન્સ્ટન્સ ફરિયાદ વિના અન્ય ક્લાઇન્ટને સેવા આપે છે. જે બદલાયું છે તે અંતર છે, અને અંતરને ગુણે છે તમારો કોડ જેટલી વાર અટકીને રાહ જુએ છે. ક્લાઇન્ટથી બહારની તરફ વિનંતીનો રસ્તો ચાલો અને ઉકેલ લગભગ હંમેશા ઝડપી સર્વર નહીં, પણ ઓછી ક્રમિક રાહ જોવાની હોય છે.

સર્વરના મેટ્રિકથી નહીં, ક્લાઇન્ટથી શરૂ કરો

પ્રથમ આદેશ અને છેલ્લા આદેશ વચ્ચે ક્લાઇન્ટ પ્રક્રિયાનું નિરીક્ષણ કરો. જો ટ્રેસ જવાબ, વિરામ, પછી આગળનો આદેશ દર્શાવે, તો તમે પ્રતિ આદેશ પૂરી રાઉન્ડ ટ્રિપ ચૂકવો છો અને સર્વર ટ્યુનિંગનો કોઈ પણ જથ્થો તેને બદલશે નહીં. ધીમો લોગ અહીં ખોટું સાધન છે, કારણ કે તે અમલનો સમય નોંધે છે અને સંદેશાવ્યવહાર I/O ઇરાદાપૂર્વક બાકાત રાખે છે. ધીમા એન્ડપોઇન્ટની બાજુમાં સ્વચ્છ ધીમો લોગ એ રાઉન્ડ-ટ્રિપ સમસ્યાની સહી છે.

કોડને સ્પર્શ કરતા પહેલા રસ્તો જ માપો. redis-cli -h redis.example.internal --latency વારંવાર PING મોકલે છે અને સરેરાશ વિનંતી અને જવાબ સમય છાપે છે, જે તમારો પ્રતિ-આદાનપ્રદાન ખર્ચ છે. તેને એક વપરાશકર્તા ક્રિયામાંના ક્રમિક આદેશોની સંખ્યા સાથે ગુણો અને એન્ડપોઇન્ટ માટે ન્યૂનતમ મર્યાદા મળે છે.

એક વપરાશકર્તા ક્રિયાને ખરેખર કેટલી રાઉન્ડ ટ્રિપ જોઈએ તે ગણો

એક એન્ડપોઇન્ટ લો અને દરેક Redis કૉલ ક્રમમાં લખો, જે ORM, સેશન મિડલવેર કે ફીચર-ફ્લેગ શોધમાં છુપાયેલા હોય તે સહિત. મોટા ભાગના ધીમા એન્ડપોઇન્ટ જ્યાં ત્રણ પૂરતા હતા ત્યાં વીસ કે ત્રીસ કૉલ કરતા હોય છે, અને છુપાયેલા સામાન્ય રીતે બહુમતીમાં હોય છે.

નિર્ભરતા સાંકળને સંકોચી શકાતી નથી: જો બીજા આદેશને પ્રથમ પાછી આપેલી કીની જરૂર હોય, તો રાહ ખરી છે અને એકમાત્ર વિકલ્પો અલગ ડેટા મોડેલ અથવા એવી સર્વર-બાજુની ક્રિયા છે જે આખું પગલું એકસાથે વ્યક્ત કરે. સ્વતંત્ર વાંચન અલગ કિસ્સો છે, કારણ કે બીજું મોકલતા પહેલા પ્રથમ જવાબની રાહ જોવા માટે કંઈ ફરજ પાડતું નથી. કંઈપણ સંપાદિત કરતા પહેલા દરેક કૉલને નિર્ભર કે સ્વતંત્ર તરીકે ચિહ્નિત કરો અને ઉકેલનો આકાર સ્પષ્ટ થઈ જશે.

મહત્વની સંખ્યા ક્રમિક રાહ છે, કુલ આદેશો નહીં. એક બેચમાં ત્રીસ આદેશ પણ એક જ રાહનો ખર્ચ કરે છે.

ફક્ત એ આદેશોને બેચ કરો જે એકબીજા પર નિર્ભર નથી

પાઇપલાઇન સ્વતંત્ર આદેશોને કતારમાં મૂકે છે અને જવાબો ક્રમમાં એકત્ર કરે છે, N રાહને એકમાં ફેરવે છે. મોટા ભાગના ક્લાઇન્ટ તેને અલગ કનેક્શન મોડ તરીકે નહીં, પણ બ્લોક, કૉલબેક કે સંદર્ભ મેનેજર તરીકે આપે છે, તેથી તમારા સ્થાપિત સંસ્કરણની 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())

ફક્ત બેચિંગ જોઈએ ત્યારે transaction=False આપો. ડિફૉલ્ટ સાથે ક્લાઇન્ટ બેચને MULTI અને EXECમાં લપેટે છે, જે તેને પરમાણુ બનાવે છે અને બીજા ક્લાઇન્ટ મધ્યમાં શું જોઈ શકે તે બદલે છે. પરમાણુતા સુધારણાનો નિર્ણય છે, પ્રદર્શનનું બટન નહીં, અને બંને રાઉન્ડ ટ્રિપ ઘટાડે છે એટલા માટે પાઇપલાઇન વ્યવહાર નથી.

ફક્ત બેચ સબમિશન નહીં, દરેક જવાબ વાંચો. કતારમાંનો આદેશ ભૂલ પાછી આપી શકે છે જ્યારે બેચ સમગ્ર રીતે પૂર્ણ થાય છે, અને જવાબોની સૂચિ ફેંકી દેતો ક્લાઇન્ટ નિષ્ફળ લખાણને શાંત લખાણમાં ફેરવે છે. જવાબોની સૂચિની લંબાઈને તમે કતારમાં મૂકેલા આદેશોની સંખ્યા સાથે સરખાવો.

ક્રિયાઓ વચ્ચે કનેક્શન જીવંત રાખો

દરેક નવું કનેક્શન નામ-ઉકેલ, TCP હેન્ડશેક, TLS હેન્ડશેક અને AUTH માટે ચૂકવે છે, અને VPN પર તેમાંનું દરેક એ રાઉન્ડ ટ્રિપ છે જે તમે બેચ કરીને દૂર કરી શકતા નથી. પ્રતિ પ્રક્રિયા એક વાર ક્લાઇન્ટ બનાવો અને ફરી વાપરો, અથવા તમારી લાઇબ્રેરી આપતા મર્યાદિત કદના પૂલનો ઉપયોગ કરો. પ્રતિ વિનંતી ફરી કનેક્ટ થવું એ પ્રતિ-આદેશ રાહ પછી આ લક્ષણનું બીજું સૌથી સામાન્ય કારણ છે.

રૂપરેખાંકનમાં શાબ્દિક સરનામા ઠેકાણે ખાનગી હોસ્ટનામ રાખો. પ્રમાણપત્ર ચકાસણી અને સેવા ઓળખ ખાનગી નેટવર્ક પર પણ લાગુ પડે છે, અને IP પિન કરવું તે ક્ષણે તૂટે છે જ્યારે પ્રદાતા સબનેટનું પુનઃક્રમાંકન કરે. જો ઉકેલ ધીમો ભાગ હોય, તો કનેક્શન સ્ટ્રિંગ નહીં, રિઝોલ્વરનો રસ્તો સુધારો.

સ્પષ્ટ સૉકેટ સમયમર્યાદા સેટ કરો જેથી અટકેલી ટનલ વર્કરને લટકાવવાને બદલે ઝડપથી નિષ્ફળ જાય. પછી ક્લાઇન્ટમાં કનેક્શન બનાવવાનું લોગ કરીને ખાતરી કરો કે પૂલ ખરેખર ફરી વપરાય છે.

મેમરી સમસ્યા બને તે પહેલાં બેચનું કદ નક્કી કરો

Redis બેચની આખી અવધિ દરમિયાન કતારબદ્ધ જવાબો રાખે છે, અને ક્લાઇન્ટ પછી પાર્સ કરેલું પરિણામ રાખે છે. દસ હજાર મોટા મૂલ્યોની પાઇપલાઇન નેટવર્ક રાહને મેમરી સ્પાઇક અને બંને છેડે લાંબા વિરામ સાથે બદલે છે.

આદેશોની સંખ્યા નહીં, જવાબના જથ્થા પ્રમાણે બેચનું કદ પસંદ કરો. એક બેચમાં થોડા સો નાના આદેશ સામાન્ય રીતે આરામદાયક હોય છે, જ્યારે સો મલ્ટી-કિલોબાઇટ પેલોડ નહીં. બાઇટ અને સંખ્યા બંને પ્રમાણે વિભાજન કરો, અને દરેક બેચને એન્ડપોઇન્ટ પાસે ખરેખર હોય તે લેટન્સી બજેટની અંદર રાખો.

ફેરફાર પછી શરૂઆતથી અંત સુધી માપો: redis-cli -h redis.example.internal --latency-history દર્શાવે છે કે રસ્તો પોતે સ્થિર છે કે નહીં, અને તમારો પોતાનો વિનંતી ટાઇમર દર્શાવે છે કે એન્ડપોઇન્ટ સુધર્યો છે કે નહીં. જો લેટન્સી ઇતિહાસ સપાટ હોવા છતાં એન્ડપોઇન્ટ ધીમું રહે, તો બાકીનો ખર્ચ સર્વર-બાજુનું કામ કે તમારું પોતાનું સીરિયલાઇઝેશન છે, અને આગળનું પગલું બીજો બેચિંગ ફેરફાર નહીં, હેન્ડલરની પ્રોફાઇલ છે.