ಸಂಪರ್ಕ ಟ್ರ್ಯಾಕಿಂಗ್ ("ಕಾಂಟ್ರಾಕ್") ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಸ್ಟಾಕ್‌ನ ಪ್ರಮುಖ ಲಕ್ಷಣವಾಗಿದೆ. ಇದು ಎಲ್ಲಾ ತಾರ್ಕಿಕ ಜಾಲಬಂಧ ಸಂಪರ್ಕಗಳು ಅಥವಾ ಹರಿವುಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಕರ್ನಲ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಆ ಮೂಲಕ ಪ್ರತಿ ಹರಿವನ್ನು ರೂಪಿಸುವ ಎಲ್ಲಾ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ ಇದರಿಂದ ಅವುಗಳನ್ನು ಅನುಕ್ರಮವಾಗಿ ಒಟ್ಟಿಗೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು.
Conntrack ಕೆಲವು ಮೂಲಭೂತ ಸಂದರ್ಭಗಳಲ್ಲಿ ಬಳಸಲಾಗುವ ಪ್ರಮುಖ ಕರ್ನಲ್ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ:
- NAT ಕಾಂಟ್ರ್ಯಾಕ್‌ನಿಂದ ಮಾಹಿತಿಯನ್ನು ಅವಲಂಬಿಸಿದೆ ಆದ್ದರಿಂದ ಇದು ಒಂದೇ ಸ್ಟ್ರೀಮ್‌ನಿಂದ ಎಲ್ಲಾ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಮಾನವಾಗಿ ಪರಿಗಣಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಒಂದು ಪಾಡ್ ಕುಬರ್ನೆಟ್ಸ್ ಸೇವೆಯನ್ನು ಪ್ರವೇಶಿಸಿದಾಗ, ಕ್ಯೂಬ್-ಪ್ರಾಕ್ಸಿ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಕ್ಲಸ್ಟರ್‌ನೊಳಗೆ ನಿರ್ದಿಷ್ಟ ಪಾಡ್‌ಗೆ ಸಂಚಾರವನ್ನು ನಿರ್ದೇಶಿಸಲು NAT ಅನ್ನು ಬಳಸುತ್ತದೆ. ಕೊಟ್ಟಿರುವ ಸಂಪರ್ಕಕ್ಕಾಗಿ, IP ಸೇವೆಗೆ ಎಲ್ಲಾ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಅದೇ ಪಾಡ್‌ಗೆ ಕಳುಹಿಸಬೇಕು ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ಪಾಡ್‌ನಿಂದ ಹಿಂತಿರುಗಿಸಿದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ವಿನಂತಿಯು ಬಂದ ಪಾಡ್‌ಗೆ ಹಿಂತಿರುಗಿಸಬೇಕು ಎಂದು Conntrack ದಾಖಲಿಸುತ್ತದೆ.
- ಕ್ಯಾಲಿಕೊದಂತಹ ಸ್ಟೇಟ್‌ಫುಲ್ ಫೈರ್‌ವಾಲ್‌ಗಳು ಕನೆಕ್ಟ್‌ಟ್ರಾಕ್‌ನಿಂದ ಶ್ವೇತಪಟ್ಟಿ "ಪ್ರತಿಕ್ರಿಯೆ" ಟ್ರಾಫಿಕ್‌ಗೆ ಮಾಹಿತಿಯನ್ನು ಅವಲಂಬಿಸಿವೆ. ಪ್ರತಿಕ್ರಿಯೆ ದಟ್ಟಣೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಅನುಮತಿಸಲು ನೀತಿಯನ್ನು ಬರೆಯದೆಯೇ "ಯಾವುದೇ ರಿಮೋಟ್ IP ವಿಳಾಸಕ್ಕೆ ಸಂಪರ್ಕಿಸಲು ನನ್ನ ಪಾಡ್ ಅನ್ನು ಅನುಮತಿಸಿ" ಎಂದು ಹೇಳುವ ನೆಟ್ವರ್ಕ್ ನೀತಿಯನ್ನು ಬರೆಯಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. (ಇದೇ ಇಲ್ಲದೆ, ನೀವು ಕಡಿಮೆ ಸುರಕ್ಷಿತ "ಯಾವುದೇ ಐಪಿಯಿಂದ ನನ್ನ ಪಾಡ್‌ಗೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಅನುಮತಿಸಿ" ನಿಯಮವನ್ನು ಸೇರಿಸಬೇಕಾಗುತ್ತದೆ.)
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕಾಂಟ್ರಾಕ್ ವಿಶಿಷ್ಟವಾಗಿ ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ (ಸಿಪಿಯು ಬಳಕೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಲೇಟೆನ್ಸಿಯನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಮೂಲಕ) ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿನ ಮೊದಲ ಪ್ಯಾಕೆಟ್ ಮಾತ್ರ
ಅದರೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕೆಂದು ನಿರ್ಧರಿಸಲು ಸಂಪೂರ್ಣ ನೆಟ್ವರ್ಕ್ ಸ್ಟಾಕ್ ಮೂಲಕ ಹೋಗಬೇಕು. ಪೋಸ್ಟ್ ನೋಡಿ""ಇದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಉದಾಹರಣೆಯನ್ನು ನೋಡಲು.
ಆದಾಗ್ಯೂ, ಕಾಂಟ್ರಾಕ್ ಅದರ ಮಿತಿಗಳನ್ನು ಹೊಂದಿದೆ ...
ಹಾಗಾದರೆ ಅದೆಲ್ಲ ಎಲ್ಲಿ ತಪ್ಪಿತು?
ಕಾಂಟ್ರ್ಯಾಕ್ ಟೇಬಲ್ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದಾದ ಗರಿಷ್ಠ ಗಾತ್ರವನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಅದು ಪೂರ್ಣವಾದರೆ, ಸಂಪರ್ಕಗಳು ಸಾಮಾನ್ಯವಾಗಿ ತಿರಸ್ಕರಿಸಲು ಅಥವಾ ಕೈಬಿಡಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ. ಹೆಚ್ಚಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ದಟ್ಟಣೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಟೇಬಲ್‌ನಲ್ಲಿ ಸಾಕಷ್ಟು ಮುಕ್ತ ಸ್ಥಳವಿದೆ ಮತ್ತು ಇದು ಎಂದಿಗೂ ಸಮಸ್ಯೆಯಾಗುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಕಾಂಟ್ರಾಕ್ ಟೇಬಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಪರಿಗಣಿಸಲು ಬಯಸುವ ಕೆಲವು ಸನ್ನಿವೇಶಗಳಿವೆ:
- ನಿಮ್ಮ ಸರ್ವರ್ ಅತ್ಯಂತ ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಏಕಕಾಲದಲ್ಲಿ ಸಕ್ರಿಯ ಸಂಪರ್ಕಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಾದ ಪ್ರಕರಣವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ನಿಮ್ಮ ಕಾಂಟ್ರಾಕ್ ಟೇಬಲ್ ಅನ್ನು 128k ನಮೂದುಗಳಿಗಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದರೆ, ಆದರೆ ನೀವು >128k ಏಕಕಾಲೀನ ಸಂಪರ್ಕಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು ಖಂಡಿತವಾಗಿಯೂ ಸಮಸ್ಯೆಗೆ ಸಿಲುಕುತ್ತೀರಿ!
- ಸ್ವಲ್ಪ ಕಡಿಮೆ ಸ್ಪಷ್ಟವಾದ ಪ್ರಕರಣ: ನಿಮ್ಮ ಸರ್ವರ್ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಂಪರ್ಕಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದರೆ. ಸಂಪರ್ಕಗಳು ಅಲ್ಪಾವಧಿಯದ್ದಾಗಿದ್ದರೂ ಸಹ, ಅವುಗಳನ್ನು ಕೆಲವು ಸಮಯದವರೆಗೆ Linux ನಿಂದ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಲಾಗುತ್ತದೆ (ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ 120 ಸೆ). ಉದಾಹರಣೆಗೆ, ನಿಮ್ಮ ಕಾಂಟ್ರ್ಯಾಕ್ ಟೇಬಲ್ ಅನ್ನು 128k ನಮೂದುಗಳಿಗಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದರೆ ಮತ್ತು ನೀವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 1100 ಸಂಪರ್ಕಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದರೆ, ಸಂಪರ್ಕಗಳು ಬಹಳ ಕಡಿಮೆ ಅವಧಿಯದ್ದಾಗಿದ್ದರೂ (128k/120s = 1092 ಸಂಪರ್ಕಗಳು/ s).
ಈ ವರ್ಗಗಳಿಗೆ ಸೇರುವ ಹಲವಾರು ಸ್ಥಾಪಿತ ರೀತಿಯ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿವೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನೀವು ಬಹಳಷ್ಟು ಕೆಟ್ಟ ನಟರನ್ನು ಹೊಂದಿದ್ದರೆ, ನಿಮ್ಮ ಸರ್ವರ್‌ನ ಕಾಂಟ್ರ್ಯಾಕ್ ಟೇಬಲ್ ಅನ್ನು ಸಾಕಷ್ಟು ಅರ್ಧ-ತೆರೆದ ಸಂಪರ್ಕಗಳೊಂದಿಗೆ ಭರ್ತಿ ಮಾಡುವುದನ್ನು ಸೇವೆಯ ನಿರಾಕರಣೆ (DOS) ದಾಳಿಯ ಭಾಗವಾಗಿ ಬಳಸಬಹುದು. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಕಾಂಟ್ರ್ಯಾಕ್ ನಿಮ್ಮ ಸಿಸ್ಟಂನಲ್ಲಿ ಸೀಮಿತಗೊಳಿಸುವ ಅಡಚಣೆಯಾಗಬಹುದು. ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ಕಾಂಟ್ರ್ಯಾಕ್ ಟೇಬಲ್ ನಿಯತಾಂಕಗಳನ್ನು ಸರಿಹೊಂದಿಸುವುದು ನಿಮ್ಮ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸಲು ಸಾಕಾಗಬಹುದು - ಗಾತ್ರವನ್ನು ಹೆಚ್ಚಿಸುವ ಮೂಲಕ ಅಥವಾ ಕಾಂಟ್ರ್ಯಾಕ್ ಅವಧಿಯನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಮೂಲಕ (ಆದರೆ ನೀವು ಅದನ್ನು ತಪ್ಪಾಗಿ ಮಾಡಿದರೆ, ನೀವು ಬಹಳಷ್ಟು ತೊಂದರೆಗೆ ಸಿಲುಕುತ್ತೀರಿ). ಇತರ ಸಂದರ್ಭಗಳಲ್ಲಿ ಆಕ್ರಮಣಕಾರಿ ಸಂಚಾರಕ್ಕಾಗಿ ಕಾಂಟ್ರ್ಯಾಕ್ ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡುವುದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ.
ನಿಜವಾದ ಉದಾಹರಣೆ
ನಿರ್ದಿಷ್ಟ ಉದಾಹರಣೆಯನ್ನು ನೀಡೋಣ: ನಾವು ಕೆಲಸ ಮಾಡಿದ ಒಂದು ದೊಡ್ಡ SaaS ಪೂರೈಕೆದಾರರು ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ ಹಲವಾರು ಮೆಮ್‌ಕ್ಯಾಶ್ಡ್ ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರು (ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಲ್ಲ), ಪ್ರತಿಯೊಂದೂ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 50K+ ಅಲ್ಪಾವಧಿಯ ಸಂಪರ್ಕಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ.
ಅವರು ಕಾಂಟ್ರ್ಯಾಕ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಪ್ರಯೋಗಿಸಿದರು, ಟೇಬಲ್ ಗಾತ್ರಗಳನ್ನು ಹೆಚ್ಚಿಸಿದರು ಮತ್ತು ಟ್ರ್ಯಾಕಿಂಗ್ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಿದರು, ಆದರೆ ಕಾನ್ಫಿಗರೇಶನ್ ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ, RAM ಬಳಕೆ ಗಣನೀಯವಾಗಿ ಹೆಚ್ಚಾಯಿತು, ಇದು ಸಮಸ್ಯೆಯಾಗಿದೆ (GBytes ನ ಕ್ರಮದಲ್ಲಿ!), ಮತ್ತು ಸಂಪರ್ಕಗಳು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ. ಅದರ ಸಾಮಾನ್ಯ ಕಾರ್ಯಕ್ಷಮತೆಯ ಪ್ರಯೋಜನವನ್ನು ರಚಿಸಿ (ಕಡಿಮೆಯಾದ ಬಳಕೆ CPU ಅಥವಾ ಪ್ಯಾಕೆಟ್ ಲೇಟೆನ್ಸಿ).
ಅವರು ಪರ್ಯಾಯವಾಗಿ ಕ್ಯಾಲಿಕೊಗೆ ತಿರುಗಿದರು. ಕ್ಯಾಲಿಕೋ ನೆಟ್ವರ್ಕ್ ನೀತಿಗಳು ಕೆಲವು ರೀತಿಯ ಟ್ರಾಫಿಕ್‌ಗಾಗಿ ಕಾಂಟ್ರಾಕ್ ಅನ್ನು ಬಳಸದಿರಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ (doNotTrack ನೀತಿ ಆಯ್ಕೆಯನ್ನು ಬಳಸಿ). ಇದು ಅವರಿಗೆ ಅಗತ್ಯವಿರುವ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮಟ್ಟವನ್ನು ನೀಡಿತು, ಜೊತೆಗೆ ಕ್ಯಾಲಿಕೊ ಒದಗಿಸಿದ ಭದ್ರತೆಯ ಹೆಚ್ಚುವರಿ ಮಟ್ಟವನ್ನು ನೀಡಿತು.
ಕಾಂಟ್ರ್ಯಾಕ್ ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡಲು ನೀವು ಯಾವ ಉದ್ದಗಳಿಗೆ ಹೋಗಬೇಕು?
- ಟ್ರ್ಯಾಕ್ ಮಾಡಬೇಡಿ-ನೆಟ್ವರ್ಕ್ ನೀತಿಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಸಮ್ಮಿತೀಯವಾಗಿರಬೇಕು. SaaS ಪೂರೈಕೆದಾರರ ಸಂದರ್ಭದಲ್ಲಿ: ಅವರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸಂರಕ್ಷಿತ ವಲಯದೊಳಗೆ ಓಡುತ್ತವೆ ಮತ್ತು ಆದ್ದರಿಂದ, ನೆಟ್ವರ್ಕ್ ನೀತಿಯನ್ನು ಬಳಸಿಕೊಂಡು, ಅವರು memcached ಗೆ ಪ್ರವೇಶವನ್ನು ಅನುಮತಿಸಿದ ಇತರ ನಿರ್ದಿಷ್ಟ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಂದ ದಟ್ಟಣೆಯನ್ನು ಶ್ವೇತಪಟ್ಟಿ ಮಾಡಬಹುದು.
- ಡು-ನಾಟ್-ಟ್ರ್ಯಾಕ್ ನೀತಿಯು ಸಂಪರ್ಕದ ದಿಕ್ಕನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ. ಹೀಗಾಗಿ, memcached ಸರ್ವರ್ ಹ್ಯಾಕ್ ಆಗಿದ್ದರೆ, ನೀವು ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಯಾವುದೇ memcached ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಿಸಲು ಪ್ರಯತ್ನಿಸಬಹುದು, ಅದು ಸರಿಯಾದ ಮೂಲ ಪೋರ್ಟ್ ಅನ್ನು ಬಳಸುವವರೆಗೆ. ಆದಾಗ್ಯೂ, ನಿಮ್ಮ memcached ಕ್ಲೈಂಟ್‌ಗಳಿಗಾಗಿ ನೀವು ನೆಟ್ವರ್ಕ್ ನೀತಿಯನ್ನು ಸರಿಯಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಿದ್ದರೆ, ನಂತರ ಈ ಸಂಪರ್ಕದ ಪ್ರಯತ್ನಗಳನ್ನು ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ ಇನ್ನೂ ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ.
- ಡೋ-ನಾಟ್-ಟ್ರ್ಯಾಕ್ ನೀತಿಯನ್ನು ಪ್ರತಿ ಪ್ಯಾಕೆಟ್‌ಗೆ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ, ಸಾಮಾನ್ಯ ನೀತಿಗಳಿಗೆ ವಿರುದ್ಧವಾಗಿ, ಇದು ಹರಿವಿನಲ್ಲಿ ಮೊದಲ ಪ್ಯಾಕೆಟ್‌ಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆ. ಇದು ಪ್ರತಿ ಪ್ಯಾಕೆಟ್‌ಗೆ CPU ಬಳಕೆಯನ್ನು ಹೆಚ್ಚಿಸಬಹುದು ಏಕೆಂದರೆ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್‌ಗೆ ನೀತಿಯನ್ನು ಅನ್ವಯಿಸಬೇಕು. ಆದರೆ ಅಲ್ಪಾವಧಿಯ ಸಂಪರ್ಕಗಳಿಗೆ, ಕಾಂಟ್ರಾಕ್ ಪ್ರಕ್ರಿಯೆಗೆ ಸಂಪನ್ಮೂಲ ಬಳಕೆಯಲ್ಲಿನ ಕಡಿತದಿಂದ ಈ ವೆಚ್ಚವನ್ನು ಸಮತೋಲನಗೊಳಿಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, SaaS ಪೂರೈಕೆದಾರರ ಸಂದರ್ಭದಲ್ಲಿ, ಪ್ರತಿ ಸಂಪರ್ಕಕ್ಕಾಗಿ ಪ್ಯಾಕೆಟ್‌ಗಳ ಸಂಖ್ಯೆಯು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್‌ಗೆ ನೀತಿಗಳನ್ನು ಅನ್ವಯಿಸುವಾಗ ಹೆಚ್ಚುವರಿ CPU ಬಳಕೆಯನ್ನು ಸಮರ್ಥಿಸಲಾಗುತ್ತದೆ.
ಪರೀಕ್ಷೆಯನ್ನು ಪ್ರಾರಂಭಿಸೋಣ
ನಾವು ಮೆಮ್‌ಕ್ಯಾಶ್ಡ್ ಸರ್ವರ್ ಮತ್ತು ರಿಮೋಟ್ ನೋಡ್‌ಗಳಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಬಹು ಮೆಮ್‌ಕ್ಯಾಶ್ಡ್ ಕ್ಲೈಂಟ್ ಪಾಡ್‌ಗಳೊಂದಿಗೆ ಒಂದೇ ಪಾಡ್‌ನಲ್ಲಿ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಿದ್ದೇವೆ ಇದರಿಂದ ನಾವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಂಪರ್ಕಗಳನ್ನು ಚಲಾಯಿಸಬಹುದು. ಮೆಮ್‌ಕ್ಯಾಶ್ಡ್ ಸರ್ವರ್ ಪಾಡ್‌ನೊಂದಿಗಿನ ಸರ್ವರ್ ಕಾಂಟ್ರಾಕ್ ಟೇಬಲ್‌ನಲ್ಲಿ 8 ಕೋರ್‌ಗಳು ಮತ್ತು 512k ನಮೂದುಗಳನ್ನು ಹೊಂದಿತ್ತು (ಹೋಸ್ಟ್‌ಗಾಗಿ ಪ್ರಮಾಣಿತ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಟೇಬಲ್ ಗಾತ್ರ).
ನಾವು ಇವುಗಳ ನಡುವಿನ ಕಾರ್ಯಕ್ಷಮತೆಯ ವ್ಯತ್ಯಾಸವನ್ನು ಅಳೆಯುತ್ತೇವೆ: ನೆಟ್ವರ್ಕ್ ನೀತಿ ಇಲ್ಲ; ನಿಯಮಿತ ಕ್ಯಾಲಿಕೊ ನೀತಿಯೊಂದಿಗೆ; ಮತ್ತು ಕ್ಯಾಲಿಕೋ ಡೋ-ನಾಟ್-ಟ್ರ್ಯಾಕ್ ನೀತಿ.
ಮೊದಲ ಪರೀಕ್ಷೆಗಾಗಿ, ನಾವು ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸೆಕೆಂಡಿಗೆ 4.000 ಗೆ ಹೊಂದಿಸಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ನಾವು CPU ಬಳಕೆಯ ವ್ಯತ್ಯಾಸದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಬಹುದು. ಯಾವುದೇ ನೀತಿ ಮತ್ತು ನಿಯಮಿತ ನೀತಿಯ ನಡುವೆ ಯಾವುದೇ ಗಮನಾರ್ಹ ವ್ಯತ್ಯಾಸಗಳಿಲ್ಲ, ಆದರೆ ಸುಮಾರು 20% ರಷ್ಟು ಹೆಚ್ಚಿದ CPU ಬಳಕೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬೇಡಿ:
ಎರಡನೇ ಪರೀಕ್ಷೆಯಲ್ಲಿ, ನಮ್ಮ ಕ್ಲೈಂಟ್‌ಗಳು ಉತ್ಪಾದಿಸಬಹುದಾದಷ್ಟು ಸಂಪರ್ಕಗಳನ್ನು ನಾವು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು ನಮ್ಮ ಮೆಮ್‌ಕ್ಯಾಶ್ಡ್ ಸರ್ವರ್ ನಿಭಾಯಿಸಬಲ್ಲ ಸೆಕೆಂಡಿಗೆ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಸಂಪರ್ಕಗಳನ್ನು ಅಳೆಯುತ್ತೇವೆ. ನಿರೀಕ್ಷೆಯಂತೆ, "ಯಾವುದೇ ನೀತಿ" ಮತ್ತು "ನಿಯಮಿತ ನೀತಿ" ಪ್ರಕರಣಗಳು ಸೆಕೆಂಡಿಗೆ 4,000 ಸಂಪರ್ಕಗಳ ಸಂಪರ್ಕ ಮಿತಿಯನ್ನು ತಲುಪಿವೆ (512k / 120s = 4,369 ಸಂಪರ್ಕಗಳು/s). ಟ್ರ್ಯಾಕ್ ಮಾಡದಿರುವ ನೀತಿಯೊಂದಿಗೆ, ನಮ್ಮ ಗ್ರಾಹಕರು ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 60,000 ಸಂಪರ್ಕಗಳನ್ನು ಕಳುಹಿಸಿದ್ದಾರೆ. ಹೆಚ್ಚಿನ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ನಾವು ಈ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಬಹುದು ಎಂದು ನಮಗೆ ಖಚಿತವಾಗಿದೆ, ಆದರೆ ಈ ಲೇಖನದ ಅಂಶವನ್ನು ವಿವರಿಸಲು ಈ ಸಂಖ್ಯೆಗಳು ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ!
ತೀರ್ಮಾನಕ್ಕೆ
ಕಾಂಟ್ರಾಕ್ ಒಂದು ಪ್ರಮುಖ ಕರ್ನಲ್ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ. ಅವನು ತನ್ನ ಕೆಲಸವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮಾಡುತ್ತಾನೆ. ಇದನ್ನು ಪ್ರಮುಖ ಸಿಸ್ಟಮ್ ಘಟಕಗಳಿಂದ ಹೆಚ್ಚಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಕೆಲವು ನಿರ್ದಿಷ್ಟ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ, ಕಾಂಟ್ರಾಕ್‌ನಿಂದ ಉಂಟಾಗುವ ದಟ್ಟಣೆಯು ಅದು ಒದಗಿಸುವ ಸಾಮಾನ್ಯ ಪ್ರಯೋಜನಗಳನ್ನು ಮೀರಿಸುತ್ತದೆ. ಈ ಸನ್ನಿವೇಶದಲ್ಲಿ, ಕ್ಯಾಲಿಕೋ ನೆಟ್ವರ್ಕ್ ನೀತಿಗಳನ್ನು ನೆಟ್ವರ್ಕ್ ಭದ್ರತೆಯನ್ನು ಹೆಚ್ಚಿಸುವಾಗ ಕಾಂಟ್ರಾಕ್ ಬಳಕೆಯನ್ನು ಆಯ್ದವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ಬಳಸಬಹುದು. ಎಲ್ಲಾ ಇತರ ಟ್ರಾಫಿಕ್‌ಗಾಗಿ, ಕಾಂಟ್ರಾಕ್ ನಿಮ್ಮ ಸ್ನೇಹಿತರಾಗಿ ಮುಂದುವರಿಯುತ್ತದೆ!
ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿ ಇತರ ಲೇಖನಗಳನ್ನು ಸಹ ಓದಿ:
ಮೂಲ: www.habr.com