ಆದ್ದರಿಂದ ನೀವು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೀರಿ. ನಾವು ಇದ್ದಂತೆ. ನಾವು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಹ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ. ಸಹಜವಾಗಿ, ವ್ಯವಹಾರಕ್ಕೆ ಅವಶ್ಯಕ. ಇಂದು ನಾವು ನಮ್ಮ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್‌ನ ಮೊದಲ ಲಿಂಕ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ - statsd-ಹೊಂದಾಣಿಕೆಯ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆ ಸರ್ವರ್ , ನಾವು ಅದನ್ನು ಏಕೆ ಬರೆದಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಬ್ರೂಬೆಕ್ ಅನ್ನು ಏಕೆ ತ್ಯಜಿಸಿದ್ದೇವೆ.
ನಮ್ಮ ಹಿಂದಿನ ಲೇಖನಗಳಿಂದ (, ) ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ನಾವು ಬಳಸಿ ಅಂಕಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ ಎಂದು ನೀವು ಕಂಡುಹಿಡಿಯಬಹುದು . ಇದನ್ನು C ಯಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ಕೋಡ್ ದೃಷ್ಟಿಕೋನದಿಂದ, ಇದು ಪ್ಲಗ್‌ನಂತೆ ಸರಳವಾಗಿದೆ (ನೀವು ಕೊಡುಗೆ ನೀಡಲು ಬಯಸಿದಾಗ ಇದು ಮುಖ್ಯವಾಗಿದೆ) ಮತ್ತು, ಮುಖ್ಯವಾಗಿ, ಇದು ನಮ್ಮ ವಾಲ್ಯೂಮ್‌ಗಳ 2 ಮಿಲಿಯನ್ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ (MPS) ಗರಿಷ್ಠ ಮಟ್ಟದಲ್ಲಿ ನಿಭಾಯಿಸುತ್ತದೆ. ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ. ದಸ್ತಾವೇಜನ್ನು ನಕ್ಷತ್ರ ಚಿಹ್ನೆಯೊಂದಿಗೆ 4 ಮಿಲಿಯನ್ MPS ಗೆ ಬೆಂಬಲವನ್ನು ಹೇಳುತ್ತದೆ. ಇದರರ್ಥ ನೀವು ಲಿನಕ್ಸ್‌ನಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದರೆ ಹೇಳಲಾದ ಅಂಕಿಅಂಶವನ್ನು ನೀವು ಪಡೆಯುತ್ತೀರಿ. (ನೀವು ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಹಾಗೆಯೇ ಬಿಟ್ಟರೆ ನೀವು ಎಷ್ಟು MPS ಅನ್ನು ಪಡೆಯಬಹುದು ಎಂದು ನಮಗೆ ತಿಳಿದಿಲ್ಲ). ಈ ಅನುಕೂಲಗಳ ಹೊರತಾಗಿಯೂ, ಬ್ರೂಬೆಕ್ ಬಗ್ಗೆ ನಾವು ಹಲವಾರು ಗಂಭೀರ ದೂರುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಹಕ್ಕು 1. ಪ್ರಾಜೆಕ್ಟ್‌ನ ಡೆವಲಪರ್ ಗಿಥಬ್, ಅದನ್ನು ಬೆಂಬಲಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದರು: ಪ್ಯಾಚ್‌ಗಳು ಮತ್ತು ಫಿಕ್ಸ್‌ಗಳನ್ನು ಪ್ರಕಟಿಸುವುದು, ನಮ್ಮದು ಮತ್ತು (ನಮ್ಮದು ಮಾತ್ರವಲ್ಲ) PR ಅನ್ನು ಸ್ವೀಕರಿಸುವುದು. ಕಳೆದ ಕೆಲವು ತಿಂಗಳುಗಳಲ್ಲಿ (ಎಲ್ಲೋ ಫೆಬ್ರವರಿ-ಮಾರ್ಚ್ 2018 ರಿಂದ), ಚಟುವಟಿಕೆ ಪುನರಾರಂಭವಾಗಿದೆ, ಆದರೆ ಅದಕ್ಕೂ ಮೊದಲು ಸುಮಾರು 2 ವರ್ಷಗಳ ಸಂಪೂರ್ಣ ಶಾಂತತೆ ಇತ್ತು. ಜೊತೆಗೆ, ಯೋಜನೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗುತ್ತಿದೆ , ಇದು ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳ ಪರಿಚಯಕ್ಕೆ ಗಂಭೀರ ಅಡಚಣೆಯಾಗಬಹುದು.
ಹಕ್ಕು 2. ಲೆಕ್ಕಾಚಾರಗಳ ನಿಖರತೆ. ಬ್ರೂಬೆಕ್ ಒಟ್ಟು 65536 ಮೌಲ್ಯಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುತ್ತಾನೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಕೆಲವು ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ, ಒಟ್ಟುಗೂಡಿಸುವ ಅವಧಿಯಲ್ಲಿ (30 ಸೆಕೆಂಡುಗಳು), ಹೆಚ್ಚಿನ ಮೌಲ್ಯಗಳು ಬರಬಹುದು (ಗರಿಷ್ಠದಲ್ಲಿ 1). ಈ ಮಾದರಿಯ ಪರಿಣಾಮವಾಗಿ, ಗರಿಷ್ಠ ಮತ್ತು ಕನಿಷ್ಠ ಮೌಲ್ಯಗಳು ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿ ಗೋಚರಿಸುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಈ ರೀತಿ:
ಇದ್ದ ಹಾಗೆಯೇ
ಹೇಗಿರಬೇಕಿತ್ತು
ಅದೇ ಕಾರಣಕ್ಕಾಗಿ, ಮೊತ್ತವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪಾಗಿ ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ. 32-ಬಿಟ್ ಫ್ಲೋಟ್ ಓವರ್‌ಫ್ಲೋ ಹೊಂದಿರುವ ದೋಷವನ್ನು ಇಲ್ಲಿ ಸೇರಿಸಿ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ತೋರಿಕೆಯಲ್ಲಿ ಮುಗ್ಧ ಮೆಟ್ರಿಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವಾಗ ಸರ್ವರ್ ಅನ್ನು ಸೆಗ್‌ಫಾಲ್ಟ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿರುತ್ತದೆ. ದೋಷವನ್ನು, ಮೂಲಕ, ಸರಿಪಡಿಸಲಾಗಿಲ್ಲ.
ಮತ್ತು, ಅಂತಿಮವಾಗಿ, ಕ್ಲೈಮ್ X. ಬರೆಯುವ ಸಮಯದಲ್ಲಿ, ನಾವು ಕಂಡುಕೊಂಡ ಎಲ್ಲಾ 14 ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ statsd ಅನುಷ್ಠಾನಗಳಿಗೆ ಅದನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಲು ನಾವು ಸಿದ್ಧರಿದ್ದೇವೆ. ಕೆಲವು ಒಂದೇ ಮೂಲಸೌಕರ್ಯವು ಎಷ್ಟು ಬೆಳೆದಿದೆಯೆಂದರೆ 4 ಮಿಲಿಯನ್ MPS ಅನ್ನು ಸ್ವೀಕರಿಸುವುದು ಇನ್ನು ಮುಂದೆ ಸಾಕಾಗುವುದಿಲ್ಲ ಎಂದು ಊಹಿಸೋಣ. ಅಥವಾ ಅದು ಇನ್ನೂ ಬೆಳೆಯದಿದ್ದರೂ ಸಹ, ಆದರೆ ಮೆಟ್ರಿಕ್‌ಗಳು ನಿಮಗೆ ಈಗಾಗಲೇ ತುಂಬಾ ಮುಖ್ಯವಾಗಿದ್ದು, ಚಾರ್ಟ್‌ಗಳಲ್ಲಿ ಚಿಕ್ಕದಾದ, 2-3 ನಿಮಿಷಗಳ ಅದ್ದುಗಳು ಈಗಾಗಲೇ ನಿರ್ಣಾಯಕವಾಗಬಹುದು ಮತ್ತು ನಿರ್ವಾಹಕರಲ್ಲಿ ದುಸ್ತರ ಖಿನ್ನತೆಯನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಖಿನ್ನತೆಗೆ ಚಿಕಿತ್ಸೆ ನೀಡುವುದು ಕೃತಜ್ಞತೆಯಿಲ್ಲದ ಕೆಲಸವಾಗಿರುವುದರಿಂದ, ತಾಂತ್ರಿಕ ಪರಿಹಾರಗಳ ಅಗತ್ಯವಿದೆ.
ಮೊದಲನೆಯದಾಗಿ, ದೋಷ ಸಹಿಷ್ಣುತೆ, ಇದರಿಂದ ಸರ್ವರ್‌ನಲ್ಲಿ ಹಠಾತ್ ಸಮಸ್ಯೆಯು ಕಚೇರಿಯಲ್ಲಿ ಮನೋವೈದ್ಯಕೀಯ ಜೊಂಬಿ ಅಪೋಕ್ಯಾಲಿಪ್ಸ್ ಅನ್ನು ಉಂಟುಮಾಡುವುದಿಲ್ಲ. ಎರಡನೆಯದಾಗಿ, ಲಿನಕ್ಸ್ ನೆಟ್ವರ್ಕ್ ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿ ಆಳವಾಗಿ ಅಗೆಯದೆ ಮತ್ತು ಅಗತ್ಯವಿರುವ ಗಾತ್ರಕ್ಕೆ "ಅಗಲದಲ್ಲಿ" ಶಾಂತವಾಗಿ ಬೆಳೆಯದೆ, 4 ಮಿಲಿಯನ್‌ಗಿಂತಲೂ ಹೆಚ್ಚು MPS ಅನ್ನು ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಸ್ಕೇಲಿಂಗ್.
ನಾವು ಸ್ಕೇಲಿಂಗ್‌ಗೆ ಸ್ಥಳಾವಕಾಶವನ್ನು ಹೊಂದಿದ್ದರಿಂದ, ನಾವು ತಪ್ಪು ಸಹಿಷ್ಣುತೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. "ಬಗ್ಗೆ! ದೋಷಸಹಿಷ್ಣುತೆ! ಇದು ಸರಳವಾಗಿದೆ, ನಾವು ಅದನ್ನು ಮಾಡಬಹುದು, ”ನಾವು ಯೋಚಿಸಿದ್ದೇವೆ ಮತ್ತು 2 ಸರ್ವರ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಪ್ರತಿಯೊಂದರಲ್ಲೂ ಬ್ರೂಬೆಕ್ ನಕಲನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ. ಇದನ್ನು ಮಾಡಲು, ನಾವು ಎರಡೂ ಸರ್ವರ್‌ಗಳಿಗೆ ಮೆಟ್ರಿಕ್‌ಗಳೊಂದಿಗೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಕಲಿಸಬೇಕಾಗಿತ್ತು ಮತ್ತು ಇದಕ್ಕಾಗಿ ಬರೆಯಬೇಕಾಗಿತ್ತು . ನಾವು ಇದರೊಂದಿಗೆ ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದ್ದೇವೆ, ಆದರೆ... ಚೆನ್ನಾಗಿಲ್ಲ. ಮೊದಲಿಗೆ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾಣುತ್ತದೆ: ಪ್ರತಿ ಬ್ರೂಬೆಕ್ ತನ್ನದೇ ಆದ ಸಂಗ್ರಹಣೆಯ ಆವೃತ್ತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಪ್ರತಿ 30 ಸೆಕೆಂಡಿಗೆ ಒಮ್ಮೆ ಗ್ರ್ಯಾಫೈಟ್‌ಗೆ ಡೇಟಾವನ್ನು ಬರೆಯುತ್ತದೆ, ಹಳೆಯ ಮಧ್ಯಂತರವನ್ನು ಮೇಲ್ಬರಹ ಮಾಡುತ್ತದೆ (ಇದನ್ನು ಗ್ರ್ಯಾಫೈಟ್ ಬದಿಯಲ್ಲಿ ಮಾಡಲಾಗುತ್ತದೆ). ಒಂದು ಸರ್ವರ್ ಹಠಾತ್ತನೆ ವಿಫಲವಾದರೆ, ನಾವು ಯಾವಾಗಲೂ ಸಂಯೋಜಿತ ಡೇಟಾದ ಅದರ ಸ್ವಂತ ಪ್ರತಿಯೊಂದಿಗೆ ಎರಡನೆಯದನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಆದರೆ ಇಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ: ಸರ್ವರ್ ವಿಫಲವಾದರೆ, ಗ್ರಾಫ್ಗಳಲ್ಲಿ "ಗರಗಸ" ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಇದು ಬ್ರೂಬೆಕ್‌ನ 30-ಸೆಕೆಂಡ್ ಮಧ್ಯಂತರಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡದಿರುವ ಕಾರಣದಿಂದಾಗಿ, ಮತ್ತು ಕುಸಿತದ ಕ್ಷಣದಲ್ಲಿ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ತಿದ್ದಿ ಬರೆಯಲಾಗಿಲ್ಲ. ಎರಡನೇ ಸರ್ವರ್ ಪ್ರಾರಂಭವಾದಾಗ, ಅದೇ ವಿಷಯ ಸಂಭವಿಸುತ್ತದೆ. ಸಾಕಷ್ಟು ಸಹನೀಯ, ಆದರೆ ನಾನು ಉತ್ತಮ ಬಯಸುತ್ತೇನೆ! ಸ್ಕೇಲೆಬಿಲಿಟಿ ಸಮಸ್ಯೆಯೂ ದೂರವಾಗಿಲ್ಲ. ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್‌ಗಳು ಇನ್ನೂ ಒಂದೇ ಸರ್ವರ್‌ಗೆ "ಹಾರುತ್ತವೆ" ಮತ್ತು ಆದ್ದರಿಂದ ನಾವು ನೆಟ್ವರ್ಕ್ ಮಟ್ಟವನ್ನು ಅವಲಂಬಿಸಿ ಅದೇ 2-4 ಮಿಲಿಯನ್ MPS ಗೆ ಸೀಮಿತವಾಗಿರುತ್ತೇವೆ.
ನೀವು ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಯೋಚಿಸಿದರೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಸಲಿಕೆಯೊಂದಿಗೆ ಹಿಮವನ್ನು ಅಗೆಯಿರಿ, ನಂತರ ಈ ಕೆಳಗಿನ ಸ್ಪಷ್ಟವಾದ ಕಲ್ಪನೆಯು ಮನಸ್ಸಿಗೆ ಬರಬಹುದು: ನಿಮಗೆ ವಿತರಣಾ ಕ್ರಮದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ statsd ಅಗತ್ಯವಿದೆ. ಅಂದರೆ, ಸಮಯ ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳಲ್ಲಿ ನೋಡ್‌ಗಳ ನಡುವೆ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. "ಖಂಡಿತವಾಗಿಯೂ, ಅಂತಹ ಪರಿಹಾರವು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ," ನಾವು ಹೇಳಿದರು ಮತ್ತು Google ಗೆ ಹೋದೆವು…. ಮತ್ತು ಅವರು ಏನನ್ನೂ ಕಂಡುಹಿಡಿಯಲಿಲ್ಲ. ವಿವಿಧ ಅಂಕಿಅಂಶಗಳಿಗಾಗಿ ದಸ್ತಾವೇಜನ್ನು ಹಾದುಹೋದ ನಂತರ ( ಡಿಸೆಂಬರ್ 11.12.2017, XNUMX ರಂತೆ), ನಾವು ಸಂಪೂರ್ಣವಾಗಿ ಏನನ್ನೂ ಕಂಡುಕೊಂಡಿಲ್ಲ. ಸ್ಪಷ್ಟವಾಗಿ, ಈ ಪರಿಹಾರಗಳ ಡೆವಲಪರ್‌ಗಳು ಅಥವಾ ಬಳಕೆದಾರರು ಇನ್ನೂ ಅನೇಕ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಎದುರಿಸಿಲ್ಲ, ಇಲ್ಲದಿದ್ದರೆ ಅವರು ಖಂಡಿತವಾಗಿಯೂ ಏನಾದರೂ ಬರುತ್ತಾರೆ.
ತದನಂತರ ನಾವು "ಆಟಿಕೆ" statsd - bioyino ಬಗ್ಗೆ ನೆನಪಿಸಿಕೊಂಡಿದ್ದೇವೆ, ಇದನ್ನು ಜಸ್ಟ್ ಫಾರ್ ಫನ್ ಹ್ಯಾಕಥಾನ್‌ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ (ಯೋಜನೆಯ ಹೆಸರನ್ನು ಹ್ಯಾಕಥಾನ್ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಸ್ಕ್ರಿಪ್ಟ್‌ನಿಂದ ರಚಿಸಲಾಗಿದೆ) ಮತ್ತು ನಮಗೆ ತುರ್ತಾಗಿ ನಮ್ಮದೇ ಆದ ಅಂಕಿಅಂಶಗಳ ಅಗತ್ಯವಿದೆ ಎಂದು ಅರಿತುಕೊಂಡೆವು. ಯಾವುದಕ್ಕಾಗಿ?
- ಏಕೆಂದರೆ ಪ್ರಪಂಚದಲ್ಲಿ ತುಂಬಾ ಕಡಿಮೆ statsd ತದ್ರೂಪುಗಳಿವೆ,
- ಏಕೆಂದರೆ ಅಪೇಕ್ಷಿತ ಅಥವಾ ಅಪೇಕ್ಷಿತ ದೋಷ ಸಹಿಷ್ಣುತೆ ಮತ್ತು ಸ್ಕೇಲೆಬಿಲಿಟಿಗೆ ಹತ್ತಿರವನ್ನು ಒದಗಿಸಲು ಸಾಧ್ಯವಿದೆ (ಸರ್ವರ್‌ಗಳ ನಡುವೆ ಒಟ್ಟುಗೂಡಿದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುವುದು ಮತ್ತು ಸಂಘರ್ಷಗಳನ್ನು ಕಳುಹಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವುದು ಸೇರಿದಂತೆ),
- ಏಕೆಂದರೆ ಬ್ರೂಬೆಕ್ ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ನಿಖರವಾಗಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಸಾಧ್ಯವಿದೆ,
- ಏಕೆಂದರೆ ಬ್ರೂಬೆಕ್ ಪ್ರಾಯೋಗಿಕವಾಗಿ ನಮಗೆ ಒದಗಿಸದ ಹೆಚ್ಚು ವಿವರವಾದ ಅಂಕಿಅಂಶಗಳನ್ನು ನೀವೇ ಸಂಗ್ರಹಿಸಬಹುದು,
- ಏಕೆಂದರೆ ನನ್ನದೇ ಆದ ಹೈಪರ್‌ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಡಿಸ್ಟ್ರಿಬ್ಯೂಡ್ ಸ್ಕೇಲ್ ಲ್ಯಾಬ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರೋಗ್ರಾಮ್ ಮಾಡಲು ನನಗೆ ಅವಕಾಶವಿತ್ತು, ಇದು ಇನ್ನೊಂದು ರೀತಿಯ ಹೈಪರ್‌ಫಾರ್‌ನ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪುನರಾವರ್ತಿಸುವುದಿಲ್ಲ ... ಅಲ್ಲದೆ, ಅದು ಇಲ್ಲಿದೆ.
ಏನು ಬರೆಯಬೇಕು? ಸಹಜವಾಗಿ, ರಸ್ಟ್ನಲ್ಲಿ. ಏಕೆ?
- ಏಕೆಂದರೆ ಈಗಾಗಲೇ ಮೂಲಮಾದರಿಯ ಪರಿಹಾರವಿತ್ತು,
- ಏಕೆಂದರೆ ಲೇಖನದ ಲೇಖಕರು ಆ ಸಮಯದಲ್ಲಿ ರಸ್ಟ್ ಅನ್ನು ಈಗಾಗಲೇ ತಿಳಿದಿದ್ದರು ಮತ್ತು ಅದನ್ನು ಮುಕ್ತ ಮೂಲದಲ್ಲಿ ಹಾಕುವ ಅವಕಾಶದೊಂದಿಗೆ ಉತ್ಪಾದನೆಗಾಗಿ ಏನನ್ನಾದರೂ ಬರೆಯಲು ಉತ್ಸುಕರಾಗಿದ್ದರು,
- ಏಕೆಂದರೆ GC ಯೊಂದಿಗಿನ ಭಾಷೆಗಳು ಸ್ವೀಕರಿಸಿದ ದಟ್ಟಣೆಯ ಸ್ವರೂಪದಿಂದಾಗಿ ನಮಗೆ ಸೂಕ್ತವಲ್ಲ (ಬಹುತೇಕ ನೈಜ ಸಮಯದಲ್ಲಿ) ಮತ್ತು GC ವಿರಾಮಗಳು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ,
- ಏಕೆಂದರೆ ನಿಮಗೆ ಸಿ ಗೆ ಹೋಲಿಸಬಹುದಾದ ಗರಿಷ್ಠ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಗತ್ಯವಿದೆ
- ಏಕೆಂದರೆ ರಸ್ಟ್ ನಮಗೆ ನಿರ್ಭೀತವಾದ ಸಮನ್ವಯತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ, ಮತ್ತು ನಾವು ಅದನ್ನು C/C++ ನಲ್ಲಿ ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ನಾವು ಬ್ರೂಬೆಕ್‌ಗಿಂತ ಹೆಚ್ಚಿನ ದುರ್ಬಲತೆಗಳು, ಬಫರ್ ಓವರ್‌ಫ್ಲೋಗಳು, ಓಟದ ಪರಿಸ್ಥಿತಿಗಳು ಮತ್ತು ಇತರ ಭಯಾನಕ ಪದಗಳಲ್ಲಿ ಸಿಲುಕಿದ್ದೇವೆ.
ರಸ್ಟ್ ವಿರುದ್ಧ ವಾದವೂ ನಡೆಯಿತು. ಕಂಪನಿಯು ರಸ್ಟ್ನಲ್ಲಿ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ರಚಿಸುವ ಅನುಭವವನ್ನು ಹೊಂದಿರಲಿಲ್ಲ ಮತ್ತು ಈಗ ನಾವು ಅದನ್ನು ಮುಖ್ಯ ಯೋಜನೆಯಲ್ಲಿ ಬಳಸಲು ಯೋಜಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಏನೂ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಎಂಬ ಗಂಭೀರ ಭಯವಿತ್ತು, ಆದರೆ ನಾವು ಅವಕಾಶವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ.
ಸಮಯ ಕಳೆಯಿತು...
ಅಂತಿಮವಾಗಿ, ಹಲವಾರು ವಿಫಲ ಪ್ರಯತ್ನಗಳ ನಂತರ, ಮೊದಲ ಕೆಲಸದ ಆವೃತ್ತಿ ಸಿದ್ಧವಾಗಿದೆ. ಏನಾಯಿತು? ಇದೇನಾಯಿತು.
ಪ್ರತಿಯೊಂದು ನೋಡ್ ತನ್ನದೇ ಆದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಅಂತಿಮ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಗೆ ಅವುಗಳ ಸಂಪೂರ್ಣ ಸೆಟ್ ಅಗತ್ಯವಿರುವ ಆ ಪ್ರಕಾರಗಳಿಗೆ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುವುದಿಲ್ಲ. ನೋಡ್‌ಗಳು ಕೆಲವು ರೀತಿಯ ವಿತರಿಸಿದ ಲಾಕ್ ಪ್ರೋಟೋಕಾಲ್‌ನಿಂದ ಒಂದಕ್ಕೊಂದು ಸಂಪರ್ಕ ಹೊಂದಿವೆ, ಇದು ಗ್ರೇಟ್ ಒನ್‌ಗೆ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಕಳುಹಿಸಲು ಯೋಗ್ಯವಾದ ಏಕೈಕ (ಇಲ್ಲಿ ನಾವು ಅಳುತ್ತಿದ್ದೆವು) ಆಯ್ಕೆ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಪ್ರಸ್ತುತ ಪರಿಹರಿಸಲಾಗುತ್ತಿದೆ , ಆದರೆ ಭವಿಷ್ಯದಲ್ಲಿ ಲೇಖಕರ ಮಹತ್ವಾಕಾಂಕ್ಷೆಗಳು ವಿಸ್ತರಿಸುತ್ತವೆ ರಾಫ್ಟ್, ಅಲ್ಲಿ ಅತ್ಯಂತ ಯೋಗ್ಯರು, ಸಹಜವಾಗಿ, ಒಮ್ಮತದ ನಾಯಕ ನೋಡ್ ಆಗಿರುತ್ತಾರೆ. ಒಮ್ಮತದ ಜೊತೆಗೆ, ನೋಡ್‌ಗಳು ಆಗಾಗ್ಗೆ (ಡೀಫಾಲ್ಟ್ ಆಗಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಒಮ್ಮೆ) ತಮ್ಮ ನೆರೆಹೊರೆಯವರಿಗೆ ಆ ಸೆಕೆಂಡಿನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದ ಪೂರ್ವ-ಸಂಗ್ರಹಿಸಿದ ಮೆಟ್ರಿಕ್‌ಗಳ ಭಾಗಗಳನ್ನು ಕಳುಹಿಸುತ್ತವೆ. ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಸಂರಕ್ಷಿಸಲಾಗಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ - ಪ್ರತಿ ನೋಡ್ ಇನ್ನೂ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಈಗಾಗಲೇ ಒಟ್ಟುಗೂಡಿಸಿ, TCP ಮೂಲಕ ಕಳುಹಿಸಲಾಗಿದೆ ಮತ್ತು ಬೈನರಿ ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಎನ್‌ಕೋಡ್ ಮಾಡಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಯುಡಿಪಿಗೆ ಹೋಲಿಸಿದರೆ ನಕಲು ವೆಚ್ಚಗಳು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ. ಸಾಕಷ್ಟು ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಒಳಬರುವ ಮೆಟ್ರಿಕ್‌ಗಳ ಹೊರತಾಗಿಯೂ, ಸಂಗ್ರಹಣೆಗೆ ಬಹಳ ಕಡಿಮೆ ಮೆಮೊರಿ ಮತ್ತು ಕಡಿಮೆ CPU ಅಗತ್ಯವಿರುತ್ತದೆ. ನಮ್ಮ ಹೆಚ್ಚು ಸಂಕುಚಿತ ಮರ್ಟಿಕ್ಸ್‌ಗಾಗಿ, ಇದು ಕೆಲವೇ ಹತ್ತಾರು ಮೆಗಾಬೈಟ್‌ಗಳ ಡೇಟಾ. ಹೆಚ್ಚುವರಿ ಬೋನಸ್ ಆಗಿ, ಬರ್ಬೆಕ್‌ನಂತೆಯೇ ನಾವು ಗ್ರ್ಯಾಫೈಟ್‌ನಲ್ಲಿ ಯಾವುದೇ ಅನಗತ್ಯ ಡೇಟಾ ಪುನಃ ಬರೆಯುವಿಕೆಯನ್ನು ಪಡೆಯುವುದಿಲ್ಲ.
ಮೆಟ್ರಿಕ್‌ಗಳೊಂದಿಗೆ UDP ಪ್ಯಾಕೆಟ್‌ಗಳು ಸರಳ ರೌಂಡ್ ರಾಬಿನ್ ಮೂಲಕ ನೆಟ್ವರ್ಕ್ ಉಪಕರಣಗಳಲ್ಲಿನ ನೋಡ್‌ಗಳ ನಡುವೆ ಅಸಮತೋಲಿತವಾಗಿರುತ್ತವೆ. ಸಹಜವಾಗಿ, ನೆಟ್ವರ್ಕ್ ಹಾರ್ಡ್‌ವೇರ್ ಪ್ಯಾಕೆಟ್ಗಳ ವಿಷಯಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಆದ್ದರಿಂದ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 4M ಪ್ಯಾಕೆಟ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಎಳೆಯಬಹುದು, ಅದು ಏನನ್ನೂ ತಿಳಿದಿಲ್ಲದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ನಮೂದಿಸಬಾರದು. ಪ್ರತಿ ಪ್ಯಾಕೆಟ್‌ನಲ್ಲಿ ಮೆಟ್ರಿಕ್‌ಗಳು ಒಂದೊಂದಾಗಿ ಬರುವುದಿಲ್ಲ ಎಂದು ನಾವು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡರೆ, ಈ ಸ್ಥಳದಲ್ಲಿ ಯಾವುದೇ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ನಾವು ನಿರೀಕ್ಷಿಸುವುದಿಲ್ಲ. ಸರ್ವರ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ, ನೆಟ್ವರ್ಕ್ ಸಾಧನವು ತ್ವರಿತವಾಗಿ (1-2 ಸೆಕೆಂಡುಗಳಲ್ಲಿ) ಈ ಸತ್ಯವನ್ನು ಪತ್ತೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕ್ರ್ಯಾಶ್ ಆದ ಸರ್ವರ್ ಅನ್ನು ತಿರುಗುವಿಕೆಯಿಂದ ತೆಗೆದುಹಾಕುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ, ಚಾರ್ಟ್‌ಗಳಲ್ಲಿನ ಡ್ರಾಡೌನ್‌ಗಳನ್ನು ಗಮನಿಸದೆ ನಿಷ್ಕ್ರಿಯ (ಅಂದರೆ, ನಾಯಕರಲ್ಲದ) ನೋಡ್‌ಗಳನ್ನು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಆನ್ ಮತ್ತು ಆಫ್ ಮಾಡಬಹುದು. ನಾವು ಕಳೆದುಕೊಳ್ಳುವ ಗರಿಷ್ಠವು ಕೊನೆಯ ಸೆಕೆಂಡಿನಲ್ಲಿ ಬಂದ ಮೆಟ್ರಿಕ್‌ಗಳ ಭಾಗವಾಗಿದೆ. ನಾಯಕನ ಹಠಾತ್ ನಷ್ಟ/ಸ್ಥಗಿತ/ಸ್ವಿಚ್ ಇನ್ನೂ ಸಣ್ಣ ಅಸಂಗತತೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ (30 ಸೆಕೆಂಡ್ ಮಧ್ಯಂತರವು ಇನ್ನೂ ಸಿಂಕ್ ಆಗಿಲ್ಲ), ಆದರೆ ನೋಡ್‌ಗಳ ನಡುವೆ ಸಂವಹನವಿದ್ದರೆ, ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು, ಉದಾಹರಣೆಗೆ, ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ .
ಆಂತರಿಕ ರಚನೆಯ ಬಗ್ಗೆ ಸ್ವಲ್ಪ. ಅಪ್ಲಿಕೇಶನ್, ಸಹಜವಾಗಿ, ಮಲ್ಟಿಥ್ರೆಡ್ ಆಗಿದೆ, ಆದರೆ ಥ್ರೆಡಿಂಗ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಬ್ರೂಬೆಕ್‌ನಲ್ಲಿ ಬಳಸುವುದಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿದೆ. ಬ್ರೂಬೆಕ್‌ನಲ್ಲಿನ ಎಳೆಗಳು ಒಂದೇ ಆಗಿರುತ್ತವೆ - ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಮಾಹಿತಿ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಗೆ ಕಾರಣವಾಗಿದೆ. ಬಯೋಯಿನೊದಲ್ಲಿ, ಕಾರ್ಮಿಕರನ್ನು ಎರಡು ಗುಂಪುಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ: ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಜವಾಬ್ದಾರರು ಮತ್ತು ಒಟ್ಟುಗೂಡಿಸುವ ಜವಾಬ್ದಾರಿ ಹೊಂದಿರುವವರು. ಮೆಟ್ರಿಕ್‌ಗಳ ಪ್ರಕಾರವನ್ನು ಅವಲಂಬಿಸಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೆಚ್ಚು ಮೃದುವಾಗಿ ನಿರ್ವಹಿಸಲು ಈ ವಿಭಾಗವು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ: ತೀವ್ರವಾದ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯ ಅಗತ್ಯವಿರುವಲ್ಲಿ, ನೀವು ಒಟ್ಟುಗೂಡಿಸುವವರನ್ನು ಸೇರಿಸಬಹುದು, ಅಲ್ಲಿ ಸಾಕಷ್ಟು ನೆಟ್ವರ್ಕ್ ಟ್ರಾಫಿಕ್ ಇದೆ, ನೀವು ನೆಟ್ವರ್ಕ್ ಹರಿವಿನ ಸಂಖ್ಯೆಯನ್ನು ಸೇರಿಸಬಹುದು. ಈ ಸಮಯದಲ್ಲಿ, ನಮ್ಮ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ನಾವು 8 ನೆಟ್ವರ್ಕ್ ಮತ್ತು 4 ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ.
ಎಣಿಕೆ (ಒಟ್ಟುಗೂಡುವಿಕೆಗೆ ಜವಾಬ್ದಾರಿ) ಭಾಗವು ಸಾಕಷ್ಟು ನೀರಸವಾಗಿದೆ. ನೆಟ್ವರ್ಕ್ ಹರಿವುಗಳಿಂದ ತುಂಬಿದ ಬಫರ್ಗಳನ್ನು ಎಣಿಕೆಯ ಹರಿವಿನ ನಡುವೆ ವಿತರಿಸಲಾಗುತ್ತದೆ, ಅಲ್ಲಿ ಅವುಗಳನ್ನು ನಂತರ ಪಾರ್ಸ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಒಟ್ಟುಗೂಡಿಸಲಾಗುತ್ತದೆ. ವಿನಂತಿಯ ಮೇರೆಗೆ, ಇತರ ನೋಡ್‌ಗಳಿಗೆ ಕಳುಹಿಸಲು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ನೀಡಲಾಗುತ್ತದೆ. ನೋಡ್‌ಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವುದು ಮತ್ತು ಕಾನ್ಸುಲ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಸೇರಿದಂತೆ ಇವೆಲ್ಲವನ್ನೂ ಅಸಮಕಾಲಿಕವಾಗಿ ನಡೆಸಲಾಗುತ್ತದೆ, ಫ್ರೇಮ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿದೆ .
ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಜವಾಬ್ದಾರರಾಗಿರುವ ನೆಟ್ವರ್ಕ್ ಭಾಗದಿಂದ ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳು ಉಂಟಾಗುತ್ತವೆ. ನೆಟ್ವರ್ಕ್ ಹರಿವುಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಘಟಕಗಳಾಗಿ ಬೇರ್ಪಡಿಸುವ ಮುಖ್ಯ ಗುರಿಯು ಹರಿವು ಕಳೆಯುವ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಬಯಕೆಯಾಗಿದೆ ಕೇವಲ ಸಾಕೆಟ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಓದಲು. ಅಸಮಕಾಲಿಕ UDP ಮತ್ತು ನಿಯಮಿತ recvmsg ಅನ್ನು ಬಳಸುವ ಆಯ್ಕೆಗಳು ತ್ವರಿತವಾಗಿ ಕಣ್ಮರೆಯಾಯಿತು: ಮೊದಲನೆಯದು ಈವೆಂಟ್ ಪ್ರಕ್ರಿಯೆಗೆ ಹೆಚ್ಚು ಬಳಕೆದಾರ-ಸ್ಥಳದ CPU ಅನ್ನು ಬಳಸುತ್ತದೆ, ಎರಡನೆಯದಕ್ಕೆ ಹಲವಾರು ಸಂದರ್ಭ ಸ್ವಿಚ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ. ಆದ್ದರಿಂದ ಇದನ್ನು ಈಗ ಬಳಸಲಾಗುತ್ತದೆ ದೊಡ್ಡ ಬಫರ್‌ಗಳೊಂದಿಗೆ (ಮತ್ತು ಬಫರ್‌ಗಳು, ಜಂಟಲ್‌ಮೆನ್ ಅಧಿಕಾರಿಗಳು, ನಿಮಗೆ ಏನೂ ಅಲ್ಲ!). recvmmsg ಅಗತ್ಯವಿಲ್ಲದ ಬೆಳಕಿನ ಪ್ರಕರಣಗಳಿಗೆ ಸಾಮಾನ್ಯ UDP ಗಾಗಿ ಬೆಂಬಲವನ್ನು ಕಾಯ್ದಿರಿಸಲಾಗಿದೆ. ಮಲ್ಟಿಮೆಸೇಜ್ ಮೋಡ್‌ನಲ್ಲಿ, ಮುಖ್ಯ ವಿಷಯವನ್ನು ಸಾಧಿಸಲು ಸಾಧ್ಯವಿದೆ: ಬಹುಪಾಲು ಸಮಯ, ನೆಟ್ವರ್ಕ್ ಥ್ರೆಡ್ ಓಎಸ್ ಕ್ಯೂ ಅನ್ನು ರೇಕ್ ಮಾಡುತ್ತದೆ - ಸಾಕೆಟ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಓದುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಯೂಸರ್‌ಸ್ಪೇಸ್ ಬಫರ್‌ಗೆ ವರ್ಗಾಯಿಸುತ್ತದೆ, ಸಾಂದರ್ಭಿಕವಾಗಿ ತುಂಬಿದ ಬಫರ್ ಅನ್ನು ನೀಡಲು ಬದಲಾಯಿಸುತ್ತದೆ ಒಟ್ಟುಗೂಡಿಸುವವರು. ಸಾಕೆಟ್ನಲ್ಲಿನ ಕ್ಯೂ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಸಂಗ್ರಹವಾಗುವುದಿಲ್ಲ, ಕೈಬಿಡಲಾದ ಪ್ಯಾಕೆಟ್ಗಳ ಸಂಖ್ಯೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಬೆಳೆಯುವುದಿಲ್ಲ.
ಹೇಳಿಕೆಯನ್ನು
ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ, ಬಫರ್ ಗಾತ್ರವನ್ನು ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿ ಹೊಂದಿಸಲಾಗಿದೆ. ಸರ್ವರ್ ಅನ್ನು ನೀವೇ ಪ್ರಯತ್ನಿಸಲು ನೀವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನಿರ್ಧರಿಸಿದರೆ, ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಕಳುಹಿಸಿದ ನಂತರ, ಅವರು ಗ್ರ್ಯಾಫೈಟ್‌ನಲ್ಲಿ ಬರುವುದಿಲ್ಲ, ನೆಟ್ವರ್ಕ್ ಸ್ಟ್ರೀಮ್ ಬಫರ್‌ನಲ್ಲಿ ಉಳಿಯುತ್ತಾರೆ ಎಂಬ ಅಂಶವನ್ನು ನೀವು ಎದುರಿಸಬಹುದು. ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಮೆಟ್ರಿಕ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು, ನೀವು ಬಫ್‌ಸೈಜ್ ಮತ್ತು ಟಾಸ್ಕ್-ಕ್ಯೂ-ಗಾತ್ರವನ್ನು ಕಾನ್ಫಿಗರ್‌ನಲ್ಲಿ ಸಣ್ಣ ಮೌಲ್ಯಗಳಿಗೆ ಹೊಂದಿಸಬೇಕಾಗುತ್ತದೆ.
ಅಂತಿಮವಾಗಿ, ಚಾರ್ಟ್ ಪ್ರಿಯರಿಗಾಗಿ ಕೆಲವು ಚಾರ್ಟ್ಗಳು.
ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ ಒಳಬರುವ ಮೆಟ್ರಿಕ್‌ಗಳ ಸಂಖ್ಯೆಯ ಅಂಕಿಅಂಶಗಳು: 2 ಮಿಲಿಯನ್‌ಗಿಂತಲೂ ಹೆಚ್ಚು MPS.
ನೋಡ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗುತ್ತಿದೆ ಮತ್ತು ಒಳಬರುವ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡಲಾಗುತ್ತಿದೆ.
ಹೊರಹೋಗುವ ಮೆಟ್ರಿಕ್‌ಗಳ ಅಂಕಿಅಂಶಗಳು: ಕೇವಲ ಒಂದು ನೋಡ್ ಯಾವಾಗಲೂ ಕಳುಹಿಸುತ್ತದೆ - ರೈಡ್ ಬಾಸ್.
ಪ್ರತಿ ನೋಡ್ನ ಕಾರ್ಯಾಚರಣೆಯ ಅಂಕಿಅಂಶಗಳು, ವಿವಿಧ ಸಿಸ್ಟಮ್ ಮಾಡ್ಯೂಲ್ಗಳಲ್ಲಿನ ದೋಷಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಒಳಬರುವ ಮೆಟ್ರಿಕ್‌ಗಳ ವಿವರಗಳು (ಮೆಟ್ರಿಕ್ ಹೆಸರುಗಳನ್ನು ಮರೆಮಾಡಲಾಗಿದೆ).
ಇದನ್ನೆಲ್ಲ ಮುಂದಿಟ್ಟುಕೊಂಡು ನಾವು ಏನು ಮಾಡಲು ಯೋಜಿಸುತ್ತಿದ್ದೇವೆ? ಖಂಡಿತ, ಕೋಡ್ ಬರೆಯಿರಿ, ಡ್ಯಾಮ್...! ಯೋಜನೆಯು ಮೂಲತಃ ತೆರೆದ ಮೂಲವಾಗಿರಲು ಯೋಜಿಸಲಾಗಿತ್ತು ಮತ್ತು ಅದರ ಜೀವನದುದ್ದಕ್ಕೂ ಹಾಗೆಯೇ ಇರುತ್ತದೆ. ನಮ್ಮದೇ ಆದ ರಾಫ್ಟ್ ಆವೃತ್ತಿಗೆ ಬದಲಾಯಿಸುವುದು, ಪೀರ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಹೆಚ್ಚು ಪೋರ್ಟಬಲ್ ಆಗಿ ಬದಲಾಯಿಸುವುದು, ಹೆಚ್ಚುವರಿ ಆಂತರಿಕ ಅಂಕಿಅಂಶಗಳನ್ನು ಪರಿಚಯಿಸುವುದು, ಹೊಸ ರೀತಿಯ ಮೆಟ್ರಿಕ್‌ಗಳು, ದೋಷ ಪರಿಹಾರಗಳು ಮತ್ತು ಇತರ ಸುಧಾರಣೆಗಳನ್ನು ನಮ್ಮ ತಕ್ಷಣದ ಯೋಜನೆಗಳು ಒಳಗೊಂಡಿವೆ.
ಸಹಜವಾಗಿ, ಯೋಜನೆಯ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಸಹಾಯ ಮಾಡಲು ಎಲ್ಲರಿಗೂ ಸ್ವಾಗತವಿದೆ: PR, ಸಮಸ್ಯೆಗಳನ್ನು ರಚಿಸಿ, ಸಾಧ್ಯವಾದರೆ ನಾವು ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತೇವೆ, ಸುಧಾರಿಸುತ್ತೇವೆ, ಇತ್ಯಾದಿ.
ಹೀಗೆ ಹೇಳುತ್ತಾ ಹೋದರೆ, ಜನಜನರೇ, ನಮ್ಮ ಆನೆಗಳನ್ನು ಖರೀದಿಸಿ!
ಮೂಲ: www.habr.com