ನಿಮ್ಮ ಡೌನ್‌ಲೋಡ್ ವೇಗವಾಗಿದೆ, ಹಾಗಾದರೆ ಪ್ರತಿ ಕ್ಲಿಕ್ ನಿಧಾನವಾಗಿ ಏಕೆ ಅನಿಸುತ್ತದೆ?

ದೊಡ್ಡ ಫೈಲ್ ಅನ್ನು ವೇಗವಾಗಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ ನಂತರ ಪ್ರತಿ ಕ್ಲಿಕ್ ನಿಧಾನವಾಗಿ ಅನಿಸುವುದು ವಿರೋಧಾಭಾಸವಲ್ಲ. ಸಾಮರ್ಥ್ಯವು ಸೆಕೆಂಡಿಗೆ ಎಷ್ಟು ಚಲಿಸಬಹುದು ಎಂದು ಹೇಳುತ್ತದೆ; ರೌಂಡ್-ಟ್ರಿಪ್ ಸಮಯವು ಉಪಯುಕ್ತವಾದದ್ದು ಸಂಭವಿಸುವ ಮೊದಲು ವಿನಿಮಯ ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಮೊದಲನೆಯದನ್ನು ಸುಧಾರಿಸುವುದು ಎರಡನೆಯದಕ್ಕೆ ಏನೂ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಎರಡನೆಯದು ವ್ಯಕ್ತಿ ಟೈಪ್ ಮಾಡುವಾಗ, ಕ್ಲಿಕ್ ಮಾಡುವಾಗ ಅಥವಾ ಮಾತನಾಡುವಾಗ ಗಮನಿಸುವುದು. ಸಂಪರ್ಕವನ್ನಲ್ಲ, ದೂರನ್ನು ಅಳೆಯಿರಿ.

ವೇಗದ ಫೈಲ್, ನಿಧಾನ ಕ್ಲಿಕ್: ಎರಡು ವಿಭಿನ್ನ ಸಂಖ್ಯೆಗಳು

ಬೃಹತ್ ವರ್ಗಾವಣೆ ಮಾಹಿತಿಯನ್ನು ನಿರಂತರವಾಗಿ ಚಲನೆಯಲ್ಲಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಪ್ರತ್ಯೇಕ ವಿನಂತಿ ಕಾಯುತ್ತಿದ್ದರೂ ಅದು ಆರೋಗ್ಯಕರ ದರವನ್ನು ವರದಿ ಮಾಡಬಹುದು. ಅನೇಕ ಬೆಂಚ್ಮಾರ್ಕ್ಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಹಲವು ಸಂಪರ್ಕಗಳನ್ನು ಸಹ ತೆರೆಯುತ್ತವೆ, ಇದು ಒಂದು ವಿನಂತಿ ನಿಧಾನವಾಗಿ ಉಳಿದರೂ ಒಟ್ಟು ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಎರಡೂ ಫಲಿತಾಂಶಗಳು ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ವಿಳಂಬದ ಬಗ್ಗೆ ದೂರುವ ಬಳಕೆದಾರರಿಗೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯನ್ನು ಉಲ್ಲೇಖಿಸುವುದು ವಿಶ್ವಾಸ ಕಳೆದುಕೊಳ್ಳುವ ದಾರಿ.

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

ಟನೆಲ್ ತನ್ನ ಪ್ರಯಾಣ ಮತ್ತು ಸಂಸ್ಕರಣೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ನಕ್ಷೆಯ ಮೇಲಿನ ಲೇಬಲ್ಗಿಂತ ಮಾರ್ಗವೇ ಹೆಚ್ಚು ಮುಖ್ಯ. ಒಂದೇ ದೇಶದ ಎರಡು ಎಗ್ರೆಸ್ಗಳಿಗೆ ಒಂದೇ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಬಹಳ ಬೇರೆ ಮಾರ್ಗಗಳಿರಬಹುದು. ಇಪ್ಪತ್ತು ಮಿಲಿಸೆಕೆಂಡ್ ವ್ಯತ್ಯಾಸವು ಪುಟದ ಅನುಭವವನ್ನು ಬದಲಿಸಲು ಸಾಕು, ಆದರೂ ಅದು ಥ್ರೂಪುಟ್ ಸಂಖ್ಯೆಯನ್ನು ಬಹುತೇಕ ಚಲಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಎಗ್ರೆಸ್ ಆಯ್ಕೆ ಧ್ವಜದ ಐಕಾನ್ಗಿಂತ ಲೇಟೆನ್ಸಿ ಮಾದರಿಯನ್ನು ಅನುಸರಿಸಬೇಕು.

ದೂರನ್ನು ಅಳೆಯಿರಿ, ಸಂಪರ್ಕವನ್ನಲ್ಲ

ಬಳಕೆದಾರರು ಹೇಳಿದ ವಾಕ್ಯಕ್ಕೆ ಹೊಂದುವ ಅಳತೆಯನ್ನು ಆರಿಸಿ. ನಿಧಾನ ಡೌನ್ಲೋಡ್ಗೆ ಸರಿಯಾದ ದಿಕ್ಕಿನಲ್ಲಿ ಸ್ಥಿರ ದರ ಬೇಕು; ತಡವಾಗುವ ಕರೆಗೆ ಆ ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವಂತ ಅಂಕಿಅಂಶಗಳು ಬೇಕು; ನಿಧಾನವಾಗಿ ಪ್ರಾರಂಭವಾಗುವ ಪುಟಕ್ಕೆ ಹೆಸರು ಪರಿಹಾರ ಮತ್ತು ಸ್ಥಾಪನೆಯ ಸಮಯಗಳು ಬೇಕು.

ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4

ಮೊದಲ ಆದೇಶವು ಊಹಿಸಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯಿಸುವ ಹೋಸ್ಟ್ಗೆ ರೌಂಡ್-ಟ್ರಿಪ್ ಮಾದರಿ ನೀಡುತ್ತದೆ, ಎರಡನೆಯದು ಒಂದು ಸಂಪರ್ಕಕ್ಕೆ ಮೊದಲ ಬೈಟ್ವರೆಗಿನ ಸಮಯ ಮತ್ತು ಸ್ಥಿರ ದರವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಮೂರನೆಯದು ನಾಲ್ಕು ಸಮಾನಾಂತರ ಸ್ಟ್ರೀಮ್ಗಳೊಂದಿಗೆ ಒಟ್ಟು ಥ್ರೂಪುಟ್ ಅಳೆಯುತ್ತದೆ. ದಿನದ ಅದೇ ಸಮಯದಲ್ಲಿ ಅದೇ ಗಮ್ಯಸ್ಥಾನದ ವಿರುದ್ಧ ಅವುಗಳನ್ನು ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ ಬೆಳಗಿನ ಮಾದರಿಯನ್ನು ಸಂಜೆಯ ಮಾದರಿಯೊಂದಿಗೆ ಹೋಲಿಸುವುದು ಅಳತೆಯಲ್ಲ, ಕಥೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

ಎಗ್ರೆಸ್ಗಳನ್ನು ಹೋಲಿಸುವಾಗ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಸ್ಥಿರವಾಗಿಡಿ. ಸರ್ವರ್ ಮತ್ತು ಟನೆಲ್ ಎರಡನ್ನೂ ಬದಲಿಸುವುದು ಒಂದು ಚರವನ್ನು ಎರಡಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಫಲಿತಾಂಶ ಯಾವುದು ಮುಖ್ಯವಾಗಿತ್ತು ಎಂದು ಹೇಳಲಾರದು. ಪ್ರತಿ ಎಗ್ರೆಸ್ ಅನ್ನು ಕನಿಷ್ಠ ಮೂರು ಬಾರಿ ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ ಒಂದೇ ಮಾದರಿ ಹಲವು ಬಾರಿ ರೂಟಿಂಗ್ ಬದಲಾವಣೆ ಅಥವಾ ಗದ್ದಲದ ನಿಮಿಷದಲ್ಲಿ ಬೀಳುತ್ತದೆ. ಸರಾಸರಿಯು ಉತ್ತಮ ಪ್ರಕರಣಕ್ಕಿಂತ ಹೆಚ್ಚು ಉಪಯುಕ್ತ.

ICMP ಅನ್ನು ಉತ್ತರವಲ್ಲ, ಸುಳಿವು ಎಂದು ಪರಿಗಣಿಸಿ. ಪ್ರತಿಕ್ರಿಯಿಸುವ ಹೋಸ್ಟ್ ಪ್ರತಿಧ್ವನಿ ವಿನಂತಿಗಳನ್ನು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಬಳಸುವ ಮಾರ್ಗಕ್ಕಿಂತ ಬೇರೆ ಮಾರ್ಗದಲ್ಲಿ ನಿರ್ವಹಿಸಬಹುದು, ಮತ್ತು ಒಂದು ಕಳೆದುಹೋದ ಪ್ರತಿಕ್ರಿಯೆ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ.

ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ವಿಳಂಬವು ಸರದಿ ಸಮಸ್ಯೆ

ಜನರನ್ನು ಹೆಚ್ಚು ಗೊಂದಲಗೊಳಿಸುವ ಮಾದರಿ ಎಂದರೆ ನಿಷ್ಕ್ರಿಯವಾಗಿರುವಾಗ ಚೆನ್ನಾಗಿ ಅನಿಸಿ ಬ್ಯಾಕಪ್ ಸಮಯದಲ್ಲಿ ನಿರುಪಯುಕ್ತವಾಗುವ ಸಂಪರ್ಕ. ಅದು ಸರದಿ, ಸಾಮರ್ಥ್ಯವಲ್ಲ. ತುಂಬಿದ ಅಪ್ಲಿಂಕ್ ಪ್ರತಿ ಇತರ ಪ್ಯಾಕೆಟ್ನ ಮುಂದೆ ಬಫರ್ ನಿರ್ಮಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೀಲಿ ಒತ್ತುವಿಕೆ ಅಪ್ಲೋಡ್ನ ಒಂದು ಭಾಗದ ಹಿಂದೆ ಕಾಯುತ್ತದೆ.

ping -c 20 10.60.0.5 &
iperf3 -c 10.60.0.5 -t 20 -R -b 20M

ಮೊದಲ ಆದೇಶವು ಹಿನ್ನೆಲೆಯಲ್ಲಿ ವಿಳಂಬದ ಮಾದರಿಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಎರಡನೆಯದು ವಿರುದ್ಧ ದಿಕ್ಕನ್ನು ತುಂಬಿಸುತ್ತದೆ. ವರ್ಗಾವಣೆಯ ಸಮಯದಲ್ಲಿ ping ಸಮಯಗಳು ನೆಗೆದು ನಂತರ ಚೇತರಿಸಿಕೊಂಡರೆ, ನೀವು ರೂಟಿಂಗ್ ದೋಷವನ್ನು ಕಂಡುಹಿಡಿಯುವ ಬದಲು bufferbloat ಅನ್ನು ಪುನರುತ್ಪಾದಿಸಿದ್ದೀರಿ. ಪರಿಹಾರ ಸಾಮಾನ್ಯವಾಗಿ ಸರದಿ ನಿರ್ವಹಣೆ ಸೆಟ್ಟಿಂಗ್, ಕಡಿಮೆ ಹಿನ್ನೆಲೆ ದರ, ಅಥವಾ ಬೃಹತ್ ವರ್ಗಾವಣೆಯನ್ನು ಸಂವಾದಾತ್ಮಕ ಮಾರ್ಗದಿಂದ ದೂರ ಸರಿಸುವುದು.

ಐಚ್ಛಿಕ ಹಿನ್ನೆಲೆ ಸಂಚಾರವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಎಗ್ರೆಸ್ ದೇಶ ಬದಲಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಅದು ಅಗ್ಗವೂ, ಹಿಂತಿರುಗಿಸಬಹುದಾದದ್ದೂ ಮತ್ತು ಒಂದು ನಿಮಿಷದಲ್ಲಿ ಪರೀಕ್ಷಿಸಬಹುದಾದದ್ದೂ ಆಗಿದೆ. ಸರದಿಯನ್ನು ನಿರ್ವಹಿಸಲಾಗದಿದ್ದರೆ ದೊಡ್ಡ ಅಪ್ಲೋಡ್ಗಳನ್ನು ಕೆಲಸದ ಸಮಯದ ಹೊರಗೆ ನಿಗದಿಪಡಿಸಿ, ಮತ್ತು ಹಗಲಿನಲ್ಲಿ ಓಡಬೇಕಿದ್ದರೆ ಅವುಗಳ ದರವನ್ನು ಮಿತಿಗೊಳಿಸಿ. ರೌಟರ್ ಬೆಂಬಲಿಸಿದರೆ ಸರದಿ ನಿರ್ವಹಣೆ ಸೆಟ್ಟಿಂಗ್ ಉತ್ತಮ ಪರಿಹಾರ.

ಒಂದು ವಿಷಯ ಬದಲಿಸಿ ಮತ್ತು ಸಮಾನವನ್ನು ಸಮಾನದೊಂದಿಗೆ ಹೋಲಿಸಿ

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

ನೀವು ಏನನ್ನು ಅಳೆದಿರಿ, ಯಾವ ಗಮ್ಯಸ್ಥಾನದ ವಿರುದ್ಧ, ಯಾವ ಸಮಯದಲ್ಲಿ ಮತ್ತು ಯಾವ ಸೆಟ್ಟಿಂಗ್ಗಳೊಂದಿಗೆ ಎಂದು ಬರೆಯಿರಿ. ಆ ನಾಲ್ಕು ಸತ್ಯಗಳಿಲ್ಲದೆ ಹೋಲಿಕೆಯನ್ನು ಪುನರಾವರ್ತಿಸಲಾಗದು, ಮತ್ತು ಮುಂದಿನ ವ್ಯಕ್ತಿ ಶೂನ್ಯದಿಂದ ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ.

ನಂತರ ಟಿಕೆಟ್ನಲ್ಲಿನ ಹೇಳಿಕೆಗೆ ಸಾಧನವನ್ನು ಹೊಂದಿಸಿ. "ನಿಧಾನ ಇಂಟರ್ನೆಟ್" ಅಳತೆಯಲ್ಲ; "ಈ ಹೋಸ್ಟ್ಗೆ ಮೊದಲ ಬೈಟ್ 900 ms ತೆಗೆದುಕೊಂಡಿತು ಆದರೆ ಥ್ರೂಪುಟ್ ಚೆನ್ನಾಗಿತ್ತು" ಒಂದು ಅಳತೆ, ಮತ್ತು ಅದು ನೇರವಾಗಿ ಸಾಮರ್ಥ್ಯವನ್ನಲ್ಲ, ವಿಳಂಬವನ್ನು ಸೂಚಿಸುತ್ತದೆ.