ಬ್ರೌಸರ್‌ಗಳಿಗೆ 5.5 MB Python runtime ಅನ್ನು ಕಳುಹಿಸುತ್ತಿದ್ದ ಒಂದು ತಂಡವು, ಇತ್ತೀಚಿನ sprint ಸಮಯದಲ್ಲಿ ದಾಖಲಾದ ತಪ್ಪುಗಳಲ್ಲಿ 69 % ಒಂದೇ ತಪ್ಪಾದ ಶೀರ್ಷಿಕೆಯ ಅಡಿಯಲ್ಲಿ ಬಿದ್ದಿವೆ ಎಂದು ಕಂಡುಕೊಂಡಿತು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ 89 % ವಾಸ್ತವವಾಗಿ network timeouts ಆಗಿದ್ದವು. ಈ ತಪ್ಪು ವರದಿ ಮಾಡಲಾದ ಮಾಹಿತಿಯು ಡೆವಲಪರ್‌ಗಳನ್ನು ತಪ್ಪು debugging ಹಾದಿಯಲ್ಲಿ ನಡೆಸಿತು ಮತ್ತು ದೊಡ್ಡ ಮಟ್ಟದ ಬಳಕೆದಾರರು silent download failures ಎದುರಿಸುವಂತೆ ಮಾಡಿತು—ದೊಡ್ಡ assetsಗಳನ್ನು ಹೊಂದಿರುವ ಯಾವುದೇ web-app ಈ ಸಮಸ್ಯೆಯನ್ನು ಶೀಘ್ರದಲ್ಲೇ ಎದುರಿಸಬಹುದು.

ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ದಾರಿ ತಪ್ಪಿಸಿತು

Error-tracking system ತಪ್ಪುಗಳು ಮೊದಲು ಕಾಣಿಸಿಕೊಳ್ಳುವ ಕೋಡ್ ಸ್ಥಳದ ಆಧಾರದ ಮೇಲೆ ಘಟನೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಗುಂಪು ಮಾಡುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ ಬಂದ ಶೀರ್ಷಿಕೆಯು runtime loader ನಲ್ಲಿನ ಒಂದು ಸಾಮಾನ್ಯ bug ನಂತೆ ಕಂಡಿತು, ಆದ್ದರಿಂದ sprint ಸಮಯವನ್ನು ಎಂದಿಗೂ timeout ಆಗದ code paths ಹುಡುಕುವಲ್ಲೇ ಕಳೆಯಲಾಯಿತು. ತಂಡವು ಅಡಿಯಲ್ಲಿರುವ metadata ಅನ್ನು ಪರಿಶೀಲಿಸಿದಾಗ, ನಿಜವಾದ ಚಿತ್ರಣ ಬಯಲಿಗೆ ಬಂದಿತು: ಹೆಚ್ಚಿನ ವೈಫಲ್ಯಗಳು bug ಗಳಲ್ಲ, ಬದಲಾಗಿ network connections ಸ್ಥಗಿತಗೊಂಡಿದ್ದರಿಂದ timeout ಸಂಭವಿಸಿತ್ತು.

Takeaway: Error title ಎಂಬುದು ಕೇವಲ ಅನುಕೂಲಕ್ಕಾಗಿ ಇರುವ ಶೀರ್ಷಿಕೆಯಷ್ಟೇ, ಅದು ರೋಗನಿರ್ಣಯವಲ್ಲ (diagnosis). ಶೀರ್ಷಿಕೆಯು ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಲು ಕಾಲಕಾಲಕ್ಕೆ raw data ಅನ್ನು ಆಳವಾಗಿ ಪರಿಶೀಲಿಸಿ.

ಬ್ರೌಸರ್ connection API ಒಂದು placeholder ಅನ್ನು ನೀಡಿತು

ನಿಧಾನಗತಿಯ ಬಳಕೆದಾರರಿಗೆ 5.5 MB ಡೌನ್‌ಲೋಡ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸುಲಭವನ್ನಾಗಿಸಲು, ಡೆವಲಪರ್‌ಗಳು ಬ್ರೌಸರ್‌ನ Network Information API (navigator.connection) ಅನ್ನು ಬಳಸಿದರು. ಈ API ಪ್ರತಿಯೊಬ್ಬ ಮೊದಲ ಬಾರಿಗೆ ಭೇಟಿ ನೀಡುವ ಬಳಕೆದಾರರಿಗೂ ಸ್ಥಿರವಾದ 1.7 Mbps bandwidth ಅನ್ನು ವರದಿ ಮಾಡಿತು.

ಹೊಸ ಬಳಕೆದಾರರ ಬಗ್ಗೆ ಯಾವುದೇ ಐತಿಹಾಸಿಕ ಡೇಟಾ ಇಲ್ಲದಿದ್ದಾಗ ಬ್ರೌಸರ್‌ಗಳು ಒಂದು default value ಅನ್ನು ನೀಡುತ್ತವೆ. ಆ default value ಎಂಬುದು ಕೇವಲ ಒಂದು ಸೂಚನೆ (hint) ಅಷ್ಟೇ, ಅದು ನಿಖರವಾದ ವೇಗವಲ್ಲ. ಪ್ರತಿಯೊಂದು ಹೊಸ session ಗೂ ಒಂದೇ placeholder ಕಾಣಿಸಿಕೊಂಡರೆ, ಆ API ಇನ್ನೂ ಆ ಬಳಕೆದಾರರಿಗೆ ಸರಿಯಾಗಿ ಹೊಂದಾಣಿಕೆಯಾಗಿಲ್ಲ (calibrated) ಎಂದು ಅರ್ಥ.

Takeaway: ಎಂದಿಗೂ ಬದಲಾಗದ ಯಾವುದೇ network signal ಅನ್ನು ಕೇವಲ fallback ಎಂದು ಪರಿಗಣಿಸಿ, ಅದನ್ನು ನಿಖರವಾದ metric ಎಂದು ಭಾವಿಸಬೇಡಿ.

ಏಕೈಕ snapshots ನಂಬಲರ್ಹವಲ್ಲ

ನಂಬಲರ್ಹವಲ್ಲದ bandwidth ಸೂಚನೆಯನ್ನು ಕೈಬಿಟ್ಟ ನಂತರ, ತಂಡವು ತಮ್ಮ test suite ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿರುವಂತೆ ತೋರುವ ಬೇರೆ ಸಿಗ್ನಲ್‌ಗೆ ಬದಲಾಯಿತು. ಒಂದು ಬಾರಿ ಪರೀಕ್ಷೆಯು ಯಶಸ್ವಿಯಾಯಿತು, ಆದರೆ ಮೂರು ಬಾರಿ ಪರೀಕ್ಷಿಸಿದಾಗ ಪ್ರತಿ ಬಾರಿಯೂ ವೈಫಲ್ಯಗಳು ಸಂಭವಿಸಿದವು. Network speed ನಿರಂತರವಾಗಿ ಬದಲಾಗುತ್ತಿರುತ್ತದೆ. ಕೋಡ್ ಕೇವಲ ಒಂದು snapshot ಅನ್ನು ತೆಗೆದುಕೊಂಡು, ಶಾಶ್ವತ ನಿರ್ಧಾರವನ್ನು ಮಾಡಿತು ಮತ್ತು ಕ್ಷಣಾರ್ಧದಲ್ಲಿ connection ಬದಲಾದರೂ ಮುಂದುವರಿಯಿತು.

Takeaway: ಬದಲಾಗುತ್ತಿರುವ ಗುರಿಯ (moving target) ಕೇವಲ ಒಂದು ರೀಡಿಂಗ್ ಆಧಾರದ ಮೇಲೆ ಶಾಶ್ವತ ಕ್ರಮವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಡಿ. ಒಮ್ಮೆ ಮಾತ್ರ polling ಮಾಡುವ ಬದಲು change events ಗೆ subscribe ಮಾಡಿ.

ತಂಡವು ಜಾರಿಗೆ ತಂದ ಪ್ರಾಯೋಗಿಕ ಪರಿಹಾರಗಳು

  • Connection ಬದಲಾವಣೆಗಳಿಗೆ subscribe ಮಾಡಿ. navigator.connection ಅನ್ನು ಒಮ್ಮೆ ಓದುವ ಬದಲು, ಕೋಡ್ ಈಗ change event ಅನ್ನು ಗಮನಿಸುತ್ತದೆ ಮತ್ತು ಡೌನ್‌ಲೋಡ್ ಸಮಯದಲ್ಲಿ bandwidth ಕಡಿಮೆಯಾದರೆ ಅಥವಾ ಹೆಚ್ಚಾದರೆ ಅದಕ್ಕೆ ತಕ್ಕಂತೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ.
  • “no-progress” watchdog ಅನ್ನು ಸೇರಿಸಿ. ಒಂದು ನಿರ್ದಿಷ್ಟ ಅವಧಿಯ ನಂತರ ಯಾವುದೇ ಪ್ರಗತಿ ಕಾಣಿಸದ ವಿನಂತಿಯನ್ನು (request) ಒಂದು timer ರದ್ದುಗೊಳಿಸುತ್ತದೆ, ಇದರಿಂದ ಬ್ರೌಸರ್ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಲು ಅಥವಾ fallback ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
  • ಡೌನ್‌ಲೋಡ್ ಮಧ್ಯದಲ್ಲಿ CDNs ಬದಲಾಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ನಿಧಾನಗತಿಯ ಲಿಂಕ್‌ನಲ್ಲಿ ದೊಡ್ಡ ಫೈಲ್‌ನ ಮೂಲವನ್ನು (source) ಬದಲಾಯಿಸುವುದರಿಂದ ವರ್ಗಾವಣೆ ಶೂನ್ಯದಿಂದ ಮತ್ತೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಇದರಿಂದ ಈಗಾಗಲೇ ಪಡೆದ ಬೈಟ್‌ಗಳು ವ್ಯರ್ಥವಾಗುತ್ತವೆ. ಈಗ ಡೌನ್‌ಲೋಡ್ ಸಂಪೂರ್ಣ ಅವಧಿಯವರೆಗೆ ಆರಂಭದಲ್ಲಿ ಆಯ್ಕೆ ಮಾಡಿದ CDN ನಲ್ಲೇ ಇರುತ್ತದೆ.
  • ಭಾರೀ caching ಕೆಲಸಗಳನ್ನು ಮುಂದೂಡಿ. ಕ್ಯಾಶ್‌ಗೆ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಬರೆಯುವ ಕೆಲಸಗಳನ್ನು runtime ಲೋಡ್ ಆದ ನಂತರದವರೆಗೆ ಮುಂದೂಡಲಾಗುತ್ತದೆ, ಇದರಿಂದ critical path ಚಿಕ್ಕದಾಗಿರುತ್ತದೆ.

ನಿಮ್ಮ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು ಅತಿಯಾದ ನಿಖರತೆಯನ್ನು ತೋರಿಸುತ್ತಿದ್ದರೆ, ಅದನ್ನು ಆಳವಾಗಿ ಪರಿಶೀಲಿಸಿ. ನೆಟ್‌ವರ್ಕ್ ಅಳತೆ ಎಂದಿಗೂ ಬದಲಾಗದಿದ್ದರೆ, ಅದನ್ನು ಕೇವಲ placeholder ಎಂದು ಪರಿಗಣಿಸಿ. ಮತ್ತು ಒಂದು ಏಕೈಕ snapshot ಮಲ್ಟಿ-ಮೆಗಾಬೈಟ್ ಡೌನ್‌ಲೋಡ್‌ನ ವಿಧಿಯನ್ನು ನಿರ್ಧರಿಸುತ್ತಿದ್ದರೆ, ನೀವು ಭ್ರಮೆಯ ಮೇಲೆ ನಂಬಿಕೆ ಇಡುತ್ತಿದ್ದೀರಿ ಎಂದರ್ಥ. ಅಂತಹ ನಿರ್ಧಾರಗಳು ಬಳಕೆದಾರರ ವಿಶ್ವಾಸವನ್ನು ಕುಂದಿಸುವ silent failures ಆಗಿ ಹೊರಹೊಮ್ಮುತ್ತವೆ—ಇದನ್ನು ನಂತರದ ಸಮಯದಲ್ಲಿ ಎಷ್ಟೇ ಚತುರ ಕೋಡ್‌ನಿಂದ ಪೂರ್ಣವಾಗಿ ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.