SRE: ಕಾರ್ಯಕ್ಷಮತೆಯ ವಿಶ್ಲೇಷಣೆ. Go ನಲ್ಲಿ ಸರಳ ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕಾನ್ಫಿಗರೇಶನ್ ವಿಧಾನ

ಕಾರ್ಯಕ್ಷಮತೆಯ ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ಶ್ರುತಿಯು ಗ್ರಾಹಕರಿಗೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅನುಸರಣೆಯನ್ನು ಪರಿಶೀಲಿಸಲು ಪ್ರಬಲ ಸಾಧನವಾಗಿದೆ.

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

ಗೋ ಇಲ್ಲಿ ವಿಶೇಷವಾಗಿ ಉತ್ತಮವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಪ್ರೊಫೈಲಿಂಗ್ ಪರಿಕರಗಳನ್ನು ಹೊಂದಿದೆ pprof ಪ್ರಮಾಣಿತ ಗ್ರಂಥಾಲಯದಲ್ಲಿ.

ತಂತ್ರ

ನಮ್ಮ ರಚನಾತ್ಮಕ ವಿಶ್ಲೇಷಣೆಗಾಗಿ ಸಾರಾಂಶ ಪಟ್ಟಿಯನ್ನು ರಚಿಸೋಣ. ಅಂತಃಪ್ರಜ್ಞೆ ಅಥವಾ ಊಹೆಯ ಆಧಾರದ ಮೇಲೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವ ಬದಲು ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ನಾವು ಕೆಲವು ಡೇಟಾವನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಇದನ್ನು ಮಾಡಲು ನಾವು ಇದನ್ನು ಮಾಡುತ್ತೇವೆ:

• ನಾವು ಆಪ್ಟಿಮೈಸೇಶನ್ ಗಡಿಗಳನ್ನು ನಿರ್ಧರಿಸುತ್ತೇವೆ (ಅವಶ್ಯಕತೆಗಳು);
• ನಾವು ವ್ಯವಸ್ಥೆಗೆ ವಹಿವಾಟು ಲೋಡ್ ಅನ್ನು ಲೆಕ್ಕ ಹಾಕುತ್ತೇವೆ;
• ನಾವು ಪರೀಕ್ಷೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತೇವೆ (ಡೇಟಾವನ್ನು ರಚಿಸಿ);
• ನಾವು ಗಮನಿಸುತ್ತೇವೆ;
• ನಾವು ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ - ಎಲ್ಲಾ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸಲಾಗಿದೆಯೇ?
• ನಾವು ಅದನ್ನು ವೈಜ್ಞಾನಿಕವಾಗಿ ಸ್ಥಾಪಿಸುತ್ತೇವೆ, ಒಂದು ಊಹೆಯನ್ನು ಮಾಡಿ;
• ಈ ಊಹೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ನಾವು ಪ್ರಯೋಗವನ್ನು ನಡೆಸುತ್ತೇವೆ.

ಸರಳ HTTP ಸರ್ವರ್ ಆರ್ಕಿಟೆಕ್ಚರ್

ಈ ಲೇಖನಕ್ಕಾಗಿ ನಾವು ಗೋಲಾಂಗ್‌ನಲ್ಲಿ ಸಣ್ಣ HTTP ಸರ್ವರ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಈ ಲೇಖನದಿಂದ ಎಲ್ಲಾ ಕೋಡ್ ಅನ್ನು ಕಾಣಬಹುದು ಇಲ್ಲಿ.

ವಿಶ್ಲೇಷಿಸಲ್ಪಡುತ್ತಿರುವ ಅಪ್ಲಿಕೇಶನ್ ಒಂದು HTTP ಸರ್ವರ್ ಆಗಿದ್ದು ಅದು ಪ್ರತಿ ವಿನಂತಿಗೆ Postgresql ಅನ್ನು ಪೋಲ್ ಮಾಡುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಸಿಸ್ಟಮ್ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಪ್ರದರ್ಶಿಸಲು Prometheus, node_exporter ಮತ್ತು Grafana ಇವೆ.

ಸರಳೀಕರಿಸಲು, ಸಮತಲ ಸ್ಕೇಲಿಂಗ್ (ಮತ್ತು ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ಸರಳೀಕರಿಸುವುದು) ಪ್ರತಿ ಸೇವೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಒಟ್ಟಿಗೆ ನಿಯೋಜಿಸಲಾಗಿದೆ ಎಂದು ನಾವು ಪರಿಗಣಿಸುತ್ತೇವೆ:

ಗುರಿಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವುದು

ಈ ಹಂತದಲ್ಲಿ, ನಾವು ಗುರಿಯನ್ನು ನಿರ್ಧರಿಸುತ್ತೇವೆ. ನಾವು ಏನನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ? ಕೊನೆಗೊಳ್ಳುವ ಸಮಯ ಬಂದಾಗ ನಮಗೆ ಹೇಗೆ ಗೊತ್ತು? ಈ ಲೇಖನದಲ್ಲಿ, ನಾವು ಗ್ರಾಹಕರನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ನಮ್ಮ ಸೇವೆಯು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 10 ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಎಂದು ನಾವು ಊಹಿಸುತ್ತೇವೆ.

В Google SRE ಪುಸ್ತಕ ಆಯ್ಕೆ ಮತ್ತು ಮಾಡೆಲಿಂಗ್ ವಿಧಾನಗಳನ್ನು ವಿವರವಾಗಿ ಚರ್ಚಿಸಲಾಗಿದೆ. ನಾವು ಅದೇ ರೀತಿ ಮಾಡೋಣ ಮತ್ತು ಮಾದರಿಗಳನ್ನು ನಿರ್ಮಿಸೋಣ:

• ಸುಪ್ತತೆ: 99% ವಿನಂತಿಗಳನ್ನು 60ms ಗಿಂತ ಕಡಿಮೆ ಅವಧಿಯಲ್ಲಿ ಪೂರ್ಣಗೊಳಿಸಬೇಕು;
• ವೆಚ್ಚ: ಸೇವೆಯು ಸಮಂಜಸವಾಗಿ ಸಾಧ್ಯ ಎಂದು ನಾವು ಭಾವಿಸುವ ಕನಿಷ್ಠ ಹಣವನ್ನು ಸೇವಿಸಬೇಕು. ಇದನ್ನು ಮಾಡಲು, ನಾವು ಥ್ರೋಪುಟ್ ಅನ್ನು ಗರಿಷ್ಠಗೊಳಿಸುತ್ತೇವೆ;
• ಸಾಮರ್ಥ್ಯದ ಯೋಜನೆ: ಒಟ್ಟಾರೆ ಸ್ಕೇಲಿಂಗ್ ಕಾರ್ಯವನ್ನು ಒಳಗೊಂಡಂತೆ ಅಪ್ಲಿಕೇಶನ್‌ನ ಎಷ್ಟು ನಿದರ್ಶನಗಳನ್ನು ರನ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಆರಂಭಿಕ ಲೋಡ್ ಮತ್ತು ಒದಗಿಸುವ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸಲು ಎಷ್ಟು ನಿದರ್ಶನಗಳು ಅಗತ್ಯವಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮತ್ತು ದಾಖಲಿಸುವುದು ಅಗತ್ಯವಿದೆ. ಪುನರುಕ್ತಿ n+1.

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

ಪರೀಕ್ಷಾ ವಾತಾವರಣವನ್ನು ಹೊಂದಿಸಲಾಗುತ್ತಿದೆ

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

ವಹಿವಾಟು ಹೊರೆ

ಈ ಪರಿಸರವು ಬಳಸುತ್ತದೆ ತರಕಾರಿ ನಿಲ್ಲಿಸುವವರೆಗೆ ಕಸ್ಟಮ್ HTTP ವಿನಂತಿ ದರವನ್ನು ರಚಿಸಲು:

$ make load-test LOAD_TEST_RATE=50
echo "POST http://localhost:8080" | vegeta attack -body tests/fixtures/age_no_match.json -rate=50 -duration=0 | tee results.bin | vegeta report

ವೀಕ್ಷಣೆ

ರನ್ಟೈಮ್ನಲ್ಲಿ ವಹಿವಾಟಿನ ಲೋಡ್ ಅನ್ನು ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ (ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ, ಪ್ರತಿಕ್ರಿಯೆ ಸುಪ್ತತೆ) ಮತ್ತು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ (ಮೆಮೊರಿ, CPU, IOPS) ಮೆಟ್ರಿಕ್‌ಗಳ ಜೊತೆಗೆ, ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೊಫೈಲಿಂಗ್ ಎಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು CPU ಸಮಯವನ್ನು ಹೇಗೆ ಸೇವಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ರನ್ ಮಾಡಲಾಗುತ್ತದೆ.

ಪ್ರೊಫೈಲಿಂಗ್

ಪ್ರೊಫೈಲಿಂಗ್ ಎನ್ನುವುದು ಒಂದು ರೀತಿಯ ಅಳತೆಯಾಗಿದ್ದು ಅದು ಅಪ್ಲಿಕೇಶನ್ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ CPU ಸಮಯ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ನೋಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಪ್ರೊಸೆಸರ್ ಸಮಯವನ್ನು ಎಲ್ಲಿ ಮತ್ತು ಎಷ್ಟು ಖರ್ಚು ಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ನಿರ್ಧರಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ:

ಈ ಡೇಟಾವನ್ನು ವಿಶ್ಲೇಷಣೆಯ ಸಮಯದಲ್ಲಿ ವ್ಯರ್ಥ CPU ಸಮಯ ಮತ್ತು ಅನಗತ್ಯ ಕೆಲಸಗಳ ಒಳನೋಟವನ್ನು ಪಡೆಯಲು ಬಳಸಬಹುದು. Go (pprof) ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ರಚಿಸಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ಪ್ರಮಾಣಿತ ಪರಿಕರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಜ್ವಾಲೆಯ ಗ್ರಾಫ್‌ಗಳಾಗಿ ದೃಶ್ಯೀಕರಿಸಬಹುದು. ನಾನು ಅವರ ಬಳಕೆ ಮತ್ತು ಸೆಟಪ್ ಮಾರ್ಗದರ್ಶಿ ಕುರಿತು ನಂತರ ಲೇಖನದಲ್ಲಿ ಮಾತನಾಡುತ್ತೇನೆ.

ಮರಣದಂಡನೆ, ವೀಕ್ಷಣೆ, ವಿಶ್ಲೇಷಣೆ.

ಪ್ರಯೋಗ ನಡೆಸೋಣ. ನಾವು ಕಾರ್ಯಕ್ಷಮತೆಯಿಂದ ತೃಪ್ತರಾಗುವವರೆಗೆ ನಾವು ನಿರ್ವಹಿಸುತ್ತೇವೆ, ಗಮನಿಸುತ್ತೇವೆ ಮತ್ತು ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ. ಮೊದಲ ಅವಲೋಕನಗಳ ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆಯಲು ಅದನ್ನು ಅನ್ವಯಿಸಲು ನಿರಂಕುಶವಾಗಿ ಕಡಿಮೆ ಲೋಡ್ ಮೌಲ್ಯವನ್ನು ಆರಿಸಿಕೊಳ್ಳೋಣ. ಪ್ರತಿ ನಂತರದ ಹಂತದಲ್ಲಿ ನಾವು ಒಂದು ನಿರ್ದಿಷ್ಟ ಸ್ಕೇಲಿಂಗ್ ಅಂಶದೊಂದಿಗೆ ಲೋಡ್ ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತೇವೆ, ಕೆಲವು ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ. ಪ್ರತಿ ಲೋಡ್ ಪರೀಕ್ಷೆಯ ರನ್ ಅನ್ನು ಸರಿಹೊಂದಿಸಲಾದ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ನಡೆಸಲಾಗುತ್ತದೆ: make load-test LOAD_TEST_RATE=X.

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 50 ವಿನಂತಿಗಳು

ಮೇಲಿನ ಎರಡು ಗ್ರಾಫ್‌ಗಳಿಗೆ ಗಮನ ಕೊಡಿ. ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 50 ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಎಂದು ಮೇಲಿನ ಎಡಭಾಗವು ತೋರಿಸುತ್ತದೆ (ಇದು ಯೋಚಿಸುತ್ತದೆ) ಮತ್ತು ಮೇಲಿನ ಬಲವು ಪ್ರತಿ ವಿನಂತಿಯ ಅವಧಿಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಎರಡೂ ನಿಯತಾಂಕಗಳು ನಾವು ನಮ್ಮ ಕಾರ್ಯಕ್ಷಮತೆಯ ಗಡಿಯೊಳಗೆ ಇದ್ದೇವೋ ಅಥವಾ ಇಲ್ಲವೋ ಎಂಬುದನ್ನು ನೋಡಲು ಮತ್ತು ವಿಶ್ಲೇಷಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಗ್ರಾಫ್ನಲ್ಲಿ ಕೆಂಪು ರೇಖೆ HTTP ವಿನಂತಿ ಲೇಟೆನ್ಸಿ SLO ಅನ್ನು 60ms ನಲ್ಲಿ ತೋರಿಸುತ್ತದೆ. ನಾವು ನಮ್ಮ ಗರಿಷ್ಟ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯಕ್ಕಿಂತ ಕೆಳಗಿದ್ದೇವೆ ಎಂದು ಸಾಲು ತೋರಿಸುತ್ತದೆ.

ವೆಚ್ಚದ ಭಾಗವನ್ನು ನೋಡೋಣ:

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 10000 ವಿನಂತಿಗಳು / ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ 50 ವಿನಂತಿಗಳು = 200 ಸರ್ವರ್‌ಗಳು + 1

ನಾವು ಇನ್ನೂ ಈ ಅಂಕಿಅಂಶವನ್ನು ಸುಧಾರಿಸಬಹುದು.

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 500 ವಿನಂತಿಗಳು

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 500 ವಿನಂತಿಗಳನ್ನು ಲೋಡ್ ಮಾಡಿದಾಗ ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕ ಸಂಗತಿಗಳು ಸಂಭವಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ:

ಮತ್ತೊಮ್ಮೆ, ಮೇಲಿನ ಎಡ ಗ್ರಾಫ್ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಸಾಮಾನ್ಯ ಲೋಡ್ ಅನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡುತ್ತಿದೆ ಎಂದು ನೀವು ನೋಡಬಹುದು. ಇದು ಹಾಗಲ್ಲದಿದ್ದರೆ, ಅಪ್ಲಿಕೇಶನ್ ಚಾಲನೆಯಲ್ಲಿರುವ ಸರ್ವರ್‌ನಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ. ಪ್ರತಿಕ್ರಿಯೆ ಲೇಟೆನ್ಸಿ ಗ್ರಾಫ್ ಮೇಲಿನ ಬಲಭಾಗದಲ್ಲಿದೆ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 500 ವಿನಂತಿಗಳು 25-40ms ಪ್ರತಿಕ್ರಿಯೆ ವಿಳಂಬಕ್ಕೆ ಕಾರಣವಾಗಿವೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. 99 ನೇ ಶೇಕಡಾವಾರು ಇನ್ನೂ ಮೇಲೆ ಆಯ್ಕೆ ಮಾಡಿದ 60ms SLO ಗೆ ಚೆನ್ನಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ.

ವೆಚ್ಚದ ವಿಷಯದಲ್ಲಿ:

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 10000 ವಿನಂತಿಗಳು / ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ 500 ವಿನಂತಿಗಳು = 20 ಸರ್ವರ್‌ಗಳು + 1

ಎಲ್ಲವನ್ನೂ ಇನ್ನೂ ಸುಧಾರಿಸಬಹುದು.

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 1000 ವಿನಂತಿಗಳು

ಉತ್ತಮ ಉಡಾವಣೆ! ಅಪ್ಲಿಕೇಶನ್ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 1000 ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಆದರೆ ಲೇಟೆನ್ಸಿ ಮಿತಿಯನ್ನು SLO ಉಲ್ಲಂಘಿಸಿದೆ. ಇದನ್ನು ಮೇಲಿನ ಬಲ ಗ್ರಾಫ್‌ನಲ್ಲಿ p99 ಸಾಲಿನಲ್ಲಿ ಕಾಣಬಹುದು. p100 ಲೈನ್ ಹೆಚ್ಚು ಹೆಚ್ಚಿದ್ದರೂ, ನಿಜವಾದ ವಿಳಂಬಗಳು ಗರಿಷ್ಠ 60ms ಗಿಂತ ಹೆಚ್ಚಿವೆ. ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ಪ್ರೊಫೈಲಿಂಗ್‌ಗೆ ಧುಮುಕೋಣ.

ಪ್ರೊಫೈಲಿಂಗ್

ಪ್ರೊಫೈಲಿಂಗ್ಗಾಗಿ, ನಾವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 1000 ವಿನಂತಿಗಳಿಗೆ ಲೋಡ್ ಅನ್ನು ಹೊಂದಿಸುತ್ತೇವೆ, ನಂತರ ಬಳಸಿ pprof ಅಪ್ಲಿಕೇಶನ್ CPU ಸಮಯವನ್ನು ಎಲ್ಲಿ ಕಳೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ಡೇಟಾವನ್ನು ಸೆರೆಹಿಡಿಯಲು. HTTP ಎಂಡ್ ಪಾಯಿಂಟ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ಮೂಲಕ ಇದನ್ನು ಮಾಡಬಹುದು pprof, ತದನಂತರ, ಲೋಡ್ ಅಡಿಯಲ್ಲಿ, ಕರ್ಲ್ ಬಳಸಿ ಫಲಿತಾಂಶಗಳನ್ನು ಉಳಿಸಿ:

$ curl http://localhost:8080/debug/pprof/profile?seconds=29 > cpu.1000_reqs_sec_no_optimizations.prof

ಫಲಿತಾಂಶಗಳನ್ನು ಈ ರೀತಿ ಪ್ರದರ್ಶಿಸಬಹುದು:

$ go tool pprof -http=:12345 cpu.1000_reqs_sec_no_optimizations.prof

ಅಪ್ಲಿಕೇಶನ್ ಎಲ್ಲಿ ಮತ್ತು ಎಷ್ಟು CPU ಸಮಯವನ್ನು ಕಳೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ಗ್ರಾಫ್ ತೋರಿಸುತ್ತದೆ. ನಿಂದ ವಿವರಣೆಯಿಂದ ಬ್ರೆಂಡನ್ ಗ್ರೆಗ್:

X ಅಕ್ಷವು ಸ್ಟಾಕ್ ಪ್ರೊಫೈಲ್ ಜನಸಂಖ್ಯೆಯಾಗಿದ್ದು, ವರ್ಣಮಾಲೆಯಂತೆ ವಿಂಗಡಿಸಲಾಗಿದೆ (ಇದು ಸಮಯವಲ್ಲ), Y ಅಕ್ಷವು ಸ್ಟಾಕ್‌ನ ಆಳವನ್ನು ತೋರಿಸುತ್ತದೆ, ಸೊನ್ನೆಯಿಂದ [ಮೇಲ್ಭಾಗದಲ್ಲಿ] ಎಣಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಆಯತವು ಸ್ಟಾಕ್ ಫ್ರೇಮ್ ಆಗಿದೆ. ಅಗಲವಾದ ಚೌಕಟ್ಟು, ಹೆಚ್ಚಾಗಿ ಇದು ರಾಶಿಗಳಲ್ಲಿ ಇರುತ್ತದೆ. ಮೇಲ್ಭಾಗದಲ್ಲಿ ಯಾವುದು CPU ನಲ್ಲಿ ರನ್ ಆಗುತ್ತದೆ ಮತ್ತು ಕೆಳಗಿನವುಗಳು ಮಕ್ಕಳ ಅಂಶಗಳಾಗಿವೆ. ಬಣ್ಣಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಏನನ್ನೂ ಅರ್ಥೈಸುವುದಿಲ್ಲ, ಆದರೆ ಚೌಕಟ್ಟುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ.

ವಿಶ್ಲೇಷಣೆ - ಊಹೆ

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

ಬ್ರೆಂಡನ್ ಗ್ರೆಗ್ ಅವರ ಶಿಫಾರಸುಗಳನ್ನು ಅನುಸರಿಸಿ, ನಾವು ಮೇಲಿನಿಂದ ಕೆಳಕ್ಕೆ ಚಾರ್ಟ್ ಅನ್ನು ಓದುತ್ತೇವೆ. ಪ್ರತಿಯೊಂದು ಸಾಲು ಸ್ಟಾಕ್ ಫ್ರೇಮ್ (ಫಂಕ್ಷನ್ ಕರೆ) ಅನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ. ಮೊದಲ ಸಾಲು ಪ್ರೋಗ್ರಾಂಗೆ ಪ್ರವೇಶ ಬಿಂದುವಾಗಿದೆ, ಎಲ್ಲಾ ಇತರ ಕರೆಗಳ ಪೋಷಕ (ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಎಲ್ಲಾ ಇತರ ಕರೆಗಳು ಅದನ್ನು ತಮ್ಮ ಸ್ಟಾಕ್ನಲ್ಲಿ ಹೊಂದಿರುತ್ತವೆ). ಮುಂದಿನ ಸಾಲು ಈಗಾಗಲೇ ವಿಭಿನ್ನವಾಗಿದೆ:

ಗ್ರಾಫ್‌ನಲ್ಲಿನ ಕಾರ್ಯದ ಹೆಸರಿನ ಮೇಲೆ ನೀವು ಕರ್ಸರ್ ಅನ್ನು ಸುಳಿದಾಡಿದರೆ, ಡೀಬಗ್ ಮಾಡುವ ಸಮಯದಲ್ಲಿ ಅದು ಸ್ಟಾಕ್‌ನಲ್ಲಿದ್ದ ಒಟ್ಟು ಸಮಯವನ್ನು ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ. HTTPServe ಕಾರ್ಯವು 65% ಸಮಯ, ಇತರ ರನ್ಟೈಮ್ ಕಾರ್ಯಗಳು runtime.mcall, mstart и gc, ಉಳಿದ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಂಡಿತು. ಮೋಜಿನ ಸಂಗತಿ: ಒಟ್ಟು ಸಮಯದ 5% DNS ಪ್ರಶ್ನೆಗಳಿಗೆ ವ್ಯಯಿಸಲಾಗಿದೆ:

ಪ್ರೋಗ್ರಾಂ ಹುಡುಕುವ ವಿಳಾಸಗಳು Postgresql ಗೆ ಸೇರಿವೆ. ಕ್ಲಿಕ್ ಮಾಡಿ FindByAge:

ಕುತೂಹಲಕಾರಿಯಾಗಿ, ಪ್ರೋಗ್ರಾಂ ತಾತ್ವಿಕವಾಗಿ, ವಿಳಂಬವನ್ನು ಸೇರಿಸುವ ಮೂರು ಮುಖ್ಯ ಮೂಲಗಳಿವೆ ಎಂದು ತೋರಿಸುತ್ತದೆ: ಸಂಪರ್ಕಗಳನ್ನು ತೆರೆಯುವುದು ಮತ್ತು ಮುಚ್ಚುವುದು, ಡೇಟಾವನ್ನು ವಿನಂತಿಸುವುದು ಮತ್ತು ಡೇಟಾಬೇಸ್ಗೆ ಸಂಪರ್ಕಿಸುವುದು. DNS ವಿನಂತಿಗಳು, ಸಂಪರ್ಕಗಳನ್ನು ತೆರೆಯುವುದು ಮತ್ತು ಮುಚ್ಚುವುದು ಒಟ್ಟು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯದ ಸುಮಾರು 13% ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಗ್ರಾಫ್ ತೋರಿಸುತ್ತದೆ.

ಕಲ್ಪನೆ: ಪೂಲಿಂಗ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಪರ್ಕಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡುವುದು ಒಂದೇ HTTP ವಿನಂತಿಯ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಹೆಚ್ಚಿನ ಥ್ರೋಪುಟ್ ಮತ್ತು ಕಡಿಮೆ ಸುಪ್ತತೆಯನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೊಂದಿಸಲಾಗುತ್ತಿದೆ - ಪ್ರಯೋಗ

ನಾವು ಮೂಲ ಕೋಡ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತೇವೆ, ಪ್ರತಿ ವಿನಂತಿಗಾಗಿ Postgresql ಗೆ ಸಂಪರ್ಕವನ್ನು ತೆಗೆದುಹಾಕಲು ಪ್ರಯತ್ನಿಸಿ. ಮೊದಲ ಆಯ್ಕೆಯನ್ನು ಬಳಸುವುದು ಸಂಪರ್ಕ ಪೂಲ್ ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದಲ್ಲಿ. ಈ ಪ್ರಯೋಗದಲ್ಲಿ ನಾವು ಅದನ್ನು ಹೊಂದಿಸೋಣ ಹೋಗುವುದಕ್ಕಾಗಿ sql ಚಾಲಕವನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಪರ್ಕ ಪೂಲಿಂಗ್:

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)

if err != nil {
   return nil, err
}

ಮರಣದಂಡನೆ, ವೀಕ್ಷಣೆ, ವಿಶ್ಲೇಷಣೆ

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 1000 ವಿನಂತಿಗಳೊಂದಿಗೆ ಪರೀಕ್ಷೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದ ನಂತರ, p99 ನ ಲೇಟೆನ್ಸಿ ಮಟ್ಟಗಳು 60ms ನ SLO ನೊಂದಿಗೆ ಸಾಮಾನ್ಯ ಸ್ಥಿತಿಗೆ ಮರಳಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ!

ವೆಚ್ಚ ಏನು?

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 10000 ವಿನಂತಿಗಳು / ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ 1000 ವಿನಂತಿಗಳು = 10 ಸರ್ವರ್‌ಗಳು + 1

ಅದನ್ನು ಇನ್ನೂ ಉತ್ತಮವಾಗಿ ಮಾಡೋಣ!

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 2000 ವಿನಂತಿಗಳು

ಲೋಡ್ ಅನ್ನು ದ್ವಿಗುಣಗೊಳಿಸುವುದು ಒಂದೇ ವಿಷಯವನ್ನು ತೋರಿಸುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್ ಸೆಕೆಂಡಿಗೆ 2000 ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, p100 60ms ಗಿಂತ ಕಡಿಮೆಯಾಗಿದೆ, p99 SLO ಅನ್ನು ತೃಪ್ತಿಪಡಿಸುತ್ತದೆ.

ವೆಚ್ಚದ ವಿಷಯದಲ್ಲಿ:

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 10000 ವಿನಂತಿಗಳು / ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ 2000 ವಿನಂತಿಗಳು = 5 ಸರ್ವರ್‌ಗಳು + 1

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 3000 ವಿನಂತಿಗಳು

ಇಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ 3000ms ಗಿಂತ ಕಡಿಮೆ p99 ಲೇಟೆನ್ಸಿಯೊಂದಿಗೆ 60 ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು. SLO ಅನ್ನು ಉಲ್ಲಂಘಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ವೆಚ್ಚವನ್ನು ಈ ಕೆಳಗಿನಂತೆ ಸ್ವೀಕರಿಸಲಾಗಿದೆ:

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 10000 ವಿನಂತಿಗಳು / ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ 3000 ವಿನಂತಿಗಳು = 4 ಸರ್ವರ್‌ಗಳು + 1 (ಲೇಖಕರು ಒಟ್ಟುಗೂಡಿಸಿದ್ದಾರೆ, ಅಂದಾಜು ಅನುವಾದಕ)

ಇನ್ನೊಂದು ಸುತ್ತಿನ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಪ್ರಯತ್ನಿಸೋಣ.

ವಿಶ್ಲೇಷಣೆ - ಊಹೆ

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 3000 ವಿನಂತಿಗಳಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಡೀಬಗ್ ಮಾಡುವ ಫಲಿತಾಂಶಗಳನ್ನು ನಾವು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ಪ್ರದರ್ಶಿಸುತ್ತೇವೆ:

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

ಕಲ್ಪನೆ: ಸಂಪರ್ಕಗಳು, ಪೂಲ್ನ ಉಪಸ್ಥಿತಿಯ ಹೊರತಾಗಿಯೂ, ಇನ್ನೂ ಕೈಬಿಡಲಾಗಿದೆ ಮತ್ತು ಸ್ವಚ್ಛಗೊಳಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಅವುಗಳನ್ನು ಮರುಹೊಂದಿಸಬೇಕಾಗಿದೆ. ಪೂಲ್ ಗಾತ್ರಕ್ಕೆ ಬಾಕಿಯಿರುವ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿಸುವುದು ಸಂಪರ್ಕವನ್ನು ರಚಿಸಲು ಅಪ್ಲಿಕೇಶನ್ ಕಳೆಯುವ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಮೂಲಕ ಸುಪ್ತತೆಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೊಂದಿಸಲಾಗುತ್ತಿದೆ - ಪ್ರಯೋಗ

ಸ್ಥಾಪಿಸಲು ಪ್ರಯತ್ನಿಸಲಾಗುತ್ತಿದೆ ಮ್ಯಾಕ್ಸ್‌ಐಡಲ್‌ಕಾನ್ಸ್ ಪೂಲ್ ಗಾತ್ರಕ್ಕೆ ಸಮನಾಗಿರುತ್ತದೆ (ಸಹ ವಿವರಿಸಲಾಗಿದೆ ಇಲ್ಲಿ):

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
db.SetMaxIdleConns(8)
if err != nil {
   return nil, err
}

ಮರಣದಂಡನೆ, ವೀಕ್ಷಣೆ, ವಿಶ್ಲೇಷಣೆ

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 3000 ವಿನಂತಿಗಳು

p99 ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ p60 ಜೊತೆಗೆ 100ms ಗಿಂತ ಕಡಿಮೆಯಾಗಿದೆ!

ಜ್ವಾಲೆಯ ಗ್ರಾಫ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದು ಸಂಪರ್ಕವು ಇನ್ನು ಮುಂದೆ ಗಮನಿಸುವುದಿಲ್ಲ ಎಂದು ತೋರಿಸುತ್ತದೆ! ಹೆಚ್ಚು ವಿವರವಾಗಿ ಪರಿಶೀಲಿಸೋಣ pg(*conn).query - ಇಲ್ಲಿ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಿರುವುದನ್ನು ನಾವು ಗಮನಿಸುವುದಿಲ್ಲ.

ತೀರ್ಮಾನಕ್ಕೆ

ಗ್ರಾಹಕರ ನಿರೀಕ್ಷೆಗಳು ಮತ್ತು ಕ್ರಿಯಾತ್ಮಕವಲ್ಲದ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸಲಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಕಾರ್ಯಕ್ಷಮತೆಯ ವಿಶ್ಲೇಷಣೆಯು ನಿರ್ಣಾಯಕವಾಗಿದೆ. ಗ್ರಾಹಕರ ನಿರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಅವಲೋಕನಗಳನ್ನು ಹೋಲಿಸುವ ಮೂಲಕ ವಿಶ್ಲೇಷಣೆಯು ಸ್ವೀಕಾರಾರ್ಹ ಮತ್ತು ಯಾವುದು ಅಲ್ಲ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ವಿಶ್ಲೇಷಣೆಯನ್ನು ಸರಳ ಮತ್ತು ಪ್ರವೇಶಿಸುವಂತೆ ಮಾಡುವ ಪ್ರಮಾಣಿತ ಗ್ರಂಥಾಲಯದಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಶಕ್ತಿಯುತ ಸಾಧನಗಳನ್ನು Go ಒದಗಿಸುತ್ತದೆ.

ಮೂಲ: www.habr.com