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 ಮಾರ್ಗವೇ ಸ್ಥಿರವಾಗಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮದೇ ವಿನಂತಿ ಟೈಮರ್ ಎಂಡ್ಪಾಯಿಂಟ್ ಸುಧಾರಿಸಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ವಿಳಂಬ ಇತಿಹಾಸ ಚಪ್ಪಟೆಯಾಗಿದ್ದರೂ ಎಂಡ್ಪಾಯಿಂಟ್ ಇನ್ನೂ ನಿಧಾನವಾಗಿದ್ದರೆ, ಉಳಿದ ವೆಚ್ಚ ಸರ್ವರ್-ಪಕ್ಷದ ಕೆಲಸ ಅಥವಾ ನಿಮ್ಮದೇ ಸರಣೀಕರಣ, ಮತ್ತು ಮುಂದಿನ ಹೆಜ್ಜೆ ಇನ್ನೊಂದು ಬ್ಯಾಚಿಂಗ್ ಬದಲಾವಣೆಯಲ್ಲ, ಹ್ಯಾಂಡ್ಲರ್ನ ಪ್ರೊಫೈಲ್.