ಸೈನ್ ಇನ್ ಹೆಚ್ಚಿನ ಪೋಸ್ಟ್‌ಗಳು, ವಿತರಿಸಿದ ಸೇವೆಯಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ, ಈ ಸೇವೆಯನ್ನು ಆಲ್ವಿನ್ ಎಂದು ಕರೆಯೋಣ. ಈ ಸಮಯದಲ್ಲಿ ನಾನು ಸಮಸ್ಯೆಯನ್ನು ಸ್ವತಃ ಕಂಡುಹಿಡಿಯಲಿಲ್ಲ, ಕ್ಲೈಂಟ್ ಕಡೆಯ ವ್ಯಕ್ತಿಗಳು ನನಗೆ ಮಾಹಿತಿ ನೀಡಿದರು.

ಆಲ್ವಿನ್‌ನೊಂದಿಗಿನ ದೀರ್ಘ ವಿಳಂಬದಿಂದಾಗಿ ಒಂದು ದಿನ ನಾನು ಅತೃಪ್ತ ಇಮೇಲ್‌ನಿಂದ ಎಚ್ಚರಗೊಂಡೆ, ಅದನ್ನು ನಾವು ಮುಂದಿನ ದಿನಗಳಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲು ಯೋಜಿಸಿದ್ದೇವೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ಕ್ಲೈಂಟ್ 99 ಎಂಎಸ್ ಪ್ರದೇಶದಲ್ಲಿ 50 ನೇ ಶೇಕಡಾ ಲೇಟೆನ್ಸಿಯನ್ನು ಅನುಭವಿಸಿದ್ದಾರೆ, ಇದು ನಮ್ಮ ಲೇಟೆನ್ಸಿ ಬಜೆಟ್‌ಗಿಂತ ಹೆಚ್ಚಾಗಿದೆ. ನಾನು ಸೇವೆಯನ್ನು ವ್ಯಾಪಕವಾಗಿ ಪರೀಕ್ಷಿಸಿದ್ದರಿಂದ ಇದು ಆಶ್ಚರ್ಯಕರವಾಗಿತ್ತು, ವಿಶೇಷವಾಗಿ ಲೇಟೆನ್ಸಿಯಲ್ಲಿ, ಇದು ಸಾಮಾನ್ಯ ದೂರಾಗಿದೆ.

ನಾನು ಆಲ್ವಿನ್‌ನನ್ನು ಪರೀಕ್ಷೆಗೆ ಒಳಪಡಿಸುವ ಮೊದಲು, ನಾನು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 40k ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ (QPS) ಸಾಕಷ್ಟು ಪ್ರಯೋಗಗಳನ್ನು ನಡೆಸಿದ್ದೇನೆ, ಎಲ್ಲವೂ 10ms ಗಿಂತ ಕಡಿಮೆ ಸುಪ್ತತೆಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಅವರ ಫಲಿತಾಂಶಗಳನ್ನು ನಾನು ಒಪ್ಪುವುದಿಲ್ಲ ಎಂದು ಘೋಷಿಸಲು ನಾನು ಸಿದ್ಧನಾಗಿದ್ದೆ. ಆದರೆ ಪತ್ರವನ್ನು ಮತ್ತೊಮ್ಮೆ ನೋಡಿದಾಗ, ನಾನು ಹೊಸದನ್ನು ಗಮನಿಸಿದ್ದೇನೆ: ಅವರು ಹೇಳಿದ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ನಾನು ನಿಖರವಾಗಿ ಪರೀಕ್ಷಿಸಿಲ್ಲ, ಅವರ ಕ್ಯೂಪಿಎಸ್ ನನ್ನಿಗಿಂತ ಕಡಿಮೆಯಾಗಿದೆ. ನಾನು 40k QPS ನಲ್ಲಿ ಪರೀಕ್ಷಿಸಿದೆ, ಆದರೆ ಅವರು 1k ನಲ್ಲಿ ಮಾತ್ರ. ನಾನು ಮತ್ತೊಂದು ಪ್ರಯೋಗವನ್ನು ನಡೆಸಿದ್ದೇನೆ, ಈ ಬಾರಿ ಕಡಿಮೆ QPS ನೊಂದಿಗೆ, ಅವರನ್ನು ಸಮಾಧಾನಪಡಿಸಲು.

