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 ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਰਾਹ ਖੁਦ ਸਥਿਰ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਤੁਹਾਡਾ ਆਪਣਾ ਬੇਨਤੀ ਟਾਈਮਰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਐਂਡਪੌਇੰਟ ਸੁਧਰਿਆ ਜਾਂ ਨਹੀਂ। ਜੇ ਲੇਟੈਂਸੀ ਇਤਿਹਾਸ ਸਮਤਲ ਹੁੰਦਿਆਂ ਵੀ ਐਂਡਪੌਇੰਟ ਹੌਲਾ ਰਹੇ, ਤਾਂ ਬਚਿਆ ਖ਼ਰਚ ਸਰਵਰ-ਪਾਸੇ ਦਾ ਕੰਮ ਜਾਂ ਤੁਹਾਡਾ ਆਪਣਾ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਹੈ, ਅਤੇ ਅਗਲਾ ਕਦਮ ਹੋਰ ਬੈਚਿੰਗ ਬਦਲਾਅ ਨਹੀਂ, ਹੈਂਡਲਰ ਦਾ ਪ੍ਰੋਫਾਈਲ ਹੈ।