ರಿಮೋಟ್‌ನಲ್ಲಿ x10 ಲೋಡ್‌ನಲ್ಲಿ ತೀಕ್ಷ್ಣವಾದ ಹೆಚ್ಚಳದಿಂದ ನಾವು ಹೇಗೆ ಬದುಕುಳಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಯಾವ ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ

ಹಲೋ, ಹಬ್ರ್! ಕಳೆದ ಎರಡು ತಿಂಗಳುಗಳಿಂದ ನಾವು ತುಂಬಾ ಆಸಕ್ತಿದಾಯಕ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ವಾಸಿಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ನಮ್ಮ ಮೂಲಸೌಕರ್ಯ ಸ್ಕೇಲಿಂಗ್ ಕಥೆಯನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನಾನು ಬಯಸುತ್ತೇನೆ. ಈ ಸಮಯದಲ್ಲಿ, SberMarket 4 ಬಾರಿ ಆರ್ಡರ್‌ಗಳಲ್ಲಿ ಬೆಳೆದಿದೆ ಮತ್ತು 17 ಹೊಸ ನಗರಗಳಲ್ಲಿ ಸೇವೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದೆ. ದಿನಸಿ ವಿತರಣೆಯ ಬೇಡಿಕೆಯಲ್ಲಿ ಸ್ಫೋಟಕ ಬೆಳವಣಿಗೆಯು ನಮ್ಮ ಮೂಲಸೌಕರ್ಯವನ್ನು ಅಳೆಯುವ ಅಗತ್ಯವಿದೆ. ಕಟ್ ಅಡಿಯಲ್ಲಿ ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ಮತ್ತು ಉಪಯುಕ್ತ ತೀರ್ಮಾನಗಳ ಬಗ್ಗೆ ಓದಿ.

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

ತಂಡವನ್ನು ನಿರ್ವಹಿಸುವಾಗ, ವ್ಯವಹಾರಕ್ಕೆ ಏನು ಬೇಕು ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬ ಡೆವಲಪರ್‌ನ ಅಗತ್ಯತೆಗಳ ನಡುವೆ ಸಮತೋಲನವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಮುಖ್ಯವಾಗಿದೆ. ಈಗ SberMarket ವರ್ಷದಿಂದ ವರ್ಷಕ್ಕೆ 13 ಬಾರಿ ಬೆಳೆಯುತ್ತಿದೆ, ಮತ್ತು ಇದು ಉತ್ಪನ್ನದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ, ನಿರಂತರವಾಗಿ ಅಭಿವೃದ್ಧಿಯ ಪರಿಮಾಣ ಮತ್ತು ವೇಗವನ್ನು ಹೆಚ್ಚಿಸುವ ಅಗತ್ಯವಿರುತ್ತದೆ. ಇದರ ಹೊರತಾಗಿಯೂ, ಪ್ರಾಥಮಿಕ ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ಗುಣಮಟ್ಟದ ಕೋಡಿಂಗ್‌ಗಾಗಿ ನಾವು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ. ರೂಪುಗೊಂಡ ವಿಧಾನವು ಕೆಲಸದ ಉತ್ಪನ್ನವನ್ನು ರಚಿಸುವಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ ಅದರ ಮತ್ತಷ್ಟು ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿಯೂ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಈ ಬೆಳವಣಿಗೆಯ ಪರಿಣಾಮವಾಗಿ, SberMarket ಈಗಾಗಲೇ ಕಿರಾಣಿ ವಿತರಣಾ ಸೇವೆಗಳಲ್ಲಿ ಮುಂಚೂಣಿಯಲ್ಲಿದೆ: ನಾವು ಪ್ರತಿದಿನ ಸುಮಾರು 18 ಸಾವಿರ ಆದೇಶಗಳನ್ನು ವಿತರಿಸುತ್ತೇವೆ, ಆದರೂ ಫೆಬ್ರವರಿ ಆರಂಭದಲ್ಲಿ ಸುಮಾರು 3500 ಇತ್ತು.

ಒಂದು ದಿನ, ಗ್ರಾಹಕರೊಬ್ಬರು SberMarket ಕೊರಿಯರ್‌ಗೆ ದಿನಸಿ ವಸ್ತುಗಳನ್ನು ಸಂಪರ್ಕವಿಲ್ಲದೆ ಬಾಲ್ಕನಿಯಲ್ಲಿ ತಲುಪಿಸಲು ಕೇಳಿದರು.

ಆದರೆ ನಿಶ್ಚಿತಗಳಿಗೆ ಹೋಗೋಣ. ಕಳೆದ ಕೆಲವು ತಿಂಗಳುಗಳಲ್ಲಿ, ನಾವು ನಮ್ಮ ಕಂಪನಿಯ ಮೂಲಸೌಕರ್ಯವನ್ನು ಸಕ್ರಿಯವಾಗಿ ಅಳೆಯುತ್ತಿದ್ದೇವೆ. ಈ ಅಗತ್ಯವನ್ನು ಬಾಹ್ಯ ಮತ್ತು ಆಂತರಿಕ ಅಂಶಗಳಿಂದ ವಿವರಿಸಲಾಗಿದೆ. ಗ್ರಾಹಕರ ನೆಲೆಯ ವಿಸ್ತರಣೆಯ ಜೊತೆಗೆ, ಸಂಪರ್ಕಿತ ಮಳಿಗೆಗಳ ಸಂಖ್ಯೆಯು ವರ್ಷದ ಆರಂಭದಲ್ಲಿ 90 ರಿಂದ ಮೇ ಮಧ್ಯದ ವೇಳೆಗೆ 200 ಕ್ಕಿಂತ ಹೆಚ್ಚಾಯಿತು. ನಾವು ಸಹಜವಾಗಿ ಸಿದ್ಧಪಡಿಸಿದ್ದೇವೆ, ಮುಖ್ಯ ಮೂಲಸೌಕರ್ಯವನ್ನು ಕಾಯ್ದಿರಿಸಿದ್ದೇವೆ, ಜೊತೆಗೆ ಯಾಂಡೆಕ್ಸ್ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾಡಲಾದ ಎಲ್ಲಾ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳ ಲಂಬ ಮತ್ತು ಅಡ್ಡ ಸ್ಕೇಲಿಂಗ್ ಸಾಧ್ಯತೆಯನ್ನು ನಾವು ಎಣಿಕೆ ಮಾಡಿದ್ದೇವೆ. ಆದಾಗ್ಯೂ, ಅಭ್ಯಾಸವು ತೋರಿಸಿದೆ: "ತಪ್ಪಾಗಬಹುದಾದ ಎಲ್ಲವೂ ತಪ್ಪಾಗುತ್ತದೆ." ಮತ್ತು ಇಂದು ನಾನು ಈ ವಾರಗಳಲ್ಲಿ ಸಂಭವಿಸಿದ ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ಸನ್ನಿವೇಶಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇನೆ. ನಮ್ಮ ಅನುಭವವು ನಿಮಗೆ ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಸ್ಲೇವ್ ಸಂಪೂರ್ಣ ಯುದ್ಧ ಸನ್ನದ್ಧತೆಯಲ್ಲಿದೆ

ಸಾಂಕ್ರಾಮಿಕ ರೋಗವು ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲೇ, ನಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಸರ್ವರ್‌ಗಳಿಗೆ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿ ಹೆಚ್ಚಳವನ್ನು ನಾವು ಎದುರಿಸಿದ್ದೇವೆ. ಹೋಮ್ ಡೆಲಿವರಿಗಾಗಿ ದಿನಸಿಗಳನ್ನು ಆರ್ಡರ್ ಮಾಡುವ ಪ್ರವೃತ್ತಿಯು ಆವೇಗವನ್ನು ಪಡೆಯಲಾರಂಭಿಸಿತು ಮತ್ತು COVID-19 ಕಾರಣದಿಂದಾಗಿ ಮೊದಲ ಸ್ವಯಂ-ಪ್ರತ್ಯೇಕತೆಯ ಕ್ರಮಗಳ ಪರಿಚಯದೊಂದಿಗೆ, ಕೆಲಸದ ಹೊರೆ ದಿನವಿಡೀ ನಾಟಕೀಯವಾಗಿ ಬೆಳೆಯಿತು. ಮುಖ್ಯ ಡೇಟಾಬೇಸ್‌ನ ಮಾಸ್ಟರ್ ಸರ್ವರ್‌ಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಅನ್‌ಲೋಡ್ ಮಾಡುವ ಅವಶ್ಯಕತೆಯಿದೆ ಮತ್ತು ಕೆಲವು ಓದುವ ವಿನಂತಿಗಳನ್ನು ಪ್ರತಿಕೃತಿ ಸರ್ವರ್‌ಗಳಿಗೆ (ಗುಲಾಮ) ವರ್ಗಾಯಿಸುತ್ತದೆ.

ನಾವು ಈ ಹಂತಕ್ಕೆ ಮುಂಚಿತವಾಗಿ ಸಿದ್ಧಪಡಿಸಿದ್ದೇವೆ ಮತ್ತು ಅಂತಹ ಕುಶಲತೆಗಾಗಿ 2 ಸ್ಲೇವ್ ಸರ್ವರ್‌ಗಳನ್ನು ಈಗಾಗಲೇ ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ. ಪಾಲುದಾರರೊಂದಿಗೆ ಡೇಟಾ ವಿನಿಮಯಕ್ಕಾಗಿ ಮಾಹಿತಿ ಫೀಡ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಬ್ಯಾಚ್ ಕಾರ್ಯಗಳಿಗಾಗಿ ಅವುಗಳನ್ನು ಮುಖ್ಯವಾಗಿ ಬಳಸಲಾಗುತ್ತಿತ್ತು. ಈ ಪ್ರಕ್ರಿಯೆಗಳು ಹೆಚ್ಚುವರಿ ಹೊರೆಯನ್ನು ಸೃಷ್ಟಿಸಿದವು ಮತ್ತು ಒಂದೆರಡು ತಿಂಗಳ ಹಿಂದೆ ಸಮೀಕರಣದಿಂದ ಸರಿಯಾಗಿ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ. 

ಸ್ಲೇವ್‌ನಲ್ಲಿ ನಕಲು ಸಂಭವಿಸಿದಾಗಿನಿಂದ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಅವರೊಂದಿಗೆ ಓದಲು ಮಾತ್ರ ಮೋಡ್‌ನಲ್ಲಿ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬ ಪರಿಕಲ್ಪನೆಗೆ ನಾವು ಬದ್ಧರಾಗಿದ್ದೇವೆ. ವಿಪತ್ತು ಮರುಪಡೆಯುವಿಕೆ ಯೋಜನೆಯು ವಿಪತ್ತಿನ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಸ್ಲೇವ್ ಅನ್ನು ಮಾಸ್ಟರ್ ಬದಲಿಗೆ ಸರಳವಾಗಿ ಆರೋಹಿಸಬಹುದು ಮತ್ತು ಎಲ್ಲಾ ಬರೆಯುವ ಮತ್ತು ಓದುವ ವಿನಂತಿಗಳನ್ನು ಸ್ಲೇವ್‌ಗೆ ಬದಲಾಯಿಸಬಹುದು ಎಂದು ಊಹಿಸಲಾಗಿದೆ. ಆದಾಗ್ಯೂ, ನಾವು ವಿಶ್ಲೇಷಣಾ ವಿಭಾಗದ ಅಗತ್ಯಗಳಿಗಾಗಿ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಬಳಸಲು ಬಯಸಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಸರ್ವರ್‌ಗಳನ್ನು ಓದಲು ಮಾತ್ರ ಸ್ಥಿತಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಲಾಗಿಲ್ಲ, ಆದರೆ ಪ್ರತಿ ಹೋಸ್ಟ್ ತನ್ನದೇ ಆದ ಬಳಕೆದಾರರನ್ನು ಹೊಂದಿತ್ತು, ಮತ್ತು ಕೆಲವರು ಮಧ್ಯಂತರ ಲೆಕ್ಕಾಚಾರದ ಫಲಿತಾಂಶಗಳನ್ನು ಉಳಿಸಲು ಬರೆಯುವ ಹಕ್ಕುಗಳನ್ನು ಹೊಂದಿದ್ದರು.

ಒಂದು ನಿರ್ದಿಷ್ಟ ಲೋಡ್ ಹಂತದವರೆಗೆ, http ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಾಗ ನಾವು ಬರೆಯಲು ಮತ್ತು ಓದಲು ಸಾಕಷ್ಟು ಮಾಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮಾರ್ಚ್ ಮಧ್ಯದಲ್ಲಿ, Sbermarket ರಿಮೋಟ್ ಕೆಲಸಕ್ಕೆ ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಲು ನಿರ್ಧರಿಸಿದಾಗ, ನಮ್ಮ RPS ಘಾತೀಯವಾಗಿ ಬೆಳೆಯಲು ಪ್ರಾರಂಭಿಸಿತು. ನಮ್ಮ ಹೆಚ್ಚು ಹೆಚ್ಚು ಗ್ರಾಹಕರು ಸ್ವಯಂ-ಪ್ರತ್ಯೇಕತೆಗೆ ಹೋದರು ಅಥವಾ ಮನೆಯಿಂದಲೇ ಕೆಲಸ ಮಾಡಿದರು, ಇದು ನಮ್ಮ ಕೆಲಸದ ಹೊರೆ ಸೂಚಕಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಿತು.

"ಮಾಸ್ಟರ್" ನ ಕಾರ್ಯಕ್ಷಮತೆ ಇನ್ನು ಮುಂದೆ ಸಾಕಾಗಲಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು ಪ್ರತಿಕೃತಿಗೆ ಕೆಲವು ಭಾರೀ ಓದುವ ವಿನಂತಿಗಳನ್ನು ವರ್ಗಾಯಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಯಜಮಾನನಿಗೆ ವಿನಂತಿಗಳನ್ನು ಬರೆಯಲು ಮತ್ತು ಗುಲಾಮರಿಗೆ ವಿನಂತಿಗಳನ್ನು ಓದಲು, ನಾವು ಮಾಣಿಕ್ಯವನ್ನು ಬಳಸಿದ್ದೇವೆ "ಆಕ್ಟೋಪಸ್" ನಾವು ಬರೆಯುವ ಹಕ್ಕುಗಳಿಲ್ಲದೆಯೇ _readonly postfix ನೊಂದಿಗೆ ವಿಶೇಷ ಬಳಕೆದಾರರನ್ನು ರಚಿಸಿದ್ದೇವೆ. ಆದರೆ ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ ಒಂದರ ಸಂರಚನೆಯಲ್ಲಿನ ದೋಷದಿಂದಾಗಿ, ಸೂಕ್ತವಾದ ಹಕ್ಕುಗಳನ್ನು ಹೊಂದಿರುವ ಬಳಕೆದಾರರ ಪರವಾಗಿ ಕೆಲವು ಬರೆಯುವ ವಿನಂತಿಗಳು ಸ್ಲೇವ್ ಸರ್ವರ್‌ಗೆ ಹೋದವು.

ಸಮಸ್ಯೆ ತಕ್ಷಣವೇ ಪ್ರಕಟವಾಗಲಿಲ್ಲ, ಏಕೆಂದರೆ ... ಹೆಚ್ಚಿದ ಹೊರೆಯು ಗುಲಾಮರ ವಿಳಂಬವನ್ನು ಹೆಚ್ಚಿಸಿತು. ರಾತ್ರಿಯ ಆಮದುಗಳ ನಂತರ, ಗುಲಾಮರು ಯಜಮಾನನೊಂದಿಗೆ "ಹಿಡಿಯಲಿಲ್ಲ" ಎಂದು ಬೆಳಿಗ್ಗೆ ಡೇಟಾದ ಅಸಂಗತತೆಯನ್ನು ಕಂಡುಹಿಡಿಯಲಾಯಿತು. ಸೇವೆಯ ಮೇಲಿನ ಹೆಚ್ಚಿನ ಹೊರೆ ಮತ್ತು ಹೊಸ ಮಳಿಗೆಗಳ ಪ್ರಾರಂಭದೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಆಮದುಗಳು ಇದಕ್ಕೆ ಕಾರಣವೆಂದು ನಾವು ಹೇಳುತ್ತೇವೆ. ಆದರೆ ಬಹು-ಗಂಟೆಗಳ ವಿಳಂಬದೊಂದಿಗೆ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವುದು ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ, ಮತ್ತು ನಾವು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಎರಡನೇ ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಗುಲಾಮರಿಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಅದುоದೊಡ್ಡ ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಓದುವ ವಿನಂತಿಗಳೊಂದಿಗೆ ಲೋಡ್ ಆಗಿಲ್ಲ (ಪ್ರತಿಕೃತಿ ವಿಳಂಬದ ಕೊರತೆಯನ್ನು ನಾವು ನಮಗೆ ಹೇಗೆ ವಿವರಿಸಿದ್ದೇವೆ).

ಮುಖ್ಯ ಗುಲಾಮರ "ಹರಡುವಿಕೆ" ಯ ಕಾರಣಗಳನ್ನು ನಾವು ಕಂಡುಕೊಂಡಾಗ, ಅದೇ ಕಾರಣಕ್ಕಾಗಿ ವಿಶ್ಲೇಷಣಾತ್ಮಕವು ಈಗಾಗಲೇ ವಿಫಲವಾಗಿದೆ. ಎರಡು ಹೆಚ್ಚುವರಿ ಸರ್ವರ್‌ಗಳ ಉಪಸ್ಥಿತಿಯ ಹೊರತಾಗಿಯೂ, ಮಾಸ್ಟರ್ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ವರ್ಗಾಯಿಸಲು ನಾವು ಯೋಜಿಸಿದ್ದೇವೆ, ದುರದೃಷ್ಟಕರ ದೋಷದಿಂದಾಗಿ ನಿರ್ಣಾಯಕ ಕ್ಷಣದಲ್ಲಿ ಯಾವುದೂ ಲಭ್ಯವಿಲ್ಲ ಎಂದು ತಿಳಿದುಬಂದಿದೆ.

ಆದರೆ ನಾವು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮಾತ್ರ ಡಂಪ್ ಮಾಡಿಲ್ಲ (ಆ ಸಮಯದಲ್ಲಿ ಪುನಃಸ್ಥಾಪನೆಯು ಸುಮಾರು 5 ಗಂಟೆಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು), ಆದರೆ ಮಾಸ್ಟರ್ ಸರ್ವರ್‌ನ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಕೂಡ, ನಾವು 2 ಗಂಟೆಗಳ ಒಳಗೆ ಪ್ರತಿಕೃತಿಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ. ನಿಜ, ಇದರ ನಂತರ ನಾವು ದೀರ್ಘಕಾಲದವರೆಗೆ ಪುನರಾವರ್ತಿಸುವ ಲಾಗ್ ಅನ್ನು ಎದುರಿಸಿದ್ದೇವೆ (ಏಕೆಂದರೆ ಪ್ರಕ್ರಿಯೆಯು ಏಕ-ಥ್ರೆಡ್ ಮೋಡ್ನಲ್ಲಿ ನಡೆಯುತ್ತದೆ, ಆದರೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಕಥೆಯಾಗಿದೆ).

ತೀರ್ಮಾನ: ಅಂತಹ ಘಟನೆಯ ನಂತರ, ಬಳಕೆದಾರರಿಗೆ ಬರವಣಿಗೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸುವ ಅಭ್ಯಾಸವನ್ನು ತ್ಯಜಿಸುವುದು ಮತ್ತು ಸಂಪೂರ್ಣ ಸರ್ವರ್ ಅನ್ನು ಓದಲು ಮಾತ್ರ ಎಂದು ಘೋಷಿಸುವುದು ಅಗತ್ಯವೆಂದು ಸ್ಪಷ್ಟವಾಯಿತು. ಈ ವಿಧಾನದಿಂದ, ನಿರ್ಣಾಯಕ ಸಮಯದಲ್ಲಿ ಪ್ರತಿಕೃತಿಗಳು ಲಭ್ಯವಿರುತ್ತವೆ ಎಂಬುದರಲ್ಲಿ ಸಂದೇಹವಿಲ್ಲ.

ಒಂದು ಭಾರೀ ಪ್ರಶ್ನೆಯನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡುವುದರಿಂದ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮತ್ತೆ ಜೀವಕ್ಕೆ ತರಬಹುದು

ನಾವು ಸೈಟ್‌ನಲ್ಲಿ ಕ್ಯಾಟಲಾಗ್ ಅನ್ನು ನಿರಂತರವಾಗಿ ನವೀಕರಿಸುತ್ತಿದ್ದರೂ, ಸ್ಲೇವ್ ಸರ್ವರ್‌ಗಳಿಗೆ ನಾವು ಕಳುಹಿಸಿದ ವಿನಂತಿಗಳು ಮಾಸ್ಟರ್‌ನಿಂದ ಸ್ವಲ್ಪ ವಿಳಂಬವನ್ನು ಅನುಮತಿಸಿವೆ. ಗುಲಾಮರ ಸಮಸ್ಯೆಯನ್ನು ನಾವು ಕಂಡುಹಿಡಿದ ಮತ್ತು ತೆಗೆದುಹಾಕುವ ಸಮಯವು "ಇದ್ದಕ್ಕಿದ್ದಂತೆ ದೂರವನ್ನು ಬಿಡುವುದು" "ಮಾನಸಿಕ ತಡೆ" ಗಿಂತ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ (ಈ ಸಮಯದಲ್ಲಿ ಬೆಲೆಗಳನ್ನು ನವೀಕರಿಸಬಹುದಿತ್ತು ಮತ್ತು ಗ್ರಾಹಕರು ಹಳತಾದ ಡೇಟಾವನ್ನು ನೋಡಬಹುದು), ಮತ್ತು ನಾವು ಬಲವಂತವಾಗಿ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಮುಖ್ಯ ಡೇಟಾಬೇಸ್ ಸರ್ವರ್‌ಗೆ ಬದಲಾಯಿಸಿ. ಪರಿಣಾಮವಾಗಿ, ಸೈಟ್ ನಿಧಾನವಾಯಿತು ... ಆದರೆ ಕನಿಷ್ಠ ಅದು ಕೆಲಸ ಮಾಡಿದೆ. ಮತ್ತು ಸ್ಲೇವ್ ಚೇತರಿಸಿಕೊಳ್ಳುತ್ತಿರುವಾಗ, ಆಪ್ಟಿಮೈಸೇಶನ್ ಹೊರತುಪಡಿಸಿ ನಮಗೆ ಬೇರೆ ಆಯ್ಕೆ ಇರಲಿಲ್ಲ. 

ಸ್ಲೇವ್ ಸರ್ವರ್‌ಗಳು ಚೇತರಿಸಿಕೊಳ್ಳುತ್ತಿರುವಾಗ, ನಿಮಿಷಗಳು ನಿಧಾನವಾಗಿ ಕಳೆದವು, ಮಾಸ್ಟರ್ ಓವರ್‌ಲೋಡ್ ಆಗಿದ್ದರು ಮತ್ತು "ಪ್ಯಾರೆಟೊ ನಿಯಮ" ಪ್ರಕಾರ ಸಕ್ರಿಯ ಕಾರ್ಯಗಳನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ನಾವು ನಮ್ಮ ಎಲ್ಲಾ ಪ್ರಯತ್ನಗಳನ್ನು ಎಸೆದಿದ್ದೇವೆ: ಹೆಚ್ಚಿನ ಲೋಡ್ ಅನ್ನು ಉತ್ಪಾದಿಸುವ ಟಾಪ್ ವಿನಂತಿಗಳನ್ನು ನಾವು ಆರಿಸಿದ್ದೇವೆ ಮತ್ತು ಟ್ಯೂನಿಂಗ್ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ . ಇದನ್ನು ಹಾರಾಡುತ್ತ ಸರಿಯಾಗಿ ಮಾಡಲಾಯಿತು.

ಆಸಕ್ತಿದಾಯಕ ಪರಿಣಾಮವೆಂದರೆ ಸಾಮರ್ಥ್ಯಕ್ಕೆ ಲೋಡ್ ಮಾಡಲಾದ MySQL, ಪ್ರಕ್ರಿಯೆಗಳಲ್ಲಿ ಸ್ವಲ್ಪ ಸುಧಾರಣೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಿತು. ಒಟ್ಟು ಲೋಡ್‌ನ 5% ಅನ್ನು ಮಾತ್ರ ಉತ್ಪಾದಿಸುವ ಒಂದೆರಡು ಪ್ರಶ್ನೆಗಳನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡುವುದರಿಂದ ಈಗಾಗಲೇ ಗಮನಾರ್ಹ CPU ಲೋಡ್ ಅನ್ನು ತೋರಿಸಲಾಗಿದೆ. ಪರಿಣಾಮವಾಗಿ, ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಮತ್ತು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು ಅಗತ್ಯವಾದ ಸಮಯವನ್ನು ಪಡೆಯಲು ಮಾಸ್ಟರ್‌ಗೆ ಸಂಪನ್ಮೂಲಗಳ ಸ್ವೀಕಾರಾರ್ಹ ಪೂರೈಕೆಯನ್ನು ಒದಗಿಸಲು ನಮಗೆ ಸಾಧ್ಯವಾಯಿತು. 

ತೀರ್ಮಾನ: ಸಣ್ಣ ಆಪ್ಟಿಮೈಸೇಶನ್ ಸಹ ಹಲವಾರು ಗಂಟೆಗಳ ಕಾಲ ಓವರ್ಲೋಡ್ ಅಡಿಯಲ್ಲಿ "ಬದುಕುಳಿಯಲು" ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಪ್ರತಿಕೃತಿಗಳೊಂದಿಗೆ ಸರ್ವರ್‌ಗಳನ್ನು ಮರುಸ್ಥಾಪಿಸಲು ಇದು ನಮಗೆ ಸಾಕಾಗಿತ್ತು. ಮೂಲಕ, ನಾವು ಕೆಳಗಿನ ಪೋಸ್ಟ್‌ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಪ್ರಶ್ನೆ ಆಪ್ಟಿಮೈಸೇಶನ್‌ನ ತಾಂತ್ರಿಕ ಭಾಗವನ್ನು ಚರ್ಚಿಸುತ್ತೇವೆ. ಆದ್ದರಿಂದ ನಿಮಗೆ ಉಪಯುಕ್ತವಾಗಿದ್ದರೆ ದಯವಿಟ್ಟು ನಮ್ಮ ಬ್ಲಾಗ್‌ಗೆ ಚಂದಾದಾರರಾಗಿ.

ಪಾಲುದಾರ ಸೇವೆಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಆಯೋಜಿಸಿ

ನಾವು ಗ್ರಾಹಕರಿಂದ ಆದೇಶಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತೇವೆ ಮತ್ತು ಆದ್ದರಿಂದ ನಮ್ಮ ಸೇವೆಗಳು ಮೂರನೇ ವ್ಯಕ್ತಿಯ API ಗಳೊಂದಿಗೆ ನಿರಂತರವಾಗಿ ಸಂವಹನ ನಡೆಸುತ್ತವೆ - ಇವುಗಳು SMS, ಪಾವತಿ ವೇದಿಕೆಗಳು, ರೂಟಿಂಗ್ ವ್ಯವಸ್ಥೆಗಳು, ಜಿಯೋಕೋಡರ್, ಫೆಡರಲ್ ತೆರಿಗೆ ಸೇವೆ ಮತ್ತು ಇತರ ಹಲವು ವ್ಯವಸ್ಥೆಗಳನ್ನು ಕಳುಹಿಸಲು ಗೇಟ್ವೇಗಳಾಗಿವೆ. ಮತ್ತು ಲೋಡ್ ವೇಗವಾಗಿ ಬೆಳೆಯಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ನಾವು ನಮ್ಮ ಪಾಲುದಾರ ಸೇವೆಗಳ API ಮಿತಿಗಳಿಗೆ ಓಡಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಅದನ್ನು ನಾವು ಮೊದಲು ಯೋಚಿಸಿರಲಿಲ್ಲ.

ಪಾಲುದಾರ ಸೇವೆಗಳ ಕೋಟಾಗಳನ್ನು ಅನಿರೀಕ್ಷಿತವಾಗಿ ಮೀರಿದರೆ ನಿಮ್ಮ ಸ್ವಂತ ಅಲಭ್ಯತೆಗೆ ಕಾರಣವಾಗಬಹುದು. ಅನೇಕ APIಗಳು ಮಿತಿಗಳನ್ನು ಮೀರಿದ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತವೆ ಮತ್ತು ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ಹಲವಾರು ವಿನಂತಿಗಳು ಪಾಲುದಾರರ ಉತ್ಪಾದನೆಯನ್ನು ಓವರ್‌ಲೋಡ್ ಮಾಡಬಹುದು. 

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

ಹಲವಾರು ಸಾಂಸ್ಥಿಕ ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ ಮತ್ತು ನಾವು ಹೊಸ ಷರತ್ತುಗಳನ್ನು ಒಪ್ಪಿಕೊಂಡಾಗ ಮತ್ತು ಕೆಲವು ಪಾಲುದಾರರಿಂದ ಸೇವೆಗಳ ಆಧುನೀಕರಣಕ್ಕಾಗಿ ಕಾಯುತ್ತಿರುವಾಗ ತಂಡದ ಸುಸಂಘಟಿತ ಕೆಲಸವು ಸಮಯವನ್ನು ಪಡೆಯಲು ಸಹಾಯ ಮಾಡಿತು. ಹೆಚ್ಚಿನ ದಟ್ಟಣೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಹಿಷ್ಣುತೆ ಮತ್ತು ಅತಿರೇಕದ ದರಗಳನ್ನು ಹೆಮ್ಮೆಪಡುವ ಇತರ APIಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, ಆರಂಭದಲ್ಲಿ ನಾವು ಡೆಲಿವರಿ ಪಾಯಿಂಟ್‌ನ ವಿಳಾಸವನ್ನು ನಿರ್ಧರಿಸಲು ಒಂದು ಪ್ರಸಿದ್ಧ ಮ್ಯಾಪಿಂಗ್ API ಅನ್ನು ಬಳಸಿದ್ದೇವೆ. ಆದರೆ ತಿಂಗಳ ಕೊನೆಯಲ್ಲಿ ನಾವು ಸುಮಾರು 2 ಮಿಲಿಯನ್ ರೂಬಲ್ಸ್ಗಳಿಗೆ ಅಚ್ಚುಕಟ್ಟಾದ ಬಿಲ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ. ಇದರ ನಂತರ, ಅವರು ಅದನ್ನು ತ್ವರಿತವಾಗಿ ಬದಲಾಯಿಸಲು ನಿರ್ಧರಿಸಿದರು. ನಾನು ಜಾಹೀರಾತಿನಲ್ಲಿ ತೊಡಗುವುದಿಲ್ಲ, ಆದರೆ ನಮ್ಮ ವೆಚ್ಚಗಳು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ ಎಂದು ನಾನು ಹೇಳುತ್ತೇನೆ.

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

ಕೆಲವೊಮ್ಮೆ ಅದು ತಿರುಗುತ್ತದೆ "ಹೆಚ್ಚು ಚಿನ್ನ ಬೇಕು"(ಸಿ) ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ

ನಾವು ಮುಖ್ಯ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ "ಗಾಗ್ಸ್" ಗೆ ಒಗ್ಗಿಕೊಂಡಿರುತ್ತೇವೆ, ಆದರೆ ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವಾಗ, ಅವರು ನಿರೀಕ್ಷಿಸದಿರುವಲ್ಲಿ ತೊಂದರೆಗಳು ಕಾಣಿಸಿಕೊಳ್ಳಬಹುದು. ಸೈಟ್‌ನಲ್ಲಿ ಪೂರ್ಣ-ಪಠ್ಯ ಹುಡುಕಾಟಕ್ಕಾಗಿ, ನಾವು Apache Solr ಎಂಜಿನ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಲೋಡ್ ಹೆಚ್ಚಾದಂತೆ, ನಾವು ಪ್ರತಿಕ್ರಿಯೆಯ ಸಮಯದಲ್ಲಿ ಇಳಿಕೆಯನ್ನು ಗಮನಿಸಿದ್ದೇವೆ ಮತ್ತು ಸರ್ವರ್ ಪ್ರೊಸೆಸರ್ ಲೋಡ್ ಈಗಾಗಲೇ 100% ತಲುಪಿದೆ. ಯಾವುದು ಸರಳವಾಗಿರಬಹುದು - ಸೋಲ್ರ್‌ನೊಂದಿಗೆ ಕಂಟೇನರ್‌ಗೆ ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನೀಡೋಣ.

ನಿರೀಕ್ಷಿತ ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೆಚ್ಚಳಕ್ಕೆ ಬದಲಾಗಿ, ಸರ್ವರ್ ಸರಳವಾಗಿ "ಮರಣಗೊಂಡಿದೆ". ಇದು ತಕ್ಷಣವೇ 100% ನಲ್ಲಿ ಲೋಡ್ ಆಗುತ್ತದೆ ಮತ್ತು ಇನ್ನಷ್ಟು ನಿಧಾನವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಿತು. ಆರಂಭದಲ್ಲಿ ನಾವು 2 ಕೋರ್ಗಳು ಮತ್ತು 2 GB RAM ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಸಹಾಯ ಮಾಡುವುದನ್ನು ಮಾಡಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ - ನಾವು ಸರ್ವರ್‌ಗೆ 8 ಕೋರ್‌ಗಳು ಮತ್ತು 32 GB ನೀಡಿದ್ದೇವೆ. ಎಲ್ಲವೂ ಹೆಚ್ಚು ಕೆಟ್ಟದಾಗಿದೆ (ಹೇಗೆ ಮತ್ತು ಏಕೆ ಎಂದು ಪ್ರತ್ಯೇಕ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ನಾವು ನಿಮಗೆ ಹೇಳುತ್ತೇವೆ). 

ಕೆಲವು ದಿನಗಳ ಅವಧಿಯಲ್ಲಿ, ನಾವು ಈ ಸಮಸ್ಯೆಯ ಜಟಿಲತೆಗಳನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು 8 ಕೋರ್‌ಗಳು ಮತ್ತು 32 GB ಯೊಂದಿಗೆ ಅತ್ಯುತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸಿದ್ದೇವೆ. ಈ ಸಂರಚನೆಯು ಇಂದು ಲೋಡ್ ಅನ್ನು ಹೆಚ್ಚಿಸಲು ಮುಂದುವರೆಯಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಇದು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಬೆಳವಣಿಗೆಯು ಗ್ರಾಹಕರಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ ಸಂಪರ್ಕಿತ ಮಳಿಗೆಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿಯೂ ಇದೆ - 2 ತಿಂಗಳುಗಳಲ್ಲಿ ಅವರ ಸಂಖ್ಯೆ ದ್ವಿಗುಣಗೊಂಡಿದೆ. 

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

ಸುಲಭವಾದ ಸಮತಲ ಸ್ಕೇಲಿಂಗ್‌ಗೆ ಸ್ಥಿತಿಯಿಲ್ಲದ ಕೀಲಿಯಾಗಿದೆ

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

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

ತೀರ್ಮಾನ: "ನಾವು ಖಂಡಿತವಾಗಿಯೂ ಇಲ್ಲಿ ವಿರೋಧಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ" ಎಂದು ತೋರುತ್ತಿದ್ದರೂ ಸಹ, ಸ್ಥಿತಿಯಿಲ್ಲದ ನಿಯಮವನ್ನು ವಿನಾಯಿತಿ ಇಲ್ಲದೆ ಎಲ್ಲಾ ಘಟಕಗಳಿಗೆ ಗಮನಿಸಬೇಕು. ಕೋಡ್ ಅನ್ನು ತರಾತುರಿಯಲ್ಲಿ ಪುನಃ ಬರೆಯುವುದಕ್ಕಿಂತ ಮತ್ತು ಓವರ್‌ಲೋಡ್ ಮಾಡಿದ ಸೇವೆಯನ್ನು ಸರಿಪಡಿಸುವುದಕ್ಕಿಂತ ಎಲ್ಲಾ ಸಿಸ್ಟಮ್‌ಗಳ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಸರಿಯಾಗಿ ಸಂಘಟಿಸಲು ಸ್ವಲ್ಪ ಸಮಯವನ್ನು ಕಳೆಯುವುದು ಉತ್ತಮ.

ತೀವ್ರ ಬೆಳವಣಿಗೆಗೆ 7 ತತ್ವಗಳು

ಹೆಚ್ಚುವರಿ ಸಾಮರ್ಥ್ಯದ ಲಭ್ಯತೆಯ ಹೊರತಾಗಿಯೂ, ಬೆಳವಣಿಗೆಯ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನಾವು ಹಲವಾರು ತಪ್ಪುಗಳ ಮೇಲೆ ಹೆಜ್ಜೆ ಹಾಕಿದ್ದೇವೆ. ಈ ಸಮಯದಲ್ಲಿ, ಆದೇಶಗಳ ಸಂಖ್ಯೆಯು 4 ಪಟ್ಟು ಹೆಚ್ಚು ಹೆಚ್ಚಾಗಿದೆ. ಈಗ ನಾವು ಈಗಾಗಲೇ 17 ನಗರಗಳಲ್ಲಿ ದಿನಕ್ಕೆ 000 ಕ್ಕೂ ಹೆಚ್ಚು ಆದೇಶಗಳನ್ನು ತಲುಪಿಸುತ್ತೇವೆ ಮತ್ತು ಭೌಗೋಳಿಕತೆಯನ್ನು ಇನ್ನಷ್ಟು ವಿಸ್ತರಿಸಲು ಯೋಜಿಸಿದ್ದೇವೆ - 62 ರ ಮೊದಲಾರ್ಧದಲ್ಲಿ ರಷ್ಯಾದಾದ್ಯಂತ ಸೇವೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವ ನಿರೀಕ್ಷೆಯಿದೆ. ಬೆಳೆಯುತ್ತಿರುವ ಕೆಲಸದ ಹೊರೆಯನ್ನು ನಿಭಾಯಿಸಲು, ನಮ್ಮ ಈಗಾಗಲೇ ಸಂಪೂರ್ಣ ಶಂಕುಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು, ನಿರಂತರ ಬೆಳವಣಿಗೆಯ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ನಾವು 2020 ಮೂಲ ತತ್ವಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ:

1. ಘಟನೆ ನಿರ್ವಹಣೆ. ನಾವು ಜಿರಾದಲ್ಲಿ ಬೋರ್ಡ್ ಅನ್ನು ರಚಿಸಿದ್ದೇವೆ, ಅಲ್ಲಿ ಪ್ರತಿ ಘಟನೆಯು ಟಿಕೆಟ್ ರೂಪದಲ್ಲಿ ಪ್ರತಿಫಲಿಸುತ್ತದೆ. ಘಟನೆ-ಸಂಬಂಧಿತ ಕಾರ್ಯಗಳನ್ನು ವಾಸ್ತವವಾಗಿ ಆದ್ಯತೆ ನೀಡಲು ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಇದು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಎಲ್ಲಾ ನಂತರ, ಮೂಲಭೂತವಾಗಿ, ತಪ್ಪುಗಳನ್ನು ಮಾಡಲು ಇದು ಹೆದರಿಕೆಯೆ ಅಲ್ಲ, ಆದರೆ ಅದೇ ಸಂದರ್ಭದಲ್ಲಿ ಎರಡು ಬಾರಿ ತಪ್ಪುಗಳನ್ನು ಮಾಡಲು ಹೆದರಿಕೆಯೆ. ಕಾರಣವನ್ನು ಸರಿಪಡಿಸುವ ಮೊದಲು ಘಟನೆಗಳು ಮರುಕಳಿಸುವ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಕ್ರಿಯೆಯ ಸೂಚನೆಗಳು ಸಿದ್ಧವಾಗಿರಬೇಕು, ಏಕೆಂದರೆ ಭಾರೀ ಹೊರೆಯ ಸಮಯದಲ್ಲಿ ಮಿಂಚಿನ ವೇಗದಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ.
2. ಮಾನಿಟರಿಂಗ್ ವಿನಾಯಿತಿ ಇಲ್ಲದೆ ಎಲ್ಲಾ ಮೂಲಸೌಕರ್ಯ ಅಂಶಗಳಿಗೆ ಅಗತ್ಯವಿದೆ. ನಾವು ಹೊರೆಯ ಬೆಳವಣಿಗೆಯನ್ನು ಊಹಿಸಲು ಮತ್ತು ನಿರ್ಮೂಲನೆಗೆ ಆದ್ಯತೆ ನೀಡಲು "ಅಡಚಣೆಗಳನ್ನು" ಸರಿಯಾಗಿ ಆಯ್ಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು ಎಂದು ಅವರಿಗೆ ಧನ್ಯವಾದಗಳು. ಹೆಚ್ಚಾಗಿ, ಹೆಚ್ಚಿನ ಹೊರೆಯ ಅಡಿಯಲ್ಲಿ, ನೀವು ಎಂದಿಗೂ ಯೋಚಿಸದ ಎಲ್ಲವೂ ಒಡೆಯುತ್ತದೆ ಅಥವಾ ನಿಧಾನವಾಗಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ಅವುಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಮತ್ತು ನಿರೀಕ್ಷಿಸಲು ಮೊದಲ ಘಟನೆಗಳು ಸಂಭವಿಸಿದ ತಕ್ಷಣ ಹೊಸ ಎಚ್ಚರಿಕೆಗಳನ್ನು ರಚಿಸುವುದು ಉತ್ತಮವಾಗಿದೆ.
3. ಸರಿಯಾದ ಎಚ್ಚರಿಕೆಗಳು ಲೋಡ್ ತೀವ್ರವಾಗಿ ಹೆಚ್ಚಾದಾಗ ಸರಳವಾಗಿ ಅಗತ್ಯ. ಮೊದಲಿಗೆ, ಅವರು ನಿಖರವಾಗಿ ಮುರಿದುಹೋಗಿರುವುದನ್ನು ವರದಿ ಮಾಡಬೇಕು. ಎರಡನೆಯದಾಗಿ, ಹೆಚ್ಚಿನ ಎಚ್ಚರಿಕೆಗಳು ಇರಬಾರದು, ಏಕೆಂದರೆ ನಿರ್ಣಾಯಕವಲ್ಲದ ಎಚ್ಚರಿಕೆಗಳ ಸಮೃದ್ಧತೆಯು ಎಲ್ಲಾ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಲಕ್ಷಿಸಲು ಕಾರಣವಾಗುತ್ತದೆ.
4. ಅರ್ಜಿಗಳು ಸ್ಥಿತಿರಹಿತವಾಗಿರಬೇಕು. ಈ ನಿಯಮಕ್ಕೆ ಯಾವುದೇ ವಿನಾಯಿತಿಗಳು ಇರಬಾರದು ಎಂದು ನಮಗೆ ಮನವರಿಕೆಯಾಗಿದೆ. ರನ್ಟೈಮ್ ಪರಿಸರದಿಂದ ನಮಗೆ ಸಂಪೂರ್ಣ ಸ್ವಾತಂತ್ರ್ಯ ಬೇಕು. ಇದನ್ನು ಮಾಡಲು, ನೀವು ಹಂಚಿದ ಡೇಟಾವನ್ನು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಬಹುದು ಅಥವಾ, ಉದಾಹರಣೆಗೆ, ನೇರವಾಗಿ S3 ನಲ್ಲಿ. ಇನ್ನೂ ಉತ್ತಮ, ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸಿ. https://12factor.net. ಸಮಯದ ತೀಕ್ಷ್ಣವಾದ ಹೆಚ್ಚಳದ ಸಮಯದಲ್ಲಿ, ಕೋಡ್ ಅನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ, ಮತ್ತು ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಸಮತಲ ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ನೇರವಾಗಿ ಹೆಚ್ಚಿಸುವ ಮೂಲಕ ನೀವು ಲೋಡ್ ಅನ್ನು ನಿಭಾಯಿಸಬೇಕಾಗುತ್ತದೆ.
5. ಕೋಟಾಗಳು ಮತ್ತು ಬಾಹ್ಯ ಸೇವೆಗಳ ಕಾರ್ಯಕ್ಷಮತೆ. ತ್ವರಿತ ಬೆಳವಣಿಗೆಯೊಂದಿಗೆ, ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ ಬಾಹ್ಯ ಸೇವೆಯಲ್ಲಿಯೂ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸಬಹುದು. ಇದು ವೈಫಲ್ಯದ ಕಾರಣದಿಂದಲ್ಲ, ಆದರೆ ಕೋಟಾಗಳು ಅಥವಾ ಮಿತಿಗಳನ್ನು ತಲುಪುವುದರಿಂದ ಇದು ಸಂಭವಿಸಿದಾಗ ಅತ್ಯಂತ ಕಿರಿಕಿರಿಯುಂಟುಮಾಡುವ ವಿಷಯ. ಆದ್ದರಿಂದ ಬಾಹ್ಯ ಸೇವೆಗಳು ನಿಮ್ಮಂತೆಯೇ ಅಳೆಯಬೇಕು. 
6. ಪ್ರತ್ಯೇಕ ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಸಾಲುಗಳು. ಗೇಟ್‌ವೇಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಅಡಚಣೆ ಉಂಟಾದಾಗ ಇದು ಬಹಳಷ್ಟು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಪೂರ್ಣ SMS ಕಳುಹಿಸುವ ಸರತಿ ಸಾಲುಗಳು ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಗಳ ನಡುವಿನ ಅಧಿಸೂಚನೆಗಳ ವಿನಿಮಯದಲ್ಲಿ ಮಧ್ಯಪ್ರವೇಶಿಸದಿದ್ದರೆ ನಾವು ಡೇಟಾ ವರ್ಗಾವಣೆಯಲ್ಲಿ ವಿಳಂಬವನ್ನು ಎದುರಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಅವರು ಪ್ರತ್ಯೇಕವಾಗಿ ಕೆಲಸ ಮಾಡಿದರೆ ಕಾರ್ಮಿಕರ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಸುಲಭವಾಗುತ್ತದೆ.
7. ಹಣಕಾಸಿನ ವಾಸ್ತವತೆಗಳು. ಡೇಟಾ ಹರಿವುಗಳಲ್ಲಿ ಸ್ಫೋಟಕ ಬೆಳವಣಿಗೆಯಾದಾಗ, ಸುಂಕಗಳು ಮತ್ತು ಚಂದಾದಾರಿಕೆಗಳ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಸಮಯವಿಲ್ಲ. ಆದರೆ ನೀವು ಅವುಗಳನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬೇಕು, ವಿಶೇಷವಾಗಿ ನೀವು ಸಣ್ಣ ಕಂಪನಿಯಾಗಿದ್ದರೆ. ಯಾವುದೇ API ಯ ಮಾಲೀಕರು, ಹಾಗೆಯೇ ನಿಮ್ಮ ಹೋಸ್ಟಿಂಗ್ ಪೂರೈಕೆದಾರರು ದೊಡ್ಡ ಬಿಲ್‌ಗೆ ಒಳಗಾಗಬಹುದು. ಆದ್ದರಿಂದ ನೀವು ಒಪ್ಪಂದಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಓದಬೇಕು.

ತೀರ್ಮಾನಕ್ಕೆ

ನಷ್ಟವಿಲ್ಲದೆ, ಆದರೆ ನಾವು ಈ ಹಂತವನ್ನು ಉಳಿದುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಇಂದು ನಾವು ಕಂಡುಕೊಂಡ ಎಲ್ಲಾ ತತ್ವಗಳಿಗೆ ಬದ್ಧರಾಗಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ ಮತ್ತು ಕೆಲವು ಅನಿರೀಕ್ಷಿತ ಘಟನೆಗಳನ್ನು ನಿಭಾಯಿಸಲು ಪ್ರತಿ ಯಂತ್ರವು x4 ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಲಭವಾಗಿ ಹೆಚ್ಚಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ. 

ಕೆಳಗಿನ ಪೋಸ್ಟ್‌ಗಳಲ್ಲಿ, Apache Solr ನಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅವನತಿಯನ್ನು ತನಿಖೆ ಮಾಡುವಲ್ಲಿ ನಾವು ನಮ್ಮ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಪ್ರಶ್ನೆ ಆಪ್ಟಿಮೈಸೇಶನ್ ಮತ್ತು ಫೆಡರಲ್ ತೆರಿಗೆ ಸೇವೆಯೊಂದಿಗಿನ ಸಂವಹನವು ಕಂಪನಿಯು ಹಣವನ್ನು ಉಳಿಸಲು ಹೇಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡುತ್ತೇವೆ. ನಮ್ಮ ಬ್ಲಾಗ್‌ಗೆ ಚಂದಾದಾರರಾಗಿ ಇದರಿಂದ ನೀವು ಏನನ್ನೂ ಕಳೆದುಕೊಳ್ಳಬೇಡಿ ಮತ್ತು ಟ್ರಾಫಿಕ್ ಬೆಳವಣಿಗೆಯ ಸಮಯದಲ್ಲಿ ನೀವು ಇದೇ ರೀತಿಯ ತೊಂದರೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ನಮಗೆ ತಿಳಿಸಿ.

ನೋಂದಾಯಿತ ಬಳಕೆದಾರರು ಮಾತ್ರ ಸಮೀಕ್ಷೆಯಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು. ಸೈನ್ ಇನ್ ಮಾಡಿ, ದಯವಿಟ್ಟು.

ಈ ಕಾರಣದಿಂದಾಗಿ ಲೋಡ್‌ನಲ್ಲಿ ತೀಕ್ಷ್ಣವಾದ ಹೆಚ್ಚಳದಿಂದಾಗಿ ನೀವು ಎಂದಾದರೂ ಸೇವೆಯಲ್ಲಿ ನಿಧಾನಗತಿ/ಕುಸಿತವನ್ನು ಅನುಭವಿಸಿದ್ದೀರಾ:

• 55,6%ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಸೇರಿಸಲು ಅಸಮರ್ಥತೆ10

• 16,7%ಹೋಸ್ಟಿಂಗ್ ಪೂರೈಕೆದಾರರ ಮೂಲಸೌಕರ್ಯ ಮಿತಿಗಳು3

• 33,3%ಮೂರನೇ ವ್ಯಕ್ತಿಯ APIಗಳ ಮಿತಿಗಳು6

• 27,8%ಅವರ ಅನ್ವಯಗಳ ಸ್ಥಿತಿಯಿಲ್ಲದ ತತ್ವಗಳ ಉಲ್ಲಂಘನೆ 5

• 88,9%ಸ್ವಂತ ಸೇವೆಗಳ ಸೂಕ್ತವಲ್ಲದ ಕೋಡ್16

18 ಬಳಕೆದಾರರು ಮತ ಹಾಕಿದ್ದಾರೆ. 6 ಬಳಕೆದಾರರು ದೂರ ಉಳಿದಿದ್ದಾರೆ.

ಮೂಲ: www.habr.com