ನಾನು ಇದರ ಬಗ್ಗೆ ಬ್ಲಾಗಿಂಗ್ ಮಾಡುತ್ತಿರುವುದರಿಂದ, ಅವರ ಸಂಖ್ಯೆಗಳು ಸರಿಯಾಗಿವೆ ಎಂದು ನೀವು ಬಹುಶಃ ಈಗಾಗಲೇ ಕಂಡುಕೊಂಡಿದ್ದೀರಿ. ಅದೇ ಫಲಿತಾಂಶದೊಂದಿಗೆ ನಾನು ನನ್ನ ವರ್ಚುವಲ್ ಕ್ಲೈಂಟ್ ಅನ್ನು ಮತ್ತೆ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿದೆ: ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ವಿನಂತಿಗಳು ಸುಪ್ತತೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದಲ್ಲದೆ, 10 ms ಗಿಂತ ಹೆಚ್ಚಿನ ಸುಪ್ತತೆಯೊಂದಿಗೆ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, 40k QPS ನಲ್ಲಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 50 ವಿನಂತಿಗಳು 50 ms ಅನ್ನು ಮೀರಿದರೆ, ನಂತರ 1k QPS ನಲ್ಲಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 100 ms ಗಿಂತ ಹೆಚ್ಚಿನ 50 ವಿನಂತಿಗಳು ಇದ್ದವು. ವಿರೋಧಾಭಾಸ!

ಹುಡುಕಾಟವನ್ನು ಕಿರಿದಾಗಿಸುವುದು

ಅನೇಕ ಘಟಕಗಳನ್ನು ಹೊಂದಿರುವ ವಿತರಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಲೇಟೆನ್ಸಿ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದಾಗ, ಶಂಕಿತರ ಕಿರು ಪಟ್ಟಿಯನ್ನು ರಚಿಸುವುದು ಮೊದಲ ಹಂತವಾಗಿದೆ. ಆಲ್ವಿನ್ ಅವರ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಸ್ವಲ್ಪ ಆಳವಾಗಿ ಅಗೆಯೋಣ:

ಉತ್ತಮ ಆರಂಭದ ಹಂತವು ಪೂರ್ಣಗೊಂಡ I/O ಪರಿವರ್ತನೆಗಳ ಪಟ್ಟಿಯಾಗಿದೆ (ನೆಟ್‌ವರ್ಕ್ ಕರೆಗಳು/ಡಿಸ್ಕ್ ಲುಕಪ್‌ಗಳು, ಇತ್ಯಾದಿ.). ವಿಳಂಬ ಎಲ್ಲಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ಪ್ರಯತ್ನಿಸೋಣ. ಕ್ಲೈಂಟ್‌ನೊಂದಿಗೆ ಸ್ಪಷ್ಟವಾದ I/O ಜೊತೆಗೆ, ಆಲ್ವಿನ್ ಒಂದು ಹೆಚ್ಚುವರಿ ಹೆಜ್ಜೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾನೆ: ಅವನು ಡೇಟಾ ಸ್ಟೋರ್ ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತಾನೆ. ಆದಾಗ್ಯೂ, ಈ ಸಂಗ್ರಹಣೆಯು ಆಲ್ವಿನ್‌ನಂತೆಯೇ ಅದೇ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್‌ಗಿಂತ ಕಡಿಮೆ ಸುಪ್ತತೆ ಇರಬೇಕು. ಆದ್ದರಿಂದ, ಶಂಕಿತರ ಪಟ್ಟಿ:

1. ಕ್ಲೈಂಟ್‌ನಿಂದ ಆಲ್ವಿನ್‌ಗೆ ನೆಟ್‌ವರ್ಕ್ ಕರೆ.
2. ಆಲ್ವಿನ್‌ನಿಂದ ಡೇಟಾ ಸ್ಟೋರ್‌ಗೆ ನೆಟ್‌ವರ್ಕ್ ಕರೆ.
3. ಡೇಟಾ ಸ್ಟೋರ್‌ನಲ್ಲಿ ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಹುಡುಕಿ.
4. ಆಲ್ವಿನ್‌ಗೆ ಡೇಟಾ ವೇರ್‌ಹೌಸ್‌ನಿಂದ ನೆಟ್‌ವರ್ಕ್ ಕರೆ.
5. ಆಲ್ವಿನ್‌ನಿಂದ ಕ್ಲೈಂಟ್‌ಗೆ ನೆಟ್‌ವರ್ಕ್ ಕರೆ.

ಕೆಲವು ಅಂಕಗಳನ್ನು ದಾಟಲು ಪ್ರಯತ್ನಿಸೋಣ.

ಡೇಟಾ ಸಂಗ್ರಹಣೆಗೂ ಇದಕ್ಕೂ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ

ನಾನು ಮಾಡಿದ ಮೊದಲ ಕೆಲಸವೆಂದರೆ ಆಲ್ವಿನ್ ಅನ್ನು ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸದ ಪಿಂಗ್-ಪಿಂಗ್ ಸರ್ವರ್‌ಗೆ ಪರಿವರ್ತಿಸುವುದು. ಅದು ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ಅದು ಖಾಲಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುತ್ತದೆ. ಸುಪ್ತತೆ ಕಡಿಮೆಯಾದರೆ, ಆಲ್ವಿನ್ ಅಥವಾ ಡೇಟಾ ವೇರ್‌ಹೌಸ್ ಅಳವಡಿಕೆಯಲ್ಲಿನ ದೋಷವು ಕೇಳದ ವಿಷಯವಲ್ಲ. ಮೊದಲ ಪ್ರಯೋಗದಲ್ಲಿ ನಾವು ಈ ಕೆಳಗಿನ ಗ್ರಾಫ್ ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ:

ನೀವು ನೋಡುವಂತೆ, ಪಿಂಗ್-ಪಿಂಗ್ ಸರ್ವರ್ ಅನ್ನು ಬಳಸುವಾಗ ಯಾವುದೇ ಸುಧಾರಣೆ ಇಲ್ಲ. ಇದರರ್ಥ ಡೇಟಾ ವೇರ್ಹೌಸ್ ಸುಪ್ತತೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದಿಲ್ಲ ಮತ್ತು ಶಂಕಿತರ ಪಟ್ಟಿಯನ್ನು ಅರ್ಧದಷ್ಟು ಕತ್ತರಿಸಲಾಗುತ್ತದೆ:

1. ಕ್ಲೈಂಟ್‌ನಿಂದ ಆಲ್ವಿನ್‌ಗೆ ನೆಟ್‌ವರ್ಕ್ ಕರೆ.
2. ಆಲ್ವಿನ್‌ನಿಂದ ಕ್ಲೈಂಟ್‌ಗೆ ನೆಟ್‌ವರ್ಕ್ ಕರೆ.

ಗ್ರೇಟ್! ಪಟ್ಟಿ ಶೀಘ್ರವಾಗಿ ಕುಗ್ಗುತ್ತಿದೆ. ನಾನು ಕಾರಣವನ್ನು ಬಹುತೇಕ ಕಂಡುಕೊಂಡಿದ್ದೇನೆ ಎಂದು ನಾನು ಭಾವಿಸಿದೆ.

gRPC

ಹೊಸ ಆಟಗಾರನಿಗೆ ನಿಮ್ಮನ್ನು ಪರಿಚಯಿಸುವ ಸಮಯ ಇದೀಗ: gRPC. ಇದು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಸಂವಹನಕ್ಕಾಗಿ Google ನಿಂದ ತೆರೆದ ಮೂಲ ಗ್ರಂಥಾಲಯವಾಗಿದೆ ಆರ್ಪಿಸಿ... ಆದರೂ gRPC ಉತ್ತಮವಾಗಿ ಹೊಂದುವಂತೆ ಮತ್ತು ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗಿದೆ, ಈ ಗಾತ್ರದ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ನಾನು ಇದನ್ನು ಮೊದಲ ಬಾರಿಗೆ ಬಳಸುತ್ತಿದ್ದೇನೆ ಮತ್ತು ನನ್ನ ಅನುಷ್ಠಾನವು ಉಪೋತ್ಕೃಷ್ಟವಾಗಿರುತ್ತದೆ ಎಂದು ನಾನು ನಿರೀಕ್ಷಿಸಿದೆ - ಕನಿಷ್ಠ ಹೇಳಲು.

ಲಭ್ಯತೆ gRPC ಸ್ಟಾಕ್‌ನಲ್ಲಿ ಹೊಸ ಪ್ರಶ್ನೆಯನ್ನು ಹುಟ್ಟುಹಾಕಿತು: ಬಹುಶಃ ಇದು ನನ್ನ ಅನುಷ್ಠಾನ ಅಥವಾ ನಾನೇ ಆಗಿರಬಹುದು gRPC ಸುಪ್ತ ಸಮಸ್ಯೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತಿದೆಯೇ? ಹೊಸ ಶಂಕಿತರನ್ನು ಪಟ್ಟಿಗೆ ಸೇರಿಸಲಾಗುತ್ತಿದೆ:

1. ಕ್ಲೈಂಟ್ ಗ್ರಂಥಾಲಯವನ್ನು ಕರೆಯುತ್ತಾನೆ gRPC
2. ಗ್ರಂಥಾಲಯದ gRPC ಕ್ಲೈಂಟ್‌ನಲ್ಲಿರುವ ಲೈಬ್ರರಿಗೆ ನೆಟ್‌ವರ್ಕ್ ಕರೆ ಮಾಡುತ್ತದೆ gRPC ಸರ್ವರ್‌ನಲ್ಲಿ
3. ಗ್ರಂಥಾಲಯದ gRPC ಆಲ್ವಿನ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಿ (ಪಿಂಗ್-ಪಾಂಗ್ ಸರ್ವರ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ ಯಾವುದೇ ಕಾರ್ಯಾಚರಣೆಯಿಲ್ಲ)

ಕೋಡ್ ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನಿಮಗೆ ಕಲ್ಪನೆಯನ್ನು ನೀಡಲು, ನನ್ನ ಕ್ಲೈಂಟ್/ಆಲ್ವಿನ್ ಅನುಷ್ಠಾನವು ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಪದಗಳಿಗಿಂತ ಹೆಚ್ಚು ಭಿನ್ನವಾಗಿಲ್ಲ ಅಸಿಂಕ್ ಉದಾಹರಣೆಗಳು.

ಗಮನಿಸಿ: ಮೇಲಿನ ಪಟ್ಟಿಯನ್ನು ಸ್ವಲ್ಪ ಸರಳಗೊಳಿಸಲಾಗಿದೆ ಏಕೆಂದರೆ gRPC ನಿಮ್ಮ ಸ್ವಂತ (ಟೆಂಪ್ಲೇಟ್?) ಥ್ರೆಡಿಂಗ್ ಮಾದರಿಯನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಮಾಡುತ್ತದೆ, ಇದರಲ್ಲಿ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಸ್ಟಾಕ್ ಹೆಣೆದುಕೊಂಡಿದೆ gRPC ಮತ್ತು ಬಳಕೆದಾರರ ಅನುಷ್ಠಾನ. ಸರಳತೆಗಾಗಿ, ನಾವು ಈ ಮಾದರಿಗೆ ಅಂಟಿಕೊಳ್ಳುತ್ತೇವೆ.

ಪ್ರೊಫೈಲಿಂಗ್ ಎಲ್ಲವನ್ನೂ ಸರಿಪಡಿಸುತ್ತದೆ

ಡೇಟಾ ಸ್ಟೋರ್‌ಗಳನ್ನು ದಾಟಿದ ನಂತರ, ನಾನು ಬಹುತೇಕ ಮುಗಿಸಿದ್ದೇನೆ ಎಂದು ನಾನು ಭಾವಿಸಿದೆ: “ಈಗ ಇದು ಸುಲಭ! ಪ್ರೊಫೈಲ್ ಅನ್ನು ಅನ್ವಯಿಸೋಣ ಮತ್ತು ವಿಳಂಬ ಎಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯೋಣ. I ನಿಖರವಾದ ಪ್ರೊಫೈಲಿಂಗ್‌ನ ದೊಡ್ಡ ಅಭಿಮಾನಿ, ಏಕೆಂದರೆ CPUಗಳು ತುಂಬಾ ವೇಗವಾಗಿರುತ್ತವೆ ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಅಡಚಣೆಯಾಗಿರುವುದಿಲ್ಲ. ಪ್ರೊಸೆಸರ್ ಬೇರೆ ಏನನ್ನಾದರೂ ಮಾಡಲು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದಾಗ ಹೆಚ್ಚಿನ ವಿಳಂಬಗಳು ಸಂಭವಿಸುತ್ತವೆ. ನಿಖರವಾದ CPU ಪ್ರೊಫೈಲಿಂಗ್ ಅದನ್ನು ಮಾಡುತ್ತದೆ: ಇದು ಎಲ್ಲವನ್ನೂ ನಿಖರವಾಗಿ ದಾಖಲಿಸುತ್ತದೆ ಸಂದರ್ಭ ಸ್ವಿಚ್ಗಳು ಮತ್ತು ಎಲ್ಲಿ ವಿಳಂಬಗಳು ಸಂಭವಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ.

ನಾನು ನಾಲ್ಕು ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇನೆ: ಹೆಚ್ಚಿನ QPS (ಕಡಿಮೆ ಲೇಟೆನ್ಸಿ) ಮತ್ತು ಪಿಂಗ್-ಪಾಂಗ್ ಸರ್ವರ್ ಜೊತೆಗೆ ಕಡಿಮೆ QPS (ಹೆಚ್ಚಿನ ಲೇಟೆನ್ಸಿ), ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ ಮತ್ತು ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ. ಮತ್ತು ಒಂದು ವೇಳೆ, ನಾನು ಮಾದರಿ ಪ್ರೊಸೆಸರ್ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಸಹ ತೆಗೆದುಕೊಂಡೆ. ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ಹೋಲಿಸಿದಾಗ, ನಾನು ಸಾಮಾನ್ಯವಾಗಿ ಅಸಂಗತ ಕರೆ ಸ್ಟಾಕ್‌ಗಾಗಿ ನೋಡುತ್ತೇನೆ. ಉದಾಹರಣೆಗೆ, ಹೆಚ್ಚಿನ ಸುಪ್ತತೆಯೊಂದಿಗೆ ಕೆಟ್ಟ ಭಾಗದಲ್ಲಿ ಇನ್ನೂ ಹಲವು ಸಂದರ್ಭ ಸ್ವಿಚ್‌ಗಳಿವೆ (10 ಬಾರಿ ಅಥವಾ ಹೆಚ್ಚು). ಆದರೆ ನನ್ನ ವಿಷಯದಲ್ಲಿ, ಸಂದರ್ಭ ಸ್ವಿಚ್‌ಗಳ ಸಂಖ್ಯೆ ಬಹುತೇಕ ಒಂದೇ ಆಗಿರುತ್ತದೆ. ನನ್ನ ಭಯಾನಕತೆಗೆ, ಅಲ್ಲಿ ಗಮನಾರ್ಹವಾದದ್ದೇನೂ ಇರಲಿಲ್ಲ.

ಹೆಚ್ಚುವರಿ ಡೀಬಗ್ ಮಾಡುವಿಕೆ

ನಾನು ಹತಾಶನಾಗಿದ್ದೆ. ನಾನು ಯಾವ ಇತರ ಸಾಧನಗಳನ್ನು ಬಳಸಬಹುದೆಂದು ನನಗೆ ತಿಳಿದಿರಲಿಲ್ಲ, ಮತ್ತು ನನ್ನ ಮುಂದಿನ ಯೋಜನೆಯು ಸಮಸ್ಯೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪತ್ತೆಹಚ್ಚುವ ಬದಲು ವಿಭಿನ್ನ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಪ್ರಯೋಗಗಳನ್ನು ಪುನರಾವರ್ತಿಸುವುದು.

ಹೀಗಾದರೆ

ಮೊದಲಿನಿಂದಲೂ, ನಾನು ನಿರ್ದಿಷ್ಟ 50ms ಲೇಟೆನ್ಸಿ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸಿದ್ದೆ. ಇದು ಬಹಳ ದೊಡ್ಡ ಸಮಯ. ಯಾವ ಭಾಗವು ಈ ದೋಷವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ಕಂಡುಹಿಡಿಯುವವರೆಗೆ ನಾನು ಕೋಡ್‌ನಿಂದ ತುಂಡುಗಳನ್ನು ಕತ್ತರಿಸಬೇಕೆಂದು ನಾನು ನಿರ್ಧರಿಸಿದೆ. ನಂತರ ಒಂದು ಪ್ರಯೋಗವು ಕೆಲಸ ಮಾಡಿತು.

ಎಂದಿನಂತೆ, ಹಿನ್ನೋಟದಲ್ಲಿ ಎಲ್ಲವೂ ಸ್ಪಷ್ಟವಾಗಿತ್ತು ಎಂದು ತೋರುತ್ತದೆ. ನಾನು ಕ್ಲೈಂಟ್ ಅನ್ನು ಆಲ್ವಿನ್‌ನ ಅದೇ ಯಂತ್ರದಲ್ಲಿ ಇರಿಸಿದೆ - ಮತ್ತು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದೆ localhost. ಮತ್ತು ಸುಪ್ತತೆಯ ಹೆಚ್ಚಳವು ಹೋಗಿದೆ!

ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಏನೋ ತಪ್ಪಾಗಿದೆ.

ನೆಟ್‌ವರ್ಕ್ ಎಂಜಿನಿಯರ್ ಕೌಶಲ್ಯಗಳನ್ನು ಕಲಿಯುವುದು

ನಾನು ಒಪ್ಪಿಕೊಳ್ಳಬೇಕು: ನೆಟ್‌ವರ್ಕ್ ತಂತ್ರಜ್ಞಾನಗಳ ಬಗ್ಗೆ ನನ್ನ ಜ್ಞಾನವು ಭಯಾನಕವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ನಾನು ಪ್ರತಿದಿನ ಅವರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ ಎಂಬ ಅಂಶವನ್ನು ಪರಿಗಣಿಸಿ. ಆದರೆ ನೆಟ್‌ವರ್ಕ್ ಪ್ರಮುಖ ಶಂಕಿತವಾಗಿದೆ ಮತ್ತು ಅದನ್ನು ಡೀಬಗ್ ಮಾಡುವುದು ಹೇಗೆ ಎಂದು ನಾನು ಕಲಿಯಬೇಕಾಗಿದೆ.

ಅದೃಷ್ಟವಶಾತ್, ಇಂಟರ್ನೆಟ್ ಕಲಿಯಲು ಬಯಸುವವರನ್ನು ಪ್ರೀತಿಸುತ್ತದೆ. ಪಿಂಗ್ ಮತ್ತು ಟ್ರೇಸರ್ಟ್‌ನ ಸಂಯೋಜನೆಯು ನೆಟ್‌ವರ್ಕ್ ಸಾರಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಡೀಬಗ್ ಮಾಡಲು ಸಾಕಷ್ಟು ಉತ್ತಮ ಆರಂಭದಂತೆ ತೋರುತ್ತಿದೆ.

ಮೊದಲನೆಯದಾಗಿ, ನಾನು ಪ್ರಾರಂಭಿಸಿದೆ PsPing ಆಲ್ವಿನ್‌ನ TCP ಪೋರ್ಟ್‌ಗೆ. ನಾನು ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬಳಸಿದ್ದೇನೆ - ವಿಶೇಷವೇನೂ ಇಲ್ಲ. ಸಾವಿರಕ್ಕೂ ಹೆಚ್ಚು ಪಿಂಗ್‌ಗಳಲ್ಲಿ, ಬೆಚ್ಚಗಾಗಲು ಮೊದಲನೆಯದನ್ನು ಹೊರತುಪಡಿಸಿ, ಯಾವುದೂ 10 ಎಂಎಸ್ ಅನ್ನು ಮೀರಲಿಲ್ಲ. ಇದು 50ನೇ ಪರ್ಸೆಂಟೈಲ್‌ನಲ್ಲಿ 99 ಎಂಎಸ್‌ನ ಲೇಟೆನ್ಸಿ ಹೆಚ್ಚಳಕ್ಕೆ ವಿರುದ್ಧವಾಗಿದೆ: ಅಲ್ಲಿ, ಪ್ರತಿ 100 ವಿನಂತಿಗಳಿಗೆ, ನಾವು 50 ಎಂಎಸ್‌ಗಳ ಸುಪ್ತತೆಯೊಂದಿಗೆ ಸುಮಾರು ಒಂದು ವಿನಂತಿಯನ್ನು ನೋಡಬೇಕು.

ನಂತರ ನಾನು ಪ್ರಯತ್ನಿಸಿದೆ ಟ್ರೇಸರ್ಟ್: ಆಲ್ವಿನ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ನಡುವಿನ ಮಾರ್ಗದಲ್ಲಿ ಒಂದು ನೋಡ್‌ನಲ್ಲಿ ಸಮಸ್ಯೆ ಇರಬಹುದು. ಆದರೆ ಟ್ರೇಸರ್ ಕೂಡ ಬರಿಗೈಯಲ್ಲಿ ಹಿಂತಿರುಗಿದನು.

ಹಾಗಾಗಿ ನನ್ನ ಕೋಡ್, gRPC ಅನುಷ್ಠಾನ ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ವಿಳಂಬಕ್ಕೆ ಕಾರಣವಾಗಿರಲಿಲ್ಲ. ಇದು ನನಗೆ ಎಂದಿಗೂ ಅರ್ಥವಾಗುವುದಿಲ್ಲ ಎಂದು ನಾನು ಚಿಂತೆ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದೆ.

ಈಗ ನಾವು ಯಾವ OS ನಲ್ಲಿ ಇದ್ದೇವೆ

gRPC ಲಿನಕ್ಸ್‌ನಲ್ಲಿ ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ, ಆದರೆ ವಿಂಡೋಸ್‌ನಲ್ಲಿ ವಿಲಕ್ಷಣವಾಗಿದೆ. ನಾನು ಪ್ರಯೋಗವನ್ನು ಪ್ರಯತ್ನಿಸಲು ನಿರ್ಧರಿಸಿದೆ, ಅದು ಕೆಲಸ ಮಾಡಿದೆ: ನಾನು ಲಿನಕ್ಸ್ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ರಚಿಸಿದೆ, ಲಿನಕ್ಸ್‌ಗಾಗಿ ಆಲ್ವಿನ್ ಅನ್ನು ಸಂಕಲಿಸಿದೆ ಮತ್ತು ಅದನ್ನು ನಿಯೋಜಿಸಿದೆ.

ಮತ್ತು ಇಲ್ಲಿ ಏನಾಯಿತು: ಲಿನಕ್ಸ್ ಪಿಂಗ್-ಪಾಂಗ್ ಸರ್ವರ್ ಒಂದೇ ರೀತಿಯ ವಿಂಡೋಸ್ ಹೋಸ್ಟ್‌ನಂತೆ ಅದೇ ವಿಳಂಬವನ್ನು ಹೊಂದಿಲ್ಲ, ಆದಾಗ್ಯೂ ಡೇಟಾ ಮೂಲವು ಭಿನ್ನವಾಗಿಲ್ಲ. ವಿಂಡೋಸ್‌ಗಾಗಿ ಜಿಆರ್‌ಪಿಸಿ ಅನುಷ್ಠಾನದಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ.

ನಾಗ್ಲೆ ಅವರ ಅಲ್ಗಾರಿದಮ್

ಈ ಸಮಯದಲ್ಲಿ ನಾನು ಧ್ವಜವನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೇನೆ ಎಂದು ನಾನು ಭಾವಿಸಿದೆ gRPC. ಅದು ನಿಜವಾಗಿಯೂ ಏನೆಂದು ಈಗ ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ gRPC ವಿಂಡೋಸ್ ಫ್ಲ್ಯಾಗ್ ಕಾಣೆಯಾಗಿದೆ. ನಾನು ಆಂತರಿಕ RPC ಲೈಬ್ರರಿಯನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇನೆ, ಅದು ಎಲ್ಲಾ ಫ್ಲ್ಯಾಗ್‌ಗಳಿಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನನಗೆ ವಿಶ್ವಾಸವಿದೆ ವಿನ್ಸಾಕ್. ನಂತರ ನಾನು ಈ ಎಲ್ಲಾ ಫ್ಲ್ಯಾಗ್‌ಗಳನ್ನು gRPC ಗೆ ಸೇರಿಸಿದೆ ಮತ್ತು ವಿಂಡೋಸ್‌ನಲ್ಲಿ ಪ್ಯಾಚ್ ಮಾಡಿದ ವಿಂಡೋಸ್ ಪಿಂಗ್-ಪಾಂಗ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಆಲ್ವಿನ್ ಅನ್ನು ನಿಯೋಜಿಸಿದೆ!

ಸುಮಾರು ಮುಗಿದಿದೆ: ರಿಗ್ರೆಷನ್ ಹಿಂತಿರುಗುವವರೆಗೆ ನಾನು ಸೇರಿಸಲಾದ ಫ್ಲ್ಯಾಗ್‌ಗಳನ್ನು ಒಂದೊಂದಾಗಿ ತೆಗೆದುಹಾಕಲು ಪ್ರಾರಂಭಿಸಿದೆ, ಹಾಗಾಗಿ ನಾನು ಕಾರಣವನ್ನು ಗುರುತಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಇದು ಕುಖ್ಯಾತವಾಗಿತ್ತು TCP_NODELAY, ನಾಗ್ಲೆ ಅವರ ಅಲ್ಗಾರಿದಮ್ ಸ್ವಿಚ್.

ನಾಗ್ಲೆ ಅವರ ಅಲ್ಗಾರಿದಮ್ ಪ್ಯಾಕೆಟ್ ಗಾತ್ರವು ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಬೈಟ್‌ಗಳನ್ನು ಮೀರುವವರೆಗೆ ಸಂದೇಶಗಳ ಪ್ರಸರಣವನ್ನು ವಿಳಂಬಗೊಳಿಸುವ ಮೂಲಕ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಕಳುಹಿಸಲಾದ ಪ್ಯಾಕೆಟ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಇದು ಸರಾಸರಿ ಬಳಕೆದಾರರಿಗೆ ಒಳ್ಳೆಯದಾಗಿದ್ದರೂ, ನೈಜ-ಸಮಯದ ಸರ್ವರ್‌ಗಳಿಗೆ ಇದು ವಿನಾಶಕಾರಿಯಾಗಿದೆ ಏಕೆಂದರೆ OS ಕೆಲವು ಸಂದೇಶಗಳನ್ನು ವಿಳಂಬಗೊಳಿಸುತ್ತದೆ, ಕಡಿಮೆ QPS ನಲ್ಲಿ ವಿಳಂಬವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಯು gRPC ಈ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು TCP ಸಾಕೆಟ್‌ಗಳಿಗಾಗಿ ಲಿನಕ್ಸ್ ಅನುಷ್ಠಾನದಲ್ಲಿ ಹೊಂದಿಸಲಾಗಿದೆ, ಆದರೆ ವಿಂಡೋಸ್‌ನಲ್ಲಿ ಅಲ್ಲ. ನಾನು ಇದು ಸರಿಪಡಿಸಲಾಗಿದೆ.

ತೀರ್ಮಾನಕ್ಕೆ

ಕಡಿಮೆ QPS ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಸುಪ್ತತೆಯು OS ಆಪ್ಟಿಮೈಸೇಶನ್‌ನಿಂದ ಉಂಟಾಗುತ್ತದೆ. ಸಿಂಹಾವಲೋಕನದಲ್ಲಿ, ಪ್ರೊಫೈಲಿಂಗ್ ಸುಪ್ತತೆಯನ್ನು ಪತ್ತೆ ಮಾಡಲಿಲ್ಲ ಏಕೆಂದರೆ ಇದನ್ನು ಕರ್ನಲ್ ಮೋಡ್‌ನಲ್ಲಿ ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಮಾಡಲಾಗಿದೆ ಬಳಕೆದಾರ ಮೋಡ್. ETW ಕ್ಯಾಪ್ಚರ್‌ಗಳ ಮೂಲಕ Nagle ಅವರ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಗಮನಿಸಬಹುದೇ ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ, ಆದರೆ ಇದು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ.

ಲೋಕಲ್ ಹೋಸ್ಟ್ ಪ್ರಯೋಗಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಇದು ಬಹುಶಃ ನಿಜವಾದ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಕೋಡ್ ಅನ್ನು ಸ್ಪರ್ಶಿಸಿಲ್ಲ ಮತ್ತು ನಾಗ್ಲೆ ಅವರ ಅಲ್ಗಾರಿದಮ್ ರನ್ ಆಗಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ ಸ್ಥಳೀಯ ಹೋಸ್ಟ್ ಮೂಲಕ ಆಲ್ವಿನ್ ಅನ್ನು ತಲುಪಿದಾಗ ಲೇಟೆನ್ಸಿ ಸಮಸ್ಯೆಗಳು ದೂರವಾದವು.

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ ಕಡಿಮೆಯಾದಂತೆ ಮುಂದಿನ ಬಾರಿ ನೀವು ಸುಪ್ತತೆಯ ಹೆಚ್ಚಳವನ್ನು ನೋಡಿದಾಗ, ನಗ್ಲೆ ಅವರ ಅಲ್ಗಾರಿದಮ್ ನಿಮ್ಮ ಶಂಕಿತರ ಪಟ್ಟಿಯಲ್ಲಿರಬೇಕು!

ಮೂಲ: www.habr.com