ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ CI ಸೇವೆಯಾಗಿ ಪರೀಕ್ಷೆಯನ್ನು ಲೋಡ್ ಮಾಡಿ

ಬಹು-ಉತ್ಪನ್ನ ಸಾಫ್ಟ್‌ವೇರ್ ಮಾರಾಟಗಾರರು ಸಾಮಾನ್ಯವಾಗಿ ಎದುರಿಸುವ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಒಂದಾದ ಇಂಜಿನಿಯರ್‌ಗಳ ಸಾಮರ್ಥ್ಯಗಳ ನಕಲು - ಡೆವಲಪರ್‌ಗಳು, ಪರೀಕ್ಷಕರು ಮತ್ತು ಮೂಲಸೌಕರ್ಯ ನಿರ್ವಾಹಕರು - ಪ್ರತಿಯೊಂದು ತಂಡದಲ್ಲೂ. ಇದು ದುಬಾರಿ ಎಂಜಿನಿಯರ್‌ಗಳಿಗೂ ಅನ್ವಯಿಸುತ್ತದೆ - ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಕ್ಷೇತ್ರದಲ್ಲಿ ತಜ್ಞರು.

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

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

ಪರಿಕಲ್ಪನೆಯ ಸಾರ

ಸೇವೆಯಾಗಿ ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಪರಿಕಲ್ಪನೆಯು ಲೋಡ್ ಉಪಕರಣಗಳನ್ನು ಅಪಾಚೆ JMeter, Yandex.Tank ಮತ್ತು ನಿಮ್ಮ ಸ್ವಂತ ಚೌಕಟ್ಟುಗಳನ್ನು ಅನಿಯಂತ್ರಿತ ನಿರಂತರ ಏಕೀಕರಣ ವ್ಯವಸ್ಥೆಗೆ ಸಂಯೋಜಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಡೆಮೊ GitLab CI ಗಾಗಿ ಇರುತ್ತದೆ, ಆದರೆ ತತ್ವಗಳು ಎಲ್ಲಾ CI ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಸಾಮಾನ್ಯವಾಗಿದೆ.

ಸೇವೆಯಾಗಿ ಲೋಡ್ ಪರೀಕ್ಷೆಯು ಲೋಡ್ ಪರೀಕ್ಷೆಗಾಗಿ ಕೇಂದ್ರೀಕೃತ ಸೇವೆಯಾಗಿದೆ. ಲೋಡ್ ಪರೀಕ್ಷೆಗಳನ್ನು ಮೀಸಲಾದ ಏಜೆಂಟ್ ಪೂಲ್‌ಗಳಲ್ಲಿ ನಡೆಸಲಾಗುತ್ತದೆ, ಫಲಿತಾಂಶಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ GitLab ಪುಟಗಳು, Influx DB ಮತ್ತು Grafana ಅಥವಾ ಪರೀಕ್ಷಾ ವರದಿ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ (TestRail, ReportPortal, ಇತ್ಯಾದಿ) ಪ್ರಕಟಿಸಲಾಗುತ್ತದೆ. ಆಟೊಮೇಷನ್ ಮತ್ತು ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳವಾಗಿ ಅಳವಡಿಸಲಾಗಿದೆ - GitLab CI ಯೋಜನೆಯಲ್ಲಿ ಸಾಮಾನ್ಯ gitlab-ci.yml ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಸೇರಿಸುವ ಮತ್ತು ಪ್ಯಾರಾಮೀಟರ್ ಮಾಡುವ ಮೂಲಕ.

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

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

ಲೋಡ್ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಮೂಲಭೂತ ಪರಿಕಲ್ಪನೆಗಳು ಮತ್ತು ವ್ಯಾಖ್ಯಾನಗಳು

ಲೋಡ್ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವಾಗ, ನಾವು ಅಂಟಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ ISTQB ಮಾನದಂಡಗಳು ಮತ್ತು ವಿಧಾನ, ಸೂಕ್ತವಾದ ಪರಿಭಾಷೆ ಮತ್ತು ಶಿಫಾರಸು ಮಾಡಲಾದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಬಳಸಿ. ಲೋಡ್ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಮುಖ್ಯ ಪರಿಕಲ್ಪನೆಗಳು ಮತ್ತು ವ್ಯಾಖ್ಯಾನಗಳ ಕಿರು ಪಟ್ಟಿಯನ್ನು ನಾನು ನೀಡುತ್ತೇನೆ.

ಲೋಡ್ ಏಜೆಂಟ್ - ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ವರ್ಚುವಲ್ ಯಂತ್ರ - ಲೋಡ್ ಮೂಲ (Apache JMeter, Yandex.Tank ಅಥವಾ ಸ್ವಯಂ-ಬರೆದ ಲೋಡ್ ಮಾಡ್ಯೂಲ್).

ಪರೀಕ್ಷಾ ಗುರಿ (ಗುರಿ) - ಸರ್ವರ್‌ನಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾದ ಸರ್ವರ್ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಲೋಡ್‌ಗೆ ಒಳಪಟ್ಟಿರುತ್ತದೆ.

ಪರೀಕ್ಷಾ ಸನ್ನಿವೇಶ (ಪರೀಕ್ಷಾ ಪ್ರಕರಣ) - ಪ್ಯಾರಾಮೀಟರ್ ಮಾಡಲಾದ ಹಂತಗಳ ಒಂದು ಸೆಟ್: ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ನಿಯತಾಂಕಗಳನ್ನು ಅವಲಂಬಿಸಿ ಸ್ಥಿರ ನೆಟ್‌ವರ್ಕ್ ವಿನಂತಿಗಳು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳೊಂದಿಗೆ ಈ ಕ್ರಿಯೆಗಳಿಗೆ ಬಳಕೆದಾರರ ಕ್ರಿಯೆಗಳು ಮತ್ತು ನಿರೀಕ್ಷಿತ ಪ್ರತಿಕ್ರಿಯೆಗಳು.

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

ಪರೀಕ್ಷೆ - ಪೂರ್ವನಿರ್ಧರಿತ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಸ್ಕ್ರಿಪ್ಟ್.

ಪರೀಕ್ಷಾ ಯೋಜನೆ (ಪರೀಕ್ಷಾ ಯೋಜನೆ) - ಪರೀಕ್ಷೆಗಳ ಒಂದು ಸೆಟ್ ಮತ್ತು ಲೋಡ್ ಪ್ರೊಫೈಲ್.

ಟೆಸ್ರಾನ್ (ಟೆಸ್ಟ್ರನ್) - ಸಂಪೂರ್ಣ ಕಾರ್ಯಗತಗೊಳಿಸಿದ ಲೋಡ್ ಸನ್ನಿವೇಶ ಮತ್ತು ಸ್ವೀಕರಿಸಿದ ವರದಿಯೊಂದಿಗೆ ಒಂದು ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುವ ಒಂದು ಪುನರಾವರ್ತನೆ.

ನೆಟ್‌ವರ್ಕ್ ವಿನಂತಿ (ವಿನಂತಿ) - ಏಜೆಂಟ್‌ನಿಂದ ಗುರಿಗೆ ಕಳುಹಿಸಲಾದ HTTP ವಿನಂತಿ.

ನೆಟ್‌ವರ್ಕ್ ಪ್ರತಿಕ್ರಿಯೆ (ಪ್ರತಿಕ್ರಿಯೆ) - ಗುರಿಯಿಂದ ಏಜೆಂಟ್‌ಗೆ ಕಳುಹಿಸಲಾದ HTTP ಪ್ರತಿಕ್ರಿಯೆ.
HTTP ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್ (HTTP ಪ್ರತಿಕ್ರಿಯೆಗಳ ಸ್ಥಿತಿ) - ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ನಿಂದ ಪ್ರಮಾಣಿತ ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್.
ವಹಿವಾಟು ಸಂಪೂರ್ಣ ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆ ಚಕ್ರವಾಗಿದೆ. ವಿನಂತಿಯನ್ನು (ವಿನಂತಿಯನ್ನು) ಕಳುಹಿಸುವ ಪ್ರಾರಂಭದಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು (ಪ್ರತಿಕ್ರಿಯೆ) ಸ್ವೀಕರಿಸುವವರೆಗೆ ವಹಿವಾಟನ್ನು ಎಣಿಸಲಾಗುತ್ತದೆ.

ವಹಿವಾಟಿನ ಸ್ಥಿತಿ - ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆ ಚಕ್ರವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಳಿಸಲು ಸಾಧ್ಯವೇ. ಈ ಚಕ್ರದಲ್ಲಿ ಯಾವುದೇ ದೋಷವಿದ್ದರೆ, ಸಂಪೂರ್ಣ ವಹಿವಾಟು ವಿಫಲವಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.

ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ (ಸುಪ್ತತೆ) - ವಿನಂತಿಯನ್ನು (ವಿನಂತಿಯನ್ನು) ಕಳುಹಿಸುವ ಅಂತ್ಯದಿಂದ ಪ್ರತಿಕ್ರಿಯೆ (ಪ್ರತಿಕ್ರಿಯೆ) ಸ್ವೀಕರಿಸುವ ಆರಂಭದ ಸಮಯ.

ಲೋಡ್ ಮೆಟ್ರಿಕ್ಸ್ - ಲೋಡ್ ಮಾಡಲಾದ ಸೇವೆಯ ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ಲೋಡ್ ಏಜೆಂಟ್ ಅನ್ನು ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ.

ಲೋಡ್ ನಿಯತಾಂಕಗಳನ್ನು ಅಳೆಯಲು ಮೂಲ ಮೆಟ್ರಿಕ್ಸ್

ವಿಧಾನದಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸುವ ಮತ್ತು ಶಿಫಾರಸು ಮಾಡಲಾದ ಕೆಲವು ISTQB (ಪುಟ 36, 52) ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಕೆಳಗಿನ ಕೋಷ್ಟಕದಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ. ಏಜೆಂಟ್ ಮತ್ತು ಗುರಿಗೆ ಒಂದೇ ರೀತಿಯ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಒಂದೇ ಸಾಲಿನಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡಲಾಗಿದೆ.

ಲೋಡ್ ಏಜೆಂಟ್‌ಗಾಗಿ ಮೆಟ್ರಿಕ್‌ಗಳು
ಗುರಿ ವ್ಯವಸ್ಥೆ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಲೋಡ್‌ನಲ್ಲಿ ಪರೀಕ್ಷಿಸಲಾಗುತ್ತಿದೆ

ಸಂಖ್ಯೆ  vCPU ಮತ್ತು ಸ್ಮರಣೆ ರಾಮ್,
ಡಿಸ್ಕ್ - ಲೋಡ್ ಏಜೆಂಟ್ನ "ಕಬ್ಬಿಣ" ಗುಣಲಕ್ಷಣಗಳು
ಸಿಪಿಯು, ಮೆಮೊರಿ, ಡಿಸ್ಕ್ ಬಳಕೆ - CPU ನ ಡೈನಾಮಿಕ್ಸ್, ಮೆಮೊರಿ ಮತ್ತು ಡಿಸ್ಕ್ ಲೋಡಿಂಗ್
ಪರೀಕ್ಷೆಯ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ. ಸಾಮಾನ್ಯವಾಗಿ ಶೇಕಡಾವಾರು ಪ್ರಮಾಣದಲ್ಲಿ ಅಳೆಯಲಾಗುತ್ತದೆ
ಲಭ್ಯವಿರುವ ಗರಿಷ್ಠ ಮೌಲ್ಯಗಳು

ನೆಟ್ವರ್ಕ್ ಥ್ರೋಪುಟ್ (ಲೋಡ್ ಏಜೆಂಟ್ ಮೇಲೆ) - ಥ್ರೋಪುಟ್
ಸರ್ವರ್‌ನಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್,
ಅಲ್ಲಿ ಲೋಡ್ ಏಜೆಂಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ.
ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಬೈಟ್‌ಗಳಲ್ಲಿ ಅಳೆಯಲಾಗುತ್ತದೆ (bps)
ನೆಟ್ವರ್ಕ್ ಥ್ರೋಪುಟ್(ಗುರಿಯಲ್ಲಿ) - ನೆಟ್ವರ್ಕ್ ಇಂಟರ್ಫೇಸ್ ಬ್ಯಾಂಡ್ವಿಡ್ತ್
ಗುರಿ ಸರ್ವರ್‌ನಲ್ಲಿ. ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಬೈಟ್‌ಗಳಲ್ಲಿ ಅಳೆಯಲಾಗುತ್ತದೆ (bps)

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

ಎಲ್ಲಾ ಬಳಕೆದಾರರು ಪೂರ್ಣಗೊಳಿಸಲು ಸಮರ್ಥರಾಗಿದ್ದಾರೆ ಎಂದು ಸಾಮಾನ್ಯವಾಗಿ ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ
ಲೋಡ್ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ನಿಮ್ಮ ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ.
ಯಾವುದೇ ದೋಷವು ನಿಜವಾದ ಬಳಕೆದಾರರಿಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ ಎಂದರ್ಥ
ಸಿಸ್ಟಮ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ನಿಮ್ಮ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿ

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ವಿನಂತಿಗಳು (ನಿಮಿಷ)- ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ನೆಟ್‌ವರ್ಕ್ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ (ಅಥವಾ ನಿಮಿಷ).

ಲೋಡ್ ಏಜೆಂಟ್‌ನ ಪ್ರಮುಖ ಲಕ್ಷಣವೆಂದರೆ ಅದು ಎಷ್ಟು ವಿನಂತಿಗಳನ್ನು ರಚಿಸಬಹುದು.
ವಾಸ್ತವವಾಗಿ, ಇದು ವರ್ಚುವಲ್ ಬಳಕೆದಾರರಿಂದ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಪ್ರವೇಶದ ಅನುಕರಣೆಯಾಗಿದೆ
ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಗಳು (ನಿಮಿಷ)
- ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ನೆಟ್‌ವರ್ಕ್ ಪ್ರತಿಕ್ರಿಯೆಗಳ ಸಂಖ್ಯೆ (ಅಥವಾ ನಿಮಿಷ).

ಗುರಿ ಸೇವೆಯ ಪ್ರಮುಖ ಲಕ್ಷಣ: ಎಷ್ಟು
ಜೊತೆಗೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ರಚಿಸಿ ಮತ್ತು ಕಳುಹಿಸಿ
ಲೋಡಿಂಗ್ ಏಜೆಂಟ್

HTTP ಪ್ರತಿಕ್ರಿಯೆ ಸ್ಥಿತಿ- ವಿಭಿನ್ನ ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್‌ಗಳ ಸಂಖ್ಯೆ
ಲೋಡ್ ಏಜೆಂಟ್ ಸ್ವೀಕರಿಸಿದ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ನಿಂದ.
ಉದಾಹರಣೆಗೆ, 200 ಸರಿ ಎಂದರೆ ಯಶಸ್ವಿ ಕರೆ,
ಮತ್ತು 404 - ಸಂಪನ್ಮೂಲ ಕಂಡುಬಂದಿಲ್ಲ ಎಂದು

ಸುಪ್ತತೆ (ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ) - ಅಂತ್ಯದಿಂದ ಸಮಯ
ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು (ಪ್ರತಿಕ್ರಿಯೆ) ಸ್ವೀಕರಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ವಿನಂತಿಯನ್ನು (ವಿನಂತಿಯನ್ನು) ಕಳುಹಿಸುವುದು.
ಸಾಮಾನ್ಯವಾಗಿ ಮಿಲಿಸೆಕೆಂಡುಗಳಲ್ಲಿ (ಮಿಸೆ) ಅಳೆಯಲಾಗುತ್ತದೆ

ವಹಿವಾಟಿನ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ- ಒಂದು ಸಂಪೂರ್ಣ ವಹಿವಾಟಿನ ಸಮಯ,
ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆಯ ಚಕ್ರವನ್ನು ಪೂರ್ಣಗೊಳಿಸುವುದು.
ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವ ಪ್ರಾರಂಭದ ಸಮಯ ಇದು (ವಿನಂತಿ)
ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುವವರೆಗೆ (ಪ್ರತಿಕ್ರಿಯೆ).

ವಹಿವಾಟಿನ ಸಮಯವನ್ನು ಸೆಕೆಂಡುಗಳಲ್ಲಿ (ಅಥವಾ ನಿಮಿಷಗಳಲ್ಲಿ) ಅಳೆಯಬಹುದು
ಹಲವಾರು ವಿಧಗಳಲ್ಲಿ: ಕನಿಷ್ಠವನ್ನು ಪರಿಗಣಿಸಿ,
ಗರಿಷ್ಠ, ಸರಾಸರಿ ಮತ್ತು, ಉದಾಹರಣೆಗೆ, 90 ನೇ ಶೇಕಡಾ.
ಕನಿಷ್ಠ ಮತ್ತು ಗರಿಷ್ಠ ವಾಚನಗೋಷ್ಠಿಗಳು ವಿಪರೀತವಾಗಿವೆ
ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸ್ಥಿತಿ.
ತೊಂಬತ್ತನೇ ಶೇಕಡಾವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ,
ಇದು ಹೆಚ್ಚಿನ ಬಳಕೆದಾರರನ್ನು ತೋರಿಸುತ್ತದೆ,
ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೊಸ್ತಿಲಲ್ಲಿ ಆರಾಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ

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

ವಹಿವಾಟಿನ ಸ್ಥಿತಿ , ಉತ್ತೀರ್ಣ / ವಿಫಲವಾಗಿದೆ / ಒಟ್ಟು - ಸಂಖ್ಯೆ
ಯಶಸ್ವಿ, ವಿಫಲ ಮತ್ತು ಒಟ್ಟು ವಹಿವಾಟುಗಳ ಸಂಖ್ಯೆ.

ನಿಜವಾದ ಬಳಕೆದಾರರಿಗೆ ವಿಫಲವಾಗಿದೆ
ವಹಿವಾಟು ವಾಸ್ತವವಾಗಿ ಅರ್ಥ
ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಸಿಸ್ಟಮ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಅಸಮರ್ಥತೆ

ಲೋಡ್ ಟೆಸ್ಟಿಂಗ್ ಸ್ಕೀಮ್ಯಾಟಿಕ್ ರೇಖಾಚಿತ್ರ

ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಪರಿಕಲ್ಪನೆಯು ತುಂಬಾ ಸರಳವಾಗಿದೆ ಮತ್ತು ನಾನು ಈಗಾಗಲೇ ಉಲ್ಲೇಖಿಸಿರುವ ಮೂರು ಮುಖ್ಯ ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿದೆ: ತಯಾರು-ಪರೀಕ್ಷೆ-ವರದಿ, ಅಂದರೆ, ಪರೀಕ್ಷಾ ಗುರಿಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುವುದು ಮತ್ತು ಲೋಡ್ ಮೂಲಗಳಿಗಾಗಿ ನಿಯತಾಂಕಗಳನ್ನು ಹೊಂದಿಸುವುದು, ನಂತರ ಲೋಡ್ ಪರೀಕ್ಷೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಮತ್ತು ಕೊನೆಯಲ್ಲಿ, ಪರೀಕ್ಷಾ ವರದಿಯನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಪ್ರಕಟಿಸುವುದು.

ಸ್ಕೀಮ್ಯಾಟಿಕ್ ಟಿಪ್ಪಣಿಗಳು:

• QA.ಪರೀಕ್ಷಕ ಲೋಡ್ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಪರಿಣಿತರಾಗಿದ್ದಾರೆ,
• ಟಾರ್ಗೆಟ್ ಟಾರ್ಗೆಟ್ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದೆ, ಇದಕ್ಕಾಗಿ ನೀವು ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಅದರ ನಡವಳಿಕೆಯನ್ನು ತಿಳಿದುಕೊಳ್ಳಲು ಬಯಸುತ್ತೀರಿ.

ರೇಖಾಚಿತ್ರದಲ್ಲಿ ಘಟಕಗಳು, ಹಂತಗಳು ಮತ್ತು ಹಂತಗಳ ವರ್ಗೀಕರಣ

ಹಂತಗಳು ಮತ್ತು ಹಂತಗಳು
ಏನಾಗುತ್ತಿದೆ
ಪ್ರವೇಶದ್ವಾರದಲ್ಲಿ ಏನಿದೆ
ಔಟ್ಪುಟ್ ಏನು

ತಯಾರಿ: ಪರೀಕ್ಷೆಗೆ ತಯಾರಿ ಹಂತ

ಲೋಡ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು
ಸೆಟ್ಟಿಂಗ್ ಮತ್ತು ಪ್ರಾರಂಭ
ಬಳಕೆದಾರ
ಲೋಡ್ ನಿಯತಾಂಕಗಳು,
ಮೆಟ್ರಿಕ್ಸ್ ಆಯ್ಕೆ ಮತ್ತು
ಪರೀಕ್ಷಾ ಯೋಜನೆ ತಯಾರಿ
(ಲೋಡ್ ಪ್ರೊಫೈಲ್)
ಇದಕ್ಕಾಗಿ ಕಸ್ಟಮ್ ಆಯ್ಕೆಗಳು
ಲೋಡ್ ಏಜೆಂಟ್ ಪ್ರಾರಂಭ
ಪರೀಕ್ಷಾ ಯೋಜನೆ
ಪರೀಕ್ಷೆಯ ಉದ್ದೇಶ

VM
ಮೇಘ ನಿಯೋಜನೆ
ಜೊತೆ ವರ್ಚುವಲ್ ಯಂತ್ರ
ಅಗತ್ಯವಿರುವ ಗುಣಲಕ್ಷಣಗಳು
ಲೋಡ್ ಏಜೆಂಟ್‌ಗಾಗಿ VM ಸೆಟ್ಟಿಂಗ್‌ಗಳು
ಆಟೋಮೇಷನ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು
VM ರಚನೆ
VM ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ
ಮೋಡ

ಎನ್ವಿ
ಓಎಸ್ ಸೆಟಪ್ ಮತ್ತು ತಯಾರಿ
ಪರಿಸರ
ಲೋಡ್ ಏಜೆಂಟ್ ಕೆಲಸ
ಇದಕ್ಕಾಗಿ ಪರಿಸರ ಸೆಟ್ಟಿಂಗ್‌ಗಳು
ಲೋಡ್ ಏಜೆಂಟ್
ಆಟೋಮೇಷನ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು
ಪರಿಸರ ಸೆಟ್ಟಿಂಗ್ಗಳು
ಸಿದ್ಧಪಡಿಸಿದ ಪರಿಸರ:
OS, ಸೇವೆಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು,
ಕೆಲಸಕ್ಕೆ ಅವಶ್ಯಕ
ಲೋಡ್ ಏಜೆಂಟ್

ಲೋಡ್ ಏಜೆಂಟ್ಸ್
ಅನುಸ್ಥಾಪನೆ, ಸಂರಚನೆ ಮತ್ತು ನಿಯತಾಂಕೀಕರಣ
ಲೋಡಿಂಗ್ ಏಜೆಂಟ್.
ಅಥವಾ ಡಾಕರ್ ಚಿತ್ರವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾಗುತ್ತಿದೆ
ಮೊದಲೇ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಲೋಡ್ ಮೂಲ
ಮೂಲ ಡಾಕರ್ ಚಿತ್ರವನ್ನು ಲೋಡ್ ಮಾಡಿ
(YAT, JM ಅಥವಾ ಸ್ವಯಂ-ಲಿಖಿತ ಚೌಕಟ್ಟು)
ಸಂಯೋಜನೆಗಳು
ಲೋಡ್ ಏಜೆಂಟ್
ಹೊಂದಿಸಿ ಮತ್ತು ಸಿದ್ಧವಾಗಿದೆ
ಲೋಡ್ ಏಜೆಂಟ್ ಕೆಲಸ ಮಾಡಲು

ಪರೀಕ್ಷೆ: ಲೋಡ್ ಪರೀಕ್ಷೆಗಳ ಮರಣದಂಡನೆಯ ಹಂತ. ಮೂಲಗಳು GitLab CI ಗಾಗಿ ಮೀಸಲಾದ ಏಜೆಂಟ್ ಪೂಲ್‌ಗಳಲ್ಲಿ ನಿಯೋಜಿಸಲಾದ ಲೋಡ್ ಏಜೆಂಟ್‌ಗಳಾಗಿವೆ

ಲೋಡ್
ಲೋಡ್ ಏಜೆಂಟ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತಿದೆ
ಆಯ್ದ ಪರೀಕ್ಷಾ ಯೋಜನೆಯೊಂದಿಗೆ
ಮತ್ತು ಲೋಡ್ ನಿಯತಾಂಕಗಳು
ಬಳಕೆದಾರ ಆಯ್ಕೆಗಳು
ಪ್ರಾರಂಭಕ್ಕಾಗಿ
ಲೋಡ್ ಏಜೆಂಟ್
ಪರೀಕ್ಷಾ ಯೋಜನೆ
ಪರೀಕ್ಷೆಯ ಉದ್ದೇಶ
ಮರಣದಂಡನೆ ದಾಖಲೆಗಳು
ಲೋಡ್ ಪರೀಕ್ಷೆಗಳು
ಸಿಸ್ಟಮ್ ಲಾಗ್‌ಗಳು
ಗೋಲ್ ಮೆಟ್ರಿಕ್ಸ್ ಮತ್ತು ಲೋಡ್ ಏಜೆಂಟ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳ ಡೈನಾಮಿಕ್ಸ್

ಏಜೆಂಟರನ್ನು ರನ್ ಮಾಡಿ
ಏಜೆಂಟ್ ಎಕ್ಸಿಕ್ಯೂಶನ್
ಪರೀಕ್ಷಾ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಲೋಡ್
ಅನುಗುಣವಾಗಿ
ಪ್ರೊಫೈಲ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಿ
ಲೋಡ್ ಏಜೆಂಟ್ ಪರಸ್ಪರ ಕ್ರಿಯೆ
ಪರೀಕ್ಷೆಯ ಉದ್ದೇಶಕ್ಕಾಗಿ
ಪರೀಕ್ಷಾ ಯೋಜನೆ
ಪರೀಕ್ಷೆಯ ಉದ್ದೇಶ

ದಾಖಲೆಗಳು
"ಕಚ್ಚಾ" ದಾಖಲೆಗಳ ಸಂಗ್ರಹ
ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ:
ಲೋಡ್ ಏಜೆಂಟ್ ಚಟುವಟಿಕೆ ದಾಖಲೆಗಳು,
ಪರೀಕ್ಷಾ ಗುರಿಯ ಸ್ಥಿತಿ
ಮತ್ತು VM ಏಜೆಂಟ್ ಅನ್ನು ನಡೆಸುತ್ತಿದೆ

ಮರಣದಂಡನೆ ದಾಖಲೆಗಳು
ಲೋಡ್ ಪರೀಕ್ಷೆಗಳು
ಸಿಸ್ಟಮ್ ಲಾಗ್‌ಗಳು

ಮೆಟ್ರಿಕ್ಸ್
ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ "ಕಚ್ಚಾ" ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು

ಗುರಿ ಮೆಟ್ರಿಕ್‌ಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳ ಡೈನಾಮಿಕ್ಸ್
ಮತ್ತು ಲೋಡ್ ಏಜೆಂಟ್

ವರದಿ: ಪರೀಕ್ಷಾ ವರದಿ ತಯಾರಿ ಹಂತ

ಜನರೇಟರ್
ಸಂಸ್ಕರಣೆ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ
ಲೋಡ್ ವ್ಯವಸ್ಥೆ ಮತ್ತು
ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ "ಕಚ್ಚಾ"
ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ದಾಖಲೆಗಳು
ರಲ್ಲಿ ವರದಿಯ ರಚನೆ
ಮಾನವ ಓದಬಲ್ಲ ರೂಪ
ಅಂಶಗಳೊಂದಿಗೆ ಸಾಧ್ಯ
ವಿಶ್ಲೇಷಕರು
ಮರಣದಂಡನೆ ದಾಖಲೆಗಳು
ಲೋಡ್ ಪರೀಕ್ಷೆಗಳು
ಸಿಸ್ಟಮ್ ಲಾಗ್‌ಗಳು
ಮೆಟ್ರಿಕ್ಸ್ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳ ಡೈನಾಮಿಕ್ಸ್
ಗುರಿ ಮತ್ತು ಲೋಡ್ ಏಜೆಂಟ್
ಸಂಸ್ಕರಿಸಿದ "ಕಚ್ಚಾ" ದಾಖಲೆಗಳು
ಸೂಕ್ತವಾದ ರೂಪದಲ್ಲಿ
ಬಾಹ್ಯ ಸಂಗ್ರಹಣೆಗೆ ಅಪ್‌ಲೋಡ್‌ಗಳು
ಸ್ಥಿರ ಲೋಡ್ ವರದಿ,
ಮಾನವ-ಓದಬಲ್ಲ

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

CI ಟೆಂಪ್ಲೇಟ್‌ನಲ್ಲಿ ಲೋಡ್ ಮೂಲಗಳನ್ನು ಸಂಪರ್ಕಿಸಲಾಗುತ್ತಿದೆ

ಪ್ರಾಯೋಗಿಕ ಭಾಗಕ್ಕೆ ಹೋಗೋಣ. ಕಂಪನಿಯಲ್ಲಿನ ಕೆಲವು ಯೋಜನೆಗಳಲ್ಲಿ ಹೇಗೆ ಎಂಬುದನ್ನು ತೋರಿಸಲು ನಾನು ಬಯಸುತ್ತೇನೆ ಧನಾತ್ಮಕ ತಂತ್ರಜ್ಞಾನಗಳು ನಾವು ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಪರಿಕಲ್ಪನೆಯನ್ನು ಸೇವೆಯಾಗಿ ಜಾರಿಗೆ ತಂದಿದ್ದೇವೆ.

ಮೊದಲಿಗೆ, ನಮ್ಮ DevOps ಇಂಜಿನಿಯರ್‌ಗಳ ಸಹಾಯದಿಂದ, ಲೋಡ್ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಲು GitLab CI ನಲ್ಲಿ ನಾವು ಏಜೆಂಟ್‌ಗಳ ಮೀಸಲಾದ ಪೂಲ್ ಅನ್ನು ರಚಿಸಿದ್ದೇವೆ. ಅಸೆಂಬ್ಲಿ ಪೂಲ್‌ಗಳಂತಹ ಇತರರೊಂದಿಗೆ ಟೆಂಪ್ಲೇಟ್‌ಗಳಲ್ಲಿ ಅವುಗಳನ್ನು ಗೊಂದಲಗೊಳಿಸದಿರಲು, ನಾವು ಈ ಏಜೆಂಟ್‌ಗಳಿಗೆ ಟ್ಯಾಗ್‌ಗಳನ್ನು ಸೇರಿಸಿದ್ದೇವೆ, ಟ್ಯಾಗ್ಗಳು: ಲೋಡ್. ನೀವು ಅರ್ಥವಾಗುವ ಯಾವುದೇ ಇತರ ಟ್ಯಾಗ್‌ಗಳನ್ನು ಬಳಸಬಹುದು. ಅವರು ಕೇಳುತ್ತಾರೆ ನೋಂದಣಿ ಸಮಯದಲ್ಲಿ GitLab CI ರನ್ನರ್ಸ್.

ಹಾರ್ಡ್ವೇರ್ ಮೂಲಕ ಅಗತ್ಯವಾದ ಶಕ್ತಿಯನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಹೇಗೆ? ಲೋಡ್ ಏಜೆಂಟ್‌ಗಳ ಗುಣಲಕ್ಷಣಗಳು - ಸಾಕಷ್ಟು ಸಂಖ್ಯೆಯ vCPU, RAM ಮತ್ತು ಡಿಸ್ಕ್ - ಏಜೆಂಟ್‌ನಲ್ಲಿ ಡಾಕರ್, ಪೈಥಾನ್ (Yandex.Tank ಗಾಗಿ), GitLab CI ಏಜೆಂಟ್, Java (Apache JMeter ಗಾಗಿ) ಚಾಲನೆಯಾಗಬೇಕು ಎಂಬ ಅಂಶವನ್ನು ಆಧರಿಸಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡಬಹುದು. . JMeter ಅಡಿಯಲ್ಲಿ Java ಗಾಗಿ, ಕನಿಷ್ಟ 512 MB RAM ಅನ್ನು ಬಳಸಲು ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಮೇಲಿನ ಮಿತಿಯಾಗಿ, 80% ಲಭ್ಯವಿರುವ ಮೆಮೊರಿ.

ಹೀಗಾಗಿ, ನಮ್ಮ ಅನುಭವದ ಆಧಾರದ ಮೇಲೆ, ಲೋಡ್ ಏಜೆಂಟ್‌ಗಳಿಗಾಗಿ ಕನಿಷ್ಠ 4 vCPU ಗಳು, 4 GB RAM, 60 GB SSD ಅನ್ನು ಬಳಸಲು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಲೋಡ್ ಪ್ರೊಫೈಲ್ನ ಅಗತ್ಯತೆಗಳ ಆಧಾರದ ಮೇಲೆ ನೆಟ್ವರ್ಕ್ ಕಾರ್ಡ್ನ ಥ್ರೋಪುಟ್ ಅನ್ನು ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ.

ನಾವು ಮುಖ್ಯವಾಗಿ ಎರಡು ಲೋಡ್ ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತೇವೆ - Apache JMeter ಮತ್ತು Yandex.Tank ಡಾಕರ್ ಚಿತ್ರಗಳು.

Yandex.Tank ಲೋಡ್ ಪರೀಕ್ಷೆಗಾಗಿ Yandex ನಿಂದ ತೆರೆದ ಮೂಲ ಸಾಧನವಾಗಿದೆ. ಇದರ ಮಾಡ್ಯುಲರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಫ್ಯಾಂಟಮ್‌ನ ಉನ್ನತ-ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಸಮಕಾಲಿಕ ಹಿಟ್-ಆಧಾರಿತ HTTP ವಿನಂತಿ ಜನರೇಟರ್ ಅನ್ನು ಆಧರಿಸಿದೆ. ಟ್ಯಾಂಕ್ SSH ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಪರೀಕ್ಷೆಯ ಅಡಿಯಲ್ಲಿ ಸರ್ವರ್‌ನ ಸಂಪನ್ಮೂಲಗಳ ಅಂತರ್ನಿರ್ಮಿತ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಹೊಂದಿದೆ, ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪರೀಕ್ಷೆಯನ್ನು ನಿಲ್ಲಿಸಬಹುದು, ಫಲಿತಾಂಶಗಳನ್ನು ಕನ್ಸೋಲ್‌ನಲ್ಲಿ ಮತ್ತು ಗ್ರಾಫ್‌ಗಳ ರೂಪದಲ್ಲಿ ಪ್ರದರ್ಶಿಸಬಹುದು, ನಿಮ್ಮ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ನೀವು ಸಂಪರ್ಕಿಸಬಹುದು ಕಾರ್ಯವನ್ನು ವಿಸ್ತರಿಸಲು ಅದಕ್ಕೆ. ಅಂದಹಾಗೆ, ಟ್ಯಾಂಕ್ ಇನ್ನೂ ಮುಖ್ಯವಾಹಿನಿಯಾಗಿಲ್ಲದಿದ್ದಾಗ ನಾವು ಅದನ್ನು ಬಳಸಿದ್ದೇವೆ. ಲೇಖನದಲ್ಲಿ "Yandex.Tank ಮತ್ತು ಲೋಡ್ ಪರೀಕ್ಷೆ ಯಾಂತ್ರೀಕೃತಗೊಂಡ» 2013 ರಲ್ಲಿ ನಾವು ಅದರೊಂದಿಗೆ ಲೋಡ್ ಪರೀಕ್ಷೆಯನ್ನು ಹೇಗೆ ನಡೆಸಿದ್ದೇವೆ ಎಂಬ ಕಥೆಯನ್ನು ನೀವು ಓದಬಹುದು PT ಅಪ್ಲಿಕೇಶನ್ ಫೈರ್ವಾಲ್ ನಮ್ಮ ಕಂಪನಿಯ ಉತ್ಪನ್ನಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.

ಅಪಾಚೆ ಜೆಮೆಟರ್ ಅಪಾಚೆಯಿಂದ ತೆರೆದ ಮೂಲ ಲೋಡ್ ಪರೀಕ್ಷಾ ಸಾಧನವಾಗಿದೆ. ಸ್ಥಿರ ಮತ್ತು ಡೈನಾಮಿಕ್ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಇದನ್ನು ಸಮಾನವಾಗಿ ಬಳಸಬಹುದು. JMeter ಬೃಹತ್ ಸಂಖ್ಯೆಯ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವ ವಿಧಾನಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, ಇತ್ಯಾದಿ), SOAP / REST ವೆಬ್‌ಸೇವೆಗಳು, FTP, TCP, LDAP, SMTP(S), POP3( S) ) ಮತ್ತು IMAP(S), JDBC ಮೂಲಕ ಡೇಟಾಬೇಸ್‌ಗಳು, ಶೆಲ್ ಆಜ್ಞೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು ಮತ್ತು ಜಾವಾ ಆಬ್ಜೆಕ್ಟ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು. JMeter ಪರೀಕ್ಷಾ ಯೋಜನೆಗಳನ್ನು ರಚಿಸಲು, ಡೀಬಗ್ ಮಾಡಲು ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸಲು IDE ಅನ್ನು ಹೊಂದಿದೆ. ಯಾವುದೇ ಜಾವಾ ಹೊಂದಾಣಿಕೆಯ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ (ಲಿನಕ್ಸ್, ವಿಂಡೋಸ್, ಮ್ಯಾಕ್ ಓಎಸ್ ಎಕ್ಸ್) ಕಮಾಂಡ್ ಲೈನ್ ಕಾರ್ಯಾಚರಣೆಗಾಗಿ ಸಿಎಲ್‌ಐ ಸಹ ಇದೆ. ಉಪಕರಣವು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ HTML ಪರೀಕ್ಷಾ ವರದಿಯನ್ನು ರಚಿಸಬಹುದು.

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

Yandex.Tank ಗಾಗಿ ನಾವು ಈ ಮೂಲ ಡಾಕರ್ ಫೈಲ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ:

Dockerfile 
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]

ಮತ್ತು Apache JMeter ಗಾಗಿ ಇದು:

Dockerfile 
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]

ನಮ್ಮ ನಿರಂತರ ಏಕೀಕರಣ ವ್ಯವಸ್ಥೆಯು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಲೇಖನದಲ್ಲಿ ನೀವು ಓದಬಹುದು "ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಗಳ ಆಟೊಮೇಷನ್: ನಾವು ಧನಾತ್ಮಕ ತಂತ್ರಜ್ಞಾನಗಳಲ್ಲಿ DevOps ಕಲ್ಪನೆಗಳನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ».

ಟೆಂಪ್ಲೇಟ್ ಮತ್ತು ಪೈಪ್ಲೈನ್

ಲೋಡ್ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಲು ಟೆಂಪ್ಲೇಟ್ನ ಉದಾಹರಣೆ ಯೋಜನೆಯಲ್ಲಿ ಲಭ್ಯವಿದೆ ಡೆಮೊ ಲೋಡ್. ದಿ readme ಫೈಲ್ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಬಳಸುವ ಸೂಚನೆಗಳನ್ನು ನೀವು ಓದಬಹುದು. ಟೆಂಪ್ಲೇಟ್‌ನಲ್ಲಿಯೇ (ಫೈಲ್ .gitlab-ci.yml) ಪ್ರತಿ ಹಂತವು ಯಾವುದಕ್ಕೆ ಕಾರಣವಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ಟಿಪ್ಪಣಿಗಳಿವೆ.

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

1. ಹಂತ ತಯಾರು ಪರೀಕ್ಷಾ ಗುರಿಗಳನ್ನು ಪೂರ್ವ ಸಂರಚಿಸಲು ಅಥವಾ ಅವುಗಳ ಲಭ್ಯತೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಬಳಸಬೇಕು. ಲೋಡ್ ಮೂಲಗಳ ಪರಿಸರವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗಿಲ್ಲ, ಅವುಗಳನ್ನು ಡಾಕರ್ ಚಿತ್ರಗಳಾಗಿ ಮೊದಲೇ ನಿರ್ಮಿಸಲಾಗಿದೆ ಮತ್ತು ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿಯಲ್ಲಿ ಪೋಸ್ಟ್ ಮಾಡಲಾಗಿದೆ: ಪರೀಕ್ಷಾ ಹಂತದಲ್ಲಿ ಬಯಸಿದ ಆವೃತ್ತಿಯನ್ನು ಸೂಚಿಸಿ. ಆದರೆ ನೀವು ಅವುಗಳನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಬಹುದು ಮತ್ತು ನಿಮ್ಮ ಸ್ವಂತ ಮಾರ್ಪಡಿಸಿದ ಚಿತ್ರಗಳನ್ನು ಮಾಡಬಹುದು.
2. ಹಂತ ಟೆಸ್ಟ್ ಲೋಡ್ ಮೂಲವನ್ನು ಸೂಚಿಸಲು, ಪರೀಕ್ಷೆಗಳನ್ನು ಚಲಾಯಿಸಲು ಮತ್ತು ಪರೀಕ್ಷಾ ಕಲಾಕೃತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ನೀವು ಯಾವುದೇ ಲೋಡ್ ಮೂಲವನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು: Yandex.Tank, Apache JMeter, ನಿಮ್ಮ ಸ್ವಂತ, ಅಥವಾ ಎಲ್ಲಾ ಒಟ್ಟಿಗೆ. ಅನಗತ್ಯ ಮೂಲಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು, ಕಾಮೆಂಟ್ ಮಾಡಿ ಅಥವಾ ಕೆಲಸವನ್ನು ಅಳಿಸಿ. ಲೋಡ್ ಮೂಲಗಳಿಗೆ ಪ್ರವೇಶ ಬಿಂದುಗಳು:
   • Yandex.Tank ಗಾಗಿ ಲಾಂಚ್ ನಿಯತಾಂಕಗಳನ್ನು ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ./tests/yandextank.sh,
   • Apache JMeter ಆರಂಭಿಕ ನಿಯತಾಂಕಗಳನ್ನು ಫೈಲ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ ./tests/jmeter.sh.

   ಗಮನಿಸಿ: ಅಸೆಂಬ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು CI ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಸಂವಾದವನ್ನು ಹೊಂದಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದರಲ್ಲಿ ಪರೀಕ್ಷಾ ತರ್ಕವನ್ನು ಇರಿಸುವುದನ್ನು ಸೂಚಿಸುವುದಿಲ್ಲ. ಪರೀಕ್ಷೆಗಳಿಗೆ, ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ, ಅಲ್ಲಿ ನಿಯಂತ್ರಣ ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್ ಇದೆ. ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವ ವಿಧಾನ, ವರದಿಗಳನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಪರೀಕ್ಷಾ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಸ್ವತಃ QA ಎಂಜಿನಿಯರ್‌ಗಳು ಅಳವಡಿಸಬೇಕು. ಡೆಮೊದಲ್ಲಿ, ಎರಡೂ ಲೋಡ್ ಮೂಲಗಳಿಗಾಗಿ, ಯಾಂಡೆಕ್ಸ್ ಮುಖ್ಯ ಪುಟ ವಿನಂತಿಯನ್ನು ಸರಳವಾದ ಪರೀಕ್ಷೆಯಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಮತ್ತು ಪರೀಕ್ಷಾ ನಿಯತಾಂಕಗಳು ಡೈರೆಕ್ಟರಿಯಲ್ಲಿವೆ ./ಪರೀಕ್ಷೆಗಳು.

3. ವೇದಿಕೆಯಲ್ಲಿ ವರದಿ ಪರೀಕ್ಷಾ ಹಂತದಲ್ಲಿ ಪಡೆದ ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳನ್ನು ಬಾಹ್ಯ ಸಂಗ್ರಹಣೆಗಳಿಗೆ ಹೇಗೆ ಪ್ರಕಟಿಸಬೇಕು ಎಂಬುದನ್ನು ನೀವು ವಿವರಿಸಬೇಕಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, GitLab ಪುಟಗಳು ಅಥವಾ ವಿಶೇಷ ವರದಿ ಮಾಡುವ ವ್ಯವಸ್ಥೆಗಳಿಗೆ. GitLab ಪುಟಗಳಿಗೆ ./public ಡೈರೆಕ್ಟರಿ ಖಾಲಿಯಾಗಿರಬಾರದು ಮತ್ತು ಪರೀಕ್ಷೆಗಳು ಮುಗಿದ ನಂತರ ಕನಿಷ್ಠ ಒಂದು index.html ಫೈಲ್ ಅನ್ನು ಹೊಂದಿರಬೇಕು. GitLab ಪುಟಗಳ ಸೇವೆಯ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳ ಬಗ್ಗೆ ನೀವು ಓದಬಹುದು. ಲಿಂಕ್.

   ಡೇಟಾವನ್ನು ಹೇಗೆ ರಫ್ತು ಮಾಡುವುದು ಎಂಬುದರ ಉದಾಹರಣೆಗಳು:

   • ಜೆಮೀಟರ್‌ನಿಂದ GitLab ಪುಟಗಳು,
   • Yandex.Tank ನಿಂದ InfluxDB ಮತ್ತು Grafana.

   ಸೆಟಪ್ ಸೂಚನೆಗಳನ್ನು ಪೋಸ್ಟ್ ಮಾಡಲಾಗುತ್ತಿದೆ:

   • HTML ಸ್ಟ್ಯಾಟಿಕ್ಸ್ ಇನ್ GitLab ಪುಟಗಳು,
   • InfluxDB ಗೆ ಮತ್ತು ನಂತರ ಗ್ರಾಫಾನಾ.

ಡೆಮೊ ಉದಾಹರಣೆಯಲ್ಲಿ, ಲೋಡ್ ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ಎರಡು ಲೋಡ್ ಮೂಲಗಳೊಂದಿಗೆ ಪೈಪ್‌ಲೈನ್ (ನೀವು ಅನಗತ್ಯವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು) ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

Apache JMeter ಸ್ವತಃ HTML ವರದಿಯನ್ನು ರಚಿಸಬಹುದು, ಆದ್ದರಿಂದ ಪ್ರಮಾಣಿತ ಸಾಧನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅದನ್ನು GitLab ಪುಟಗಳಲ್ಲಿ ಉಳಿಸಲು ಹೆಚ್ಚು ಲಾಭದಾಯಕವಾಗಿದೆ. ಅಪಾಚೆ ಜೆಮೀಟರ್ ವರದಿಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

Yandex.Tank ಗಾಗಿ ಡೆಮೊ ಉದಾಹರಣೆಯಲ್ಲಿ, ನೀವು ಮಾತ್ರ ನೋಡುತ್ತೀರಿ ನಕಲಿ ಪಠ್ಯ ವರದಿ GitLab ಪುಟಗಳಿಗಾಗಿ ವಿಭಾಗದಲ್ಲಿ. ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ, ಟ್ಯಾಂಕ್ ಫಲಿತಾಂಶಗಳನ್ನು InfluxDB ಡೇಟಾಬೇಸ್‌ಗೆ ಉಳಿಸಬಹುದು ಮತ್ತು ಅಲ್ಲಿಂದ ಅವುಗಳನ್ನು ಪ್ರದರ್ಶಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಗ್ರಾಫಾನಾದಲ್ಲಿ (ಫೈಲ್‌ನಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಮಾಡಲಾಗುತ್ತದೆ ./tests/example-yandextank-test.yml) ಗ್ರಾಫನಾದಲ್ಲಿ ಟ್ಯಾಂಕ್‌ನ ವರದಿಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ಸಾರಾಂಶ

ಲೇಖನದಲ್ಲಿ, ನಾನು "ಒಂದು ಸೇವೆಯಾಗಿ ಲೋಡ್ ಪರೀಕ್ಷೆ" (ಒಂದು ಸೇವೆಯಾಗಿ ಲೋಡ್ ಪರೀಕ್ಷೆ) ಪರಿಕಲ್ಪನೆಯ ಬಗ್ಗೆ ಮಾತನಾಡಿದ್ದೇನೆ. ಲೋಡ್ ಏಜೆಂಟ್‌ಗಳ ಪೂರ್ವ-ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಪೂಲ್‌ಗಳ ಮೂಲಸೌಕರ್ಯವನ್ನು ಬಳಸುವುದು, ಲೋಡ್ ಮೂಲಗಳ ಡಾಕರ್ ಚಿತ್ರಗಳು, ವರದಿ ಮಾಡುವ ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು ಸರಳವಾದ .gitlab-ci.yml ಟೆಂಪ್ಲೇಟ್ (ಉದಾಹರಣೆ) ಆಧಾರದ ಮೇಲೆ ಅವುಗಳನ್ನು GitLab CI ನಲ್ಲಿ ಸಂಯೋಜಿಸುವ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಬಳಸುವುದು ಮುಖ್ಯ ಆಲೋಚನೆಯಾಗಿದೆ. ಲಿಂಕ್) ಇವೆಲ್ಲವನ್ನೂ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಎಂಜಿನಿಯರ್‌ಗಳ ಸಣ್ಣ ತಂಡವು ಬೆಂಬಲಿಸುತ್ತದೆ ಮತ್ತು ಉತ್ಪನ್ನ ತಂಡಗಳ ಕೋರಿಕೆಯ ಮೇರೆಗೆ ಪುನರಾವರ್ತಿಸುತ್ತದೆ. ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ಇದೇ ರೀತಿಯ ಯೋಜನೆಯನ್ನು ತಯಾರಿಸಲು ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಇದು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಗಮನಕ್ಕೆ ಧನ್ಯವಾದಗಳು!

ನಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ಸೇವೆಯಾಗಿ ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಪರಿಕಲ್ಪನೆಯ ಅನುಷ್ಠಾನಕ್ಕೆ ತಾಂತ್ರಿಕ ಸಹಾಯಕ್ಕಾಗಿ ನನ್ನ ಸಹೋದ್ಯೋಗಿಗಳಾದ ಸೆರ್ಗೆಯ್ ಕುರ್ಬನೋವ್ ಮತ್ತು ನಿಕೊಲಾಯ್ ಯುಸೆವ್ ಅವರಿಗೆ ನಾನು ದೊಡ್ಡ ಧನ್ಯವಾದ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ.

ಲೇಖಕ: ತೈಮೂರ್ ಗಿಲ್ಮುಲಿನ್ - ಉಪ ಧನಾತ್ಮಕ ತಂತ್ರಜ್ಞಾನಗಳಲ್ಲಿ ತಂತ್ರಜ್ಞಾನ ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಗಳ ಮುಖ್ಯಸ್ಥ (DevOps)

ಮೂಲ: www.habr.com