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

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

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

ಲಿನಕ್ಸ್ ಆಗಿದೆ ಸರ್ವರ್ ಕೊಠಡಿ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್, ಮತ್ತು ಹೆಚ್ಚಾಗಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಈ OS ನಲ್ಲಿ ರನ್ ಆಗುತ್ತವೆ. ನಾನು "Linux" ಎಂದು ಹೇಳುತ್ತಿದ್ದರೂ, ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲಾ Unix-ರೀತಿಯ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ನಾನು ಅರ್ಥೈಸುತ್ತೇನೆ ಎಂದು ನೀವು ಸುರಕ್ಷಿತವಾಗಿ ಊಹಿಸಬಹುದು. ಆದಾಗ್ಯೂ, ನಾನು ಇತರ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಜೊತೆಯಲ್ಲಿರುವ ಕೋಡ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿಲ್ಲ. ಆದ್ದರಿಂದ, ನೀವು FreeBSD ಅಥವಾ OpenBSD ನಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, ನಿಮ್ಮ ಫಲಿತಾಂಶಗಳು ಬದಲಾಗಬಹುದು. ನಾನು ಲಿನಕ್ಸ್-ನಿರ್ದಿಷ್ಟ ಏನನ್ನಾದರೂ ಪ್ರಯತ್ನಿಸಿದಾಗ, ನಾನು ಅದನ್ನು ಸೂಚಿಸುತ್ತೇನೆ.

ಮೊದಲಿನಿಂದಲೂ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ನೀವು ಈ ಜ್ಞಾನವನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲಾಗುತ್ತದೆ, ಹಾಗೆ ಮಾಡದಿರುವುದು ಉತ್ತಮ. ನಿಮ್ಮ ಸಂಸ್ಥೆಯ ವ್ಯಾಪಾರ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ ನೀವು C ಅಥವಾ C++ ನಲ್ಲಿ ಹೊಸ ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ಬರೆದರೆ, ಇದು ನಿಮ್ಮ ಕೆಲಸದ ಕೊನೆಯ ದಿನವಾಗಿರಬಹುದು. ಆದಾಗ್ಯೂ, ಈ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ರಚನೆಯನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರೋಗ್ರಾಂಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಪ್ರಕ್ರಿಯೆ-ಆಧಾರಿತ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಥ್ರೆಡ್-ಆಧಾರಿತ ವ್ಯವಸ್ಥೆಗಳೊಂದಿಗೆ ಮತ್ತು ಈವೆಂಟ್-ಆಧಾರಿತ ವ್ಯವಸ್ಥೆಗಳೊಂದಿಗೆ ಹೋಲಿಸಲು ನಿಮಗೆ ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಅಪಾಚೆ httpd ಗಿಂತ Nginx ಏಕೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ ಮತ್ತು ಪ್ರಶಂಸಿಸುತ್ತೀರಿ, ಜಾಂಗೊ ಆಧಾರಿತ ಪೈಥಾನ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹೋಲಿಸಿದರೆ ಸುಂಟರಗಾಳಿ ಆಧಾರಿತ ಪೈಥಾನ್ ಅಪ್ಲಿಕೇಶನ್ ಏಕೆ ಹೆಚ್ಚಿನ ಬಳಕೆದಾರರಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ.

ZeroHTTPd: ಕಲಿಕೆಯ ಸಾಧನ

ಶೂನ್ಯHTTPd ನಾನು ಬೋಧನಾ ಸಾಧನವಾಗಿ C ನಲ್ಲಿ ಮೊದಲಿನಿಂದ ಬರೆದ ವೆಬ್ ಸರ್ವರ್ ಆಗಿದೆ. ಇದು Redis ಗೆ ಪ್ರವೇಶ ಸೇರಿದಂತೆ ಯಾವುದೇ ಬಾಹ್ಯ ಅವಲಂಬನೆಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ನಾವು ನಮ್ಮದೇ ಆದ ರೆಡಿಸ್ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ನಡೆಸುತ್ತೇವೆ. ಹೆಚ್ಚಿನ ವಿವರಗಳಿಗಾಗಿ ಕೆಳಗೆ ನೋಡಿ.

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

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

ZeroHTTPd ಮುಖಪುಟ. ಇದು ಚಿತ್ರಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ವಿವಿಧ ಫೈಲ್ ಪ್ರಕಾರಗಳನ್ನು ಔಟ್ಪುಟ್ ಮಾಡಬಹುದು

ಅತಿಥಿ ಪುಸ್ತಕ ಅಪ್ಲಿಕೇಶನ್

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

ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ "ಅತಿಥಿ ಪುಸ್ತಕ" ZeroHTTPd

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

ಕ್ಲೈಂಟ್ (ಬ್ರೌಸರ್) ವಿನಂತಿಸಿದಾಗ ಅಪ್ಲಿಕೇಶನ್ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಕೆಳಗಿನ ಅಂಕಿ ತೋರಿಸುತ್ತದೆ /guestbookURL.

ಅತಿಥಿ ಪುಸ್ತಕ ಅಪ್ಲಿಕೇಶನ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ

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

ಸರ್ವರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ಸ್ ZeroHTTPd

ನಾವು ZeroHTTPd ಯ ಏಳು ಆವೃತ್ತಿಗಳನ್ನು ಒಂದೇ ರೀತಿಯ ಕ್ರಿಯಾತ್ಮಕತೆಯೊಂದಿಗೆ ಆದರೆ ವಿಭಿನ್ನ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳೊಂದಿಗೆ ನಿರ್ಮಿಸುತ್ತಿದ್ದೇವೆ:

ಪುನರಾವರ್ತಿತ
ಫೋರ್ಕ್ ಸರ್ವರ್ (ಪ್ರತಿ ವಿನಂತಿಗೆ ಒಂದು ಮಗುವಿನ ಪ್ರಕ್ರಿಯೆ)
ಪ್ರಿ-ಫೋರ್ಕ್ ಸರ್ವರ್ (ಪ್ರಕ್ರಿಯೆಗಳ ಪೂರ್ವ-ಫೋರ್ಕಿಂಗ್)
ಎಕ್ಸಿಕ್ಯೂಶನ್ ಥ್ರೆಡ್‌ಗಳೊಂದಿಗೆ ಸರ್ವರ್ (ಪ್ರತಿ ವಿನಂತಿಗೆ ಒಂದು ಥ್ರೆಡ್)
ಪೂರ್ವ-ಥ್ರೆಡ್ ರಚನೆಯೊಂದಿಗೆ ಸರ್ವರ್
ವಾಸ್ತುಶಿಲ್ಪ ಆಧಾರಿತ poll()
ವಾಸ್ತುಶಿಲ್ಪ ಆಧಾರಿತ epoll

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

ಪರೀಕ್ಷಾ ವಿಧಾನ

ZeroHTTPd ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಸೆಟಪ್

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

ಈ ಪ್ರತಿಯೊಂದು ಸರ್ವರ್‌ಗಳು ಏನು ಮಾಡುತ್ತವೆ?

load.unixism.net: ಇಲ್ಲಿ ನಾವು ಓಡುತ್ತೇವೆ ab, ಅಪಾಚೆ ಬೆಂಚ್‌ಮಾರ್ಕ್ ಉಪಯುಕ್ತತೆ. ಇದು ನಮ್ಮ ಸರ್ವರ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಬೇಕಾದ ಲೋಡ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ.
nginx.unixism.net: ಕೆಲವೊಮ್ಮೆ ನಾವು ಸರ್ವರ್ ಪ್ರೋಗ್ರಾಂನ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ನಿದರ್ಶನಗಳನ್ನು ಚಲಾಯಿಸಲು ಬಯಸುತ್ತೇವೆ. ಇದನ್ನು ಮಾಡಲು, ಸೂಕ್ತವಾದ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ Nginx ಸರ್ವರ್ ಬರುವ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ab ನಮ್ಮ ಸರ್ವರ್ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ.
zerohttpd.unixism.net: ಇಲ್ಲಿ ನಾವು ನಮ್ಮ ಸರ್ವರ್ ಪ್ರೋಗ್ರಾಂಗಳನ್ನು ಏಳು ವಿಭಿನ್ನ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳಲ್ಲಿ ಒಂದೊಂದಾಗಿ ರನ್ ಮಾಡುತ್ತೇವೆ.
redis.unixism.net: ಈ ಸರ್ವರ್ Redis ಡೀಮನ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ, ಅಲ್ಲಿ ಅತಿಥಿ ಪುಸ್ತಕ ನಮೂದುಗಳು ಮತ್ತು ಸಂದರ್ಶಕರ ಕೌಂಟರ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ.

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

ನಾವು ಏನು ಅಳೆಯುತ್ತಿದ್ದೇವೆ?

ನೀವು ವಿವಿಧ ಸೂಚಕಗಳನ್ನು ಅಳೆಯಬಹುದು. ಸಮಾನಾಂತರತೆಯ ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ ವಿನಂತಿಗಳೊಂದಿಗೆ ಸರ್ವರ್‌ಗಳನ್ನು ಲೋಡ್ ಮಾಡುವ ಮೂಲಕ ಈ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಪ್ರತಿ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನಾವು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೇವೆ: ಲೋಡ್ 20 ರಿಂದ 15 ಏಕಕಾಲೀನ ಬಳಕೆದಾರರಿಂದ ಬೆಳೆಯುತ್ತದೆ.

ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳು

ಕೆಳಗಿನ ಚಾರ್ಟ್ ಸಮಾನಾಂತರತೆಯ ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ ವಿವಿಧ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳಲ್ಲಿ ಸರ್ವರ್‌ಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ತೋರಿಸುತ್ತದೆ. y-ಅಕ್ಷವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ, x-ಅಕ್ಷವು ಸಮಾನಾಂತರ ಸಂಪರ್ಕಗಳು.

ಫಲಿತಾಂಶಗಳೊಂದಿಗೆ ಟೇಬಲ್ ಕೆಳಗೆ ಇದೆ.

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

ಸಮಾನಾಂತರತೆ
ಪುನರಾವರ್ತಿತ
ಫೋರ್ಕ್
ಪೂರ್ವ ಫೋರ್ಕ್
ಸ್ಟ್ರೀಮಿಂಗ್
ಪೂರ್ವ-ಸ್ಟ್ರೀಮಿಂಗ್
ಮತದಾನ
ಎಪೋಲ್

20
7
112
2100
1800
2250
1900
2050

50
7
190
2200
1700
2200
2000
2000

100
7
245
2200
1700
2200
2150
2100

200
7
330
2300
1750
2300
2200
2100

300
-
380
2200
1800
2400
2250
2150

400
-
410
2200
1750
2600
2000
2000

500
-
440
2300
1850
2700
1900
2212

600
-
460
2400
1800
2500
1700
2519

700
-
460
2400
1600
2490
1550
2607

800
-
460
2400
1600
2540
1400
2553

900
-
460
2300
1600
2472
1200
2567

1000
-
475
2300
1700
2485
1150
2439

1500
-
490
2400
1550
2620
900
2479

2000
-
350
2400
1400
2396
550
2200

2500
-
280
2100
1300
2453
490
2262

3000
-
280
1900
1250
2502
ದೊಡ್ಡ ಹರಡುವಿಕೆ
2138

5000
-
ದೊಡ್ಡ ಹರಡುವಿಕೆ
1600
1100
2519
-
2235

8000
-
-
1200
ದೊಡ್ಡ ಹರಡುವಿಕೆ
2451
-
2100

10 ರೂ
-
-
ದೊಡ್ಡ ಹರಡುವಿಕೆ
-
2200
-
2200

11 ರೂ
-
-
-
-
2200
-
2122

12 ರೂ
-
-
-
-
970
-
1958

13 ರೂ
-
-
-
-
730
-
1897

14 ರೂ
-
-
-
-
590
-
1466

15 ರೂ
-
-
-
-
532
-
1281

ಗ್ರಾಫ್ ಮತ್ತು ಟೇಬಲ್‌ನಿಂದ 8000 ಏಕಕಾಲಿಕ ವಿನಂತಿಗಳ ಮೇಲೆ ನಾವು ಕೇವಲ ಇಬ್ಬರು ಆಟಗಾರರನ್ನು ಮಾತ್ರ ಹೊಂದಿದ್ದೇವೆ ಎಂದು ನೋಡಬಹುದು: ಪ್ರಿ-ಫೋರ್ಕ್ ಮತ್ತು ಎಪೋಲ್. ಲೋಡ್ ಹೆಚ್ಚಾದಂತೆ, ಪೋಲ್-ಆಧಾರಿತ ಸರ್ವರ್ ಸ್ಟ್ರೀಮಿಂಗ್ ಒಂದಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಥ್ರೆಡ್-ಪ್ರಿ-ಕ್ರಿಯೇಶನ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಎಪೋಲ್‌ಗೆ ಯೋಗ್ಯವಾದ ಪ್ರತಿಸ್ಪರ್ಧಿಯಾಗಿದೆ, ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಥ್ರೆಡ್‌ಗಳನ್ನು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ನಿಗದಿಪಡಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಾಗಿದೆ.

ZeroHTTPd ಮೂಲ ಕೋಡ್

ZeroHTTPd ಮೂಲ ಕೋಡ್ ಇಲ್ಲಿ. ಪ್ರತಿ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ಪ್ರತ್ಯೇಕ ಡೈರೆಕ್ಟರಿ ಇದೆ.

ಶೂನ್ಯHTTPd
│
├── 01_ಪುನರಾವರ್ತನೆ
│ ├── main.c
├──02_ಫೋರ್ಕಿಂಗ್
│ ├── main.c
├── 03_ಪ್ರಿಫೋರ್ಕಿಂಗ್
│ ├── main.c
├── 04_ಥ್ರೆಡಿಂಗ್
│ ├── main.c
├── 05_ಪ್ರಿಥ್ರೆಡಿಂಗ್
│ ├── main.c
├── 06_poll
│ ├── main.c
├── 07_epoll
│ └── main.c
├── ಮೇಕ್ಫೈಲ್
├──ಸಾರ್ವಜನಿಕ
│ ├── index.html
│ └── tux.png
└── ಟೆಂಪ್ಲೇಟ್‌ಗಳು
    └── ಅತಿಥಿ ಪುಸ್ತಕ
        └── index.html

ಎಲ್ಲಾ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳಿಗೆ ಏಳು ಡೈರೆಕ್ಟರಿಗಳ ಜೊತೆಗೆ, ಉನ್ನತ ಮಟ್ಟದ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಇನ್ನೂ ಎರಡು ಇವೆ: ಸಾರ್ವಜನಿಕ ಮತ್ತು ಟೆಂಪ್ಲೇಟ್‌ಗಳು. ಮೊದಲನೆಯದು index.html ಫೈಲ್ ಮತ್ತು ಮೊದಲ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ನಿಂದ ಚಿತ್ರವನ್ನು ಒಳಗೊಂಡಿದೆ. ನೀವು ಅಲ್ಲಿ ಇತರ ಫೈಲ್‌ಗಳು ಮತ್ತು ಫೋಲ್ಡರ್‌ಗಳನ್ನು ಹಾಕಬಹುದು ಮತ್ತು ZeroHTTPd ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ಆ ಸ್ಥಿರ ಫೈಲ್‌ಗಳನ್ನು ಪೂರೈಸಬೇಕು. ಬ್ರೌಸರ್‌ನಲ್ಲಿನ ಮಾರ್ಗವು ಸಾರ್ವಜನಿಕ ಫೋಲ್ಡರ್‌ನಲ್ಲಿರುವ ಮಾರ್ಗಕ್ಕೆ ಹೊಂದಿಕೆಯಾದರೆ, ZeroHTTPd ಈ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ index.html ಫೈಲ್‌ಗಾಗಿ ಹುಡುಕುತ್ತದೆ. ಅತಿಥಿ ಪುಸ್ತಕದ ವಿಷಯವನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ರಚಿಸಲಾಗಿದೆ. ಇದು ಮುಖಪುಟವನ್ನು ಮಾತ್ರ ಹೊಂದಿದೆ ಮತ್ತು ಅದರ ವಿಷಯವು 'templates/guestbook/index.html' ಫೈಲ್ ಅನ್ನು ಆಧರಿಸಿದೆ. ZeroHTTPd ವಿಸ್ತರಣೆಗಾಗಿ ಡೈನಾಮಿಕ್ ಪುಟಗಳನ್ನು ಸುಲಭವಾಗಿ ಸೇರಿಸುತ್ತದೆ. ಬಳಕೆದಾರರು ಈ ಡೈರೆಕ್ಟರಿಗೆ ಟೆಂಪ್ಲೇಟ್‌ಗಳನ್ನು ಸೇರಿಸಬಹುದು ಮತ್ತು ZeroHTTPd ಅನ್ನು ಅಗತ್ಯವಿರುವಂತೆ ವಿಸ್ತರಿಸಬಹುದು ಎಂಬುದು ಕಲ್ಪನೆ.

ಎಲ್ಲಾ ಏಳು ಸರ್ವರ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು, ರನ್ ಮಾಡಿ make all ಉನ್ನತ ಮಟ್ಟದ ಡೈರೆಕ್ಟರಿಯಿಂದ - ಮತ್ತು ಎಲ್ಲಾ ನಿರ್ಮಾಣಗಳು ಈ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಗೋಚರಿಸುತ್ತವೆ. ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಫೈಲ್‌ಗಳು ಸಾರ್ವಜನಿಕ ಮತ್ತು ಟೆಂಪ್ಲೇಟ್‌ಗಳ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ಅವು ಪ್ರಾರಂಭಿಸಲಾದ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಹುಡುಕುತ್ತವೆ.

Linux API

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

ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಸ್ಕೇಲೆಬಿಲಿಟಿ

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

CPU ಮತ್ತು I/O ಕಾರ್ಯಗಳು

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

ಸರ್ವರ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳ ಕುರಿತು ಇನ್ನಷ್ಟು ತಿಳಿಯಿರಿ

ಮೂಲ: www.habr.com

ಲಿನಕ್ಸ್ ನೆಟ್ವರ್ಕ್ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಕ್ಷಮತೆ. ಪರಿಚಯ