ನಾವು ವಿಧಾನದ ಬಗ್ಗೆ ಮಾತನಾಡಿದ್ದೇವೆ ಲೇಖನ, ಇದರಲ್ಲಿ ನಾವು HTTPS ಅನ್ನು ಪರೀಕ್ಷಿಸುತ್ತೇವೆ, ಆದರೆ ಹೆಚ್ಚು ವಾಸ್ತವಿಕ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ. ಪರೀಕ್ಷೆಗಾಗಿ, ನಾವು ಲೆಟ್ಸ್ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಬ್ರೋಟ್ಲಿ ಕಂಪ್ರೆಷನ್ ಅನ್ನು 11 ಕ್ಕೆ ಸಕ್ರಿಯಗೊಳಿಸಿದ್ದೇವೆ.
ಈ ಸಮಯದಲ್ಲಿ ನಾವು ಸರ್ವರ್ ಅನ್ನು ವಿಡಿಎಸ್‌ನಲ್ಲಿ ಅಥವಾ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಪ್ರೊಸೆಸರ್‌ನೊಂದಿಗೆ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ವರ್ಚುವಲ್ ಯಂತ್ರವಾಗಿ ನಿಯೋಜಿಸುವ ಸನ್ನಿವೇಶವನ್ನು ಪುನರುತ್ಪಾದಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ, ಮಿತಿಯನ್ನು ಇಲ್ಲಿ ಹೊಂದಿಸಲಾಗಿದೆ:
- 25% - ಇದು ~ 1350 MHz ಆವರ್ತನಕ್ಕೆ ಸಮನಾಗಿರುತ್ತದೆ
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
ಒಂದು ಬಾರಿಯ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯನ್ನು 500 ರಿಂದ 1, 3, 5, 7 ಮತ್ತು 9 ಕ್ಕೆ ಇಳಿಸಲಾಗಿದೆ,
ಫಲಿತಾಂಶಗಳು:
ವಿಳಂಬಗಳು:
TTFB ಅನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ಪ್ರತ್ಯೇಕ ಪರೀಕ್ಷೆಯಾಗಿ ಸೇರಿಸಲಾಗಿದೆ, ಏಕೆಂದರೆ HTTPD ಪರಿಕರಗಳು ಪ್ರತಿಯೊಂದು ವಿನಂತಿಗೆ ಹೊಸ ಬಳಕೆದಾರರನ್ನು ರಚಿಸುತ್ತವೆ. ಈ ಪರೀಕ್ಷೆಯು ಇನ್ನೂ ವಾಸ್ತವದಿಂದ ಸಾಕಷ್ಟು ಬೇರ್ಪಟ್ಟಿದೆ, ಏಕೆಂದರೆ ಬಳಕೆದಾರರು ಇನ್ನೂ ಒಂದೆರಡು ಪುಟಗಳನ್ನು ಕ್ಲಿಕ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ವಾಸ್ತವದಲ್ಲಿ TTFP ಮುಖ್ಯ ಪಾತ್ರವನ್ನು ವಹಿಸುತ್ತದೆ.
ಮೊದಲನೆಯದು, ಸಾಮಾನ್ಯವಾಗಿ IIS ವರ್ಚುವಲ್ ಯಂತ್ರದ ಮೊದಲ ಪ್ರಾರಂಭದ ನಂತರದ ಮೊದಲ ವಿನಂತಿಯು ಸರಾಸರಿ 120 ms ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಎಲ್ಲಾ ನಂತರದ ವಿನಂತಿಗಳು 1.5 ms ನ TTFP ಅನ್ನು ತೋರಿಸುತ್ತವೆ. Apache ಮತ್ತು Nginx ಈ ವಿಷಯದಲ್ಲಿ ಹಿಂದುಳಿದಿವೆ. ವೈಯಕ್ತಿಕವಾಗಿ, ಲೇಖಕರು ಈ ಪರೀಕ್ಷೆಯನ್ನು ಅತ್ಯಂತ ಬಹಿರಂಗವಾಗಿ ಪರಿಗಣಿಸುತ್ತಾರೆ ಮತ್ತು ಅದರ ಆಧಾರದ ಮೇಲೆ ಮಾತ್ರ ವಿಜೇತರನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ.
IIS ಸಂಗ್ರಹಗಳು ಈಗಾಗಲೇ ಸ್ಥಿರ ವಿಷಯವನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಿರುವುದರಿಂದ ಮತ್ತು ಅದನ್ನು ಪ್ರವೇಶಿಸಿದಾಗಲೆಲ್ಲಾ ಅದನ್ನು ಸಂಕುಚಿತಗೊಳಿಸದ ಕಾರಣ ಫಲಿತಾಂಶವು ಆಶ್ಚರ್ಯವೇನಿಲ್ಲ.
ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ಗೆ ಖರ್ಚು ಮಾಡಿದ ಸಮಯ
ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು, 1 ಏಕ ಸಂಪರ್ಕದೊಂದಿಗೆ ಪರೀಕ್ಷೆಯು ಸಾಕಾಗುತ್ತದೆ.
ಉದಾಹರಣೆಗೆ, IIS 5000 ಸೆಕೆಂಡುಗಳಲ್ಲಿ 40 ಬಳಕೆದಾರರ ಪರೀಕ್ಷೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಿತು, ಅಂದರೆ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 123 ವಿನಂತಿಗಳು.
ಕೆಳಗಿನ ಗ್ರಾಫ್‌ಗಳು ಸೈಟ್ ವಿಷಯವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ವರ್ಗಾಯಿಸುವವರೆಗೆ ಸಮಯವನ್ನು ತೋರಿಸುತ್ತವೆ. ಇದು ನಿರ್ದಿಷ್ಟ ಸಮಯದಲ್ಲಿ ಪೂರ್ಣಗೊಂಡ ವಿನಂತಿಗಳ ಅನುಪಾತವಾಗಿದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಎಲ್ಲಾ ವಿನಂತಿಗಳಲ್ಲಿ 80% ಅನ್ನು IIS ನಲ್ಲಿ 8ms ನಲ್ಲಿ ಮತ್ತು Apache ಮತ್ತು Nginx ನಲ್ಲಿ 4.5ms ನಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು Apache ಮತ್ತು Nginx ನಲ್ಲಿ 8% ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು 98 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳ ಮಧ್ಯಂತರದಲ್ಲಿ ಪೂರ್ಣಗೊಳಿಸಲಾಗಿದೆ.
5000 ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ಸಮಯ:
5000 ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ಸಮಯ:
ನೀವು 3.5GHz CPU ಮತ್ತು 8 ಕೋರ್‌ಗಳೊಂದಿಗೆ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಆಯ್ಕೆಮಾಡಿ. ಈ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಎಲ್ಲಾ ವೆಬ್ ಸರ್ವರ್‌ಗಳು ಹೋಲುತ್ತವೆ. ಕೆಳಗಿನ ಪ್ರತಿ ಹೋಸ್ಟ್‌ಗೆ ಯಾವ ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕೆಂದು ನಾವು ಮಾತನಾಡುತ್ತೇವೆ.
ಸ್ವಲ್ಪ ಹೆಚ್ಚು ವಾಸ್ತವಿಕ ಪರಿಸ್ಥಿತಿಗೆ ಬಂದಾಗ, ಎಲ್ಲಾ ವೆಬ್ ಸರ್ವರ್‌ಗಳು ತಲೆಗೆ ಹೋಗುತ್ತವೆ.
ಥ್ರೋಪುಟ್:
ಏಕಕಾಲಿಕ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯ ವಿರುದ್ಧ ವಿಳಂಬಗಳ ಗ್ರಾಫ್. ನಯವಾದ ಮತ್ತು ಕಡಿಮೆ ಉತ್ತಮವಾಗಿದೆ. ಕೊನೆಯ 2% ಅನ್ನು ಚಾರ್ಟ್‌ಗಳಿಂದ ತೆಗೆದುಹಾಕಲಾಗಿದೆ ಏಕೆಂದರೆ ಅವುಗಳು ಅವುಗಳನ್ನು ಓದಲಾಗದಂತೆ ಮಾಡುತ್ತದೆ.
ಈಗ ವರ್ಚುವಲ್ ಹೋಸ್ಟಿಂಗ್‌ನಲ್ಲಿ ಸರ್ವರ್ ಅನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ಆಯ್ಕೆಯನ್ನು ಪರಿಗಣಿಸೋಣ. 4 GHz ನಲ್ಲಿ 2.2 ಕೋರ್ಗಳನ್ನು ಮತ್ತು 1.8 GHz ನಲ್ಲಿ ಒಂದು ಕೋರ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ.
ಅಳೆಯುವುದು ಹೇಗೆ
ನಿರ್ವಾತ ಟ್ರಯೋಡ್‌ಗಳು, ಪೆಂಟೋಡ್‌ಗಳು ಮತ್ತು ಮುಂತಾದವುಗಳ ಪ್ರಸ್ತುತ-ವೋಲ್ಟೇಜ್ ಗುಣಲಕ್ಷಣಗಳು ಹೇಗಿವೆ ಎಂಬುದನ್ನು ನೀವು ಎಂದಾದರೂ ನೋಡಿದ್ದರೆ, ಈ ಗ್ರಾಫ್‌ಗಳು ನಿಮಗೆ ಪರಿಚಿತವಾಗಿರುತ್ತವೆ. ನಾವು ಹಿಡಿಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವುದು ಇದನ್ನೇ - ಶುದ್ಧತ್ವ. ಮಿತಿ ಎಂದರೆ ನೀವು ಎಷ್ಟು ಕೋರ್ಗಳನ್ನು ಎಸೆದರೂ ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೆಚ್ಚಳವು ಗಮನಿಸುವುದಿಲ್ಲ.
ಹಿಂದೆ, 98% ವಿನಂತಿಗಳನ್ನು ಎಲ್ಲಾ ವಿನಂತಿಗಳಿಗೆ ಕಡಿಮೆ ಲೇಟೆನ್ಸಿಯೊಂದಿಗೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದು ಸಂಪೂರ್ಣ ಸವಾಲಾಗಿತ್ತು, ಕರ್ವ್ ಅನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸಮತಟ್ಟಾಗಿ ಇರಿಸುತ್ತದೆ. ಈಗ, ಮತ್ತೊಂದು ಕರ್ವ್ ಅನ್ನು ನಿರ್ಮಿಸುವ ಮೂಲಕ, ಪ್ರತಿಯೊಂದು ಸರ್ವರ್‌ಗಳಿಗೆ ಸೂಕ್ತವಾದ ಆಪರೇಟಿಂಗ್ ಪಾಯಿಂಟ್ ಅನ್ನು ನಾವು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ.
ಇದನ್ನು ಮಾಡಲು, ನಾವು ಸೆಕೆಂಡಿಗೆ ವಿನಂತಿಗಳು (RPR) ಸೂಚಕವನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ. ಸಮತಲವು ಆವರ್ತನ, ಲಂಬವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾದ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ, ಸಾಲುಗಳು ಕೋರ್ಗಳ ಸಂಖ್ಯೆ.
Nginx ವಿನಂತಿಗಳನ್ನು ಒಂದರ ನಂತರ ಒಂದರಂತೆ ಹೇಗೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಎಂಬುದರ ಪರಸ್ಪರ ಸಂಬಂಧವನ್ನು ತೋರಿಸುತ್ತದೆ. ಈ ಪರೀಕ್ಷೆಯಲ್ಲಿ 8 ಕೋರ್‌ಗಳು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.
ಒಂದೇ ಕೋರ್‌ನಲ್ಲಿ Nginx ಎಷ್ಟು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ (ಹೆಚ್ಚು ಅಲ್ಲ) ಈ ಗ್ರಾಫ್ ಸ್ಪಷ್ಟವಾಗಿ ತೋರಿಸುತ್ತದೆ. ನೀವು Nginx ಹೊಂದಿದ್ದರೆ, ನೀವು ಸ್ಥಿರವಾದವುಗಳನ್ನು ಮಾತ್ರ ಹೋಸ್ಟ್ ಮಾಡುತ್ತಿದ್ದರೆ ಕೋರ್ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಒಂದಕ್ಕೆ ಕಡಿಮೆ ಮಾಡಲು ನೀವು ಪರಿಗಣಿಸಬೇಕು.
IIS, Chrome ನಲ್ಲಿನ DevTools ಪ್ರಕಾರ ಕಡಿಮೆ TTFB ಅನ್ನು ಹೊಂದಿದ್ದರೂ, ಅಪಾಚೆ ಫೌಂಡೇಶನ್‌ನಿಂದ ಒತ್ತಡ ಪರೀಕ್ಷೆಯೊಂದಿಗೆ ಗಂಭೀರ ಹೋರಾಟದಲ್ಲಿ Nginx ಮತ್ತು Apache ಎರಡನ್ನೂ ಕಳೆದುಕೊಳ್ಳಲು ನಿರ್ವಹಿಸುತ್ತದೆ.
ಗ್ರಾಫ್‌ಗಳ ಎಲ್ಲಾ ವಕ್ರತೆಯನ್ನು ಕಬ್ಬಿಣದ ಹೊದಿಕೆಯಿಂದ ಪುನರುತ್ಪಾದಿಸಲಾಗಿದೆ.
ಕೆಲವು ರೀತಿಯ ತೀರ್ಮಾನ:
ಹೌದು, ಅಪಾಚೆ 1 ಮತ್ತು 8 ಕೋರ್‌ಗಳಲ್ಲಿ ಕೆಟ್ಟದಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ 4 ನಲ್ಲಿ ಸ್ವಲ್ಪ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಹೌದು, 8 ಕೋರ್‌ಗಳಲ್ಲಿನ Nginx 1 ಮತ್ತು 4 ಕೋರ್‌ಗಳಲ್ಲಿ ಒಂದರ ನಂತರ ಒಂದರಂತೆ ಉತ್ತಮವಾಗಿ ವಿನಂತಿಸುತ್ತದೆ ಮತ್ತು ಅನೇಕ ಸಂಪರ್ಕಗಳಿದ್ದಾಗ ಕೆಟ್ಟದಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಹೌದು, IIS ಮಲ್ಟಿ-ಥ್ರೆಡ್ ವರ್ಕ್‌ಲೋಡ್‌ಗಳಿಗಾಗಿ 4 ಕೋರ್ಗಳನ್ನು ಆದ್ಯತೆ ನೀಡುತ್ತದೆ ಮತ್ತು ಸಿಂಗಲ್-ಥ್ರೆಡ್ ವರ್ಕ್‌ಲೋಡ್‌ಗಳಿಗೆ 8 ಕೋರ್ಗಳನ್ನು ಆದ್ಯತೆ ನೀಡುತ್ತದೆ. ಅಂತಿಮವಾಗಿ, IIS ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳು ಸರಿಸಮಾನವಾಗಿದ್ದರೂ, ಹೆಚ್ಚಿನ ಲೋಡ್‌ನಲ್ಲಿ 8 ಕೋರ್‌ಗಳಲ್ಲಿ ಎಲ್ಲರಿಗಿಂತ ಸ್ವಲ್ಪ ವೇಗವಾಗಿತ್ತು.
ಇದು ಮಾಪನ ದೋಷವಲ್ಲ, ಇಲ್ಲಿ ದೋಷವು +-1ms ಗಿಂತ ಹೆಚ್ಚಿಲ್ಲ. ವಿಳಂಬದಲ್ಲಿ ಮತ್ತು RPR ಗಾಗಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ +- 2-3 ವಿನಂತಿಗಳಿಗಿಂತ ಹೆಚ್ಚಿಲ್ಲ.
8 ಕೋರ್‌ಗಳು ಕೆಟ್ಟದಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಫಲಿತಾಂಶಗಳು ಆಶ್ಚರ್ಯಕರವಲ್ಲ, ನಾವು ಸಂಪೂರ್ಣ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸಬೇಕಾದ ಸಮಯದ ಚೌಕಟ್ಟನ್ನು ಹೊಂದಿದ್ದರೆ ಅನೇಕ ಕೋರ್‌ಗಳು ಮತ್ತು SMT/ಹೈಪರ್‌ಥ್ರೆಡಿಂಗ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಬಹಳವಾಗಿ ಕುಗ್ಗಿಸುತ್ತದೆ.
ಮೂಲ: www.habr.com