ವೇಗದ ಬ್ರೌಸಿಂಗ್ಗೆ ಕಡಿಮೆ DNS ಲೇಟೆನ್ಸಿ ಒಂದು ಪ್ರಮುಖ ಅಂಶವಾಗಿದೆ. ಅದನ್ನು ಕಡಿಮೆ ಮಾಡಲು, DNS ಸರ್ವರ್ಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಆಯ್ಕೆ ಮಾಡುವುದು ಮುಖ್ಯ ಮತ್ತು ಆದರೆ ನೀವು ಮೊದಲು ಮಾಡಬೇಕಾಗಿರುವುದು ಅನುಪಯುಕ್ತ ಪ್ರಶ್ನೆಗಳನ್ನು ತೊಡೆದುಹಾಕುವುದು.
ಇದಕ್ಕಾಗಿಯೇ DNS ಅನ್ನು ಮೂಲತಃ ಹೆಚ್ಚು ಕ್ಯಾಶೆ ಮಾಡಬಹುದಾದ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿತ್ತು. ವಲಯ ನಿರ್ವಾಹಕರು ವೈಯಕ್ತಿಕ ದಾಖಲೆಗಳಿಗೆ ಬದುಕಲು ಸಮಯ (TTL) ಅನ್ನು ನಿಗದಿಪಡಿಸುತ್ತಾರೆ ಮತ್ತು ಅನಗತ್ಯ ದಟ್ಟಣೆಯನ್ನು ತಪ್ಪಿಸಲು ಮೆಮೊರಿಯಲ್ಲಿ ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುವಾಗ ಪರಿಹಾರಕರು ಈ ಮಾಹಿತಿಯನ್ನು ಬಳಸುತ್ತಾರೆ.
ಕ್ಯಾಶಿಂಗ್ ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆಯೇ? ಒಂದೆರಡು ವರ್ಷಗಳ ಹಿಂದೆ, ನನ್ನ ಸಣ್ಣ ಸಂಶೋಧನೆಯು ಅದು ಪರಿಪೂರ್ಣವಲ್ಲ ಎಂದು ತೋರಿಸಿದೆ. ಪ್ರಸ್ತುತ ವ್ಯವಹಾರಗಳ ಸ್ಥಿತಿಯನ್ನು ನೋಡೋಣ.
ನಾನು ಪ್ಯಾಚ್ ಮಾಡಿದ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ TTL ಮೌಲ್ಯವನ್ನು ಸಂಗ್ರಹಿಸಲು. ಪ್ರತಿ ಒಳಬರುವ ವಿನಂತಿಗೆ ಅದರ ದಾಖಲೆಗಳ ಕನಿಷ್ಠ TTL ಎಂದು ಇದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ. ಇದು ನೈಜ ದಟ್ಟಣೆಯ TTL ವಿತರಣೆಯ ಉತ್ತಮ ಅವಲೋಕನವನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ವೈಯಕ್ತಿಕ ವಿನಂತಿಗಳ ಜನಪ್ರಿಯತೆಯನ್ನು ಸಹ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಸರ್ವರ್ನ ಪ್ಯಾಚ್ ಮಾಡಿದ ಆವೃತ್ತಿಯು ಹಲವಾರು ಗಂಟೆಗಳ ಕಾಲ ಕಾರ್ಯನಿರ್ವಹಿಸಿತು.
ಫಲಿತಾಂಶದ ಡೇಟಾಸೆಟ್ 1 ದಾಖಲೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ (ಹೆಸರು, qtype, TTL, ಸಮಯಮುದ್ರೆ). ಒಟ್ಟಾರೆ TTL ವಿತರಣೆ ಇಲ್ಲಿದೆ (x-ಅಕ್ಷವು ಸೆಕೆಂಡುಗಳಲ್ಲಿ TTL ಆಗಿದೆ):
86 ರಷ್ಟು ಸ್ವಲ್ಪ ಏರಿಕೆ (ಹೆಚ್ಚಾಗಿ SOA ದಾಖಲೆಗಳಿಗೆ) ಹೊರತುಪಡಿಸಿ, TTL ಗಳು ಕಡಿಮೆ ವ್ಯಾಪ್ತಿಯಲ್ಲಿವೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಹತ್ತಿರದಿಂದ ನೋಡೋಣ:
ಸರಿ, 1 ಗಂಟೆಗಿಂತ ಹೆಚ್ಚಿನ ಅವಧಿಯ TTL ಗಳು ಸಂಖ್ಯಾಶಾಸ್ತ್ರೀಯವಾಗಿ ಅತ್ಯಲ್ಪ. ಹಾಗಾದರೆ 0-3600 ಶ್ರೇಣಿಯ ಮೇಲೆ ಗಮನ ಹರಿಸೋಣ:
ಹೆಚ್ಚಿನ ಟಿಟಿಎಲ್ಗಳು 0 ರಿಂದ 15 ನಿಮಿಷಗಳ ನಡುವೆ ಇರುತ್ತವೆ:
ಬಹುಪಾಲು 0 ರಿಂದ 5 ನಿಮಿಷಗಳವರೆಗೆ ಇರುತ್ತದೆ:
ಇದು ಅಷ್ಟು ಒಳ್ಳೆಯದಲ್ಲ.
ಸಂಚಿತ ವಿತರಣೆಯು ಸಮಸ್ಯೆಯನ್ನು ಇನ್ನಷ್ಟು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ:
ಅರ್ಧದಷ್ಟು DNS ಪ್ರತಿಕ್ರಿಯೆಗಳು 1 ನಿಮಿಷ ಅಥವಾ ಅದಕ್ಕಿಂತ ಕಡಿಮೆ TTL ಅನ್ನು ಹೊಂದಿರುತ್ತವೆ ಮತ್ತು ಮುಕ್ಕಾಲು ಭಾಗವು 5 ನಿಮಿಷ ಅಥವಾ ಅದಕ್ಕಿಂತ ಕಡಿಮೆ TTL ಅನ್ನು ಹೊಂದಿರುತ್ತವೆ.
ಆದರೆ ನಿರೀಕ್ಷಿಸಿ, ಇದು ವಾಸ್ತವವಾಗಿ ಕೆಟ್ಟದಾಗಿದೆ. ಇದು ಅಧಿಕೃತ ಸರ್ವರ್ಗಳಿಂದ ಬರುವ TTL ಆಗಿದೆ. ಆದಾಗ್ಯೂ, ಕ್ಲೈಂಟ್ ಪರಿಹಾರಕಗಳು (ಉದಾ. ರೂಟರ್ಗಳು, ಸ್ಥಳೀಯ ಕ್ಯಾಶ್ಗಳು) ಅಪ್ಸ್ಟ್ರೀಮ್ ಪರಿಹಾರಕಗಳಿಂದ TTL ಅನ್ನು ಪಡೆಯುತ್ತವೆ ಮತ್ತು ಅದು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ.
ಹೀಗಾಗಿ, ಕ್ಲೈಂಟ್ ಹೊಸ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು ಪ್ರತಿ ದಾಖಲೆಯನ್ನು ಸರಾಸರಿ ಅರ್ಧದಷ್ಟು ಮೂಲ TTL ಗೆ ಬಳಸಬಹುದು.
ಬಹುಶಃ ಈ ಅತ್ಯಂತ ಕಡಿಮೆ TTLಗಳು ಜನಪ್ರಿಯ ವೆಬ್ಸೈಟ್ಗಳು ಮತ್ತು API ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲವೇ ಹೊರತು ಅಸಾಮಾನ್ಯ ವಿನಂತಿಗಳ ಮೇಲೆ ಮಾತ್ರ ಪರಿಣಾಮ ಬೀರುತ್ತವೆಯೇ? ನೋಡೋಣ:
X-ಅಕ್ಷವು TTL ಆಗಿದೆ, Y-ಅಕ್ಷವು ಪ್ರಶ್ನೆ ಜನಪ್ರಿಯತೆಯಾಗಿದೆ.
ದುರದೃಷ್ಟವಶಾತ್, ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಪ್ರಶ್ನೆಗಳು ಅತ್ಯಂತ ಕೆಟ್ಟದಾಗಿ ಸಂಗ್ರಹಗೊಂಡಿವೆ.
ಜೂಮ್ ಇನ್ ಮಾಡೋಣ:
ತೀರ್ಪು: ಇದು ನಿಜವಾಗಿಯೂ ಕೆಟ್ಟದಾಗಿದೆ. ಇದು ಈಗಾಗಲೇ ಕೆಟ್ಟದಾಗಿತ್ತು ಮತ್ತು ಅದು ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿದೆ. DNS ಕ್ಯಾಶಿಂಗ್ ವಾಸ್ತವಿಕವಾಗಿ ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿದೆ. ಕಡಿಮೆ ಜನರು ತಮ್ಮ ISP ಯ DNS ಪರಿಹಾರಕವನ್ನು ಬಳಸುವುದರಿಂದ (ಒಳ್ಳೆಯ ಕಾರಣಗಳಿಗಾಗಿ), ವಿಳಂಬದಲ್ಲಿನ ಹೆಚ್ಚಳವು ಹೆಚ್ಚು ಗಮನಾರ್ಹವಾಗುತ್ತಿದೆ.
ಯಾರೂ ಭೇಟಿ ನೀಡದ ವಿಷಯಗಳಿಗೆ ಮಾತ್ರ DNS ಕ್ಯಾಶಿಂಗ್ ಉಪಯುಕ್ತವಾಗಿದೆ.
ದಯವಿಟ್ಟು ಗಮನಿಸಿ, ಸಾಫ್ಟ್ವೇರ್ ಕಡಿಮೆ ಟಿಟಿಎಲ್ಗಳನ್ನು ಅರ್ಥೈಸಿಕೊಳ್ಳಿ.
ಅದು ಯಾಕೆ?
DNS ದಾಖಲೆಗಳನ್ನು ಇಷ್ಟು ಚಿಕ್ಕ TTL ಗೆ ಏಕೆ ಹೊಂದಿಸಲಾಗಿದೆ?
- ಲೆಗಸಿ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ಗಳು ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್ಗಳೊಂದಿಗೆ ಉಳಿದಿವೆ.
- DNS ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ TTL ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ ಎಂಬ ಪುರಾಣಗಳಿವೆ (ಇದು ನಿಜವಲ್ಲ - ನೆಟ್ಸ್ಕೇಪ್ ನ್ಯಾವಿಗೇಟರ್ನಿಂದ, ಕ್ಲೈಂಟ್ಗಳು RR ಸೆಟ್ನಿಂದ ಯಾದೃಚ್ಛಿಕ IP ವಿಳಾಸವನ್ನು ಆರಿಸಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಸಂಪರ್ಕಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ಪಾರದರ್ಶಕವಾಗಿ ಇನ್ನೊಂದನ್ನು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ)
- ನಿರ್ವಾಹಕರು ಬದಲಾವಣೆಗಳನ್ನು ತಕ್ಷಣವೇ ಅನ್ವಯಿಸಲು ಬಯಸುತ್ತಾರೆ, ಆದ್ದರಿಂದ ಯೋಜಿಸುವುದು ಸುಲಭ.
- DNS ಸರ್ವರ್ ಅಥವಾ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ನ ನಿರ್ವಾಹಕರು ತಮ್ಮ ಕೆಲಸವನ್ನು ಬಳಕೆದಾರರು ವಿನಂತಿಸಿದ ಸಂರಚನೆಯನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಿಯೋಜಿಸುವುದಾಗಿ ನೋಡುತ್ತಾರೆ, ಮತ್ತು ಸೈಟ್ಗಳು ಮತ್ತು ಸೇವೆಗಳ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ವೇಗಗೊಳಿಸುವುದಲ್ಲ.
- ಕಡಿಮೆ ಟಿಟಿಎಲ್ ಮನಸ್ಸಿಗೆ ಶಾಂತಿ ನೀಡುತ್ತದೆ.
- ಜನರು ಆರಂಭದಲ್ಲಿ ಪರೀಕ್ಷೆಗೆ ಕಡಿಮೆ ಟಿಟಿಎಲ್ಗಳನ್ನು ಹೊಂದಿಸುತ್ತಾರೆ ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಬದಲಾಯಿಸಲು ಮರೆತುಬಿಡುತ್ತಾರೆ.
"ಫೇಲ್ಓವರ್" ಅನ್ನು ನಾನು ಸೇರಿಸಲಿಲ್ಲ ಏಕೆಂದರೆ ಅದು ಕಡಿಮೆ ಮತ್ತು ಕಡಿಮೆ ಪ್ರಸ್ತುತವಾಗುತ್ತಿದೆ. ಉಳಿದೆಲ್ಲವೂ ಸಂಪೂರ್ಣವಾಗಿ ಮುರಿದುಹೋದಾಗ ದೋಷ ಪುಟವನ್ನು ಪ್ರದರ್ಶಿಸಲು ನೀವು ಬಳಕೆದಾರರನ್ನು ಬೇರೆ ನೆಟ್ವರ್ಕ್ಗೆ ಮರುನಿರ್ದೇಶಿಸಬೇಕಾದರೆ, 1 ನಿಮಿಷಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ವಿಳಂಬವು ಬಹುಶಃ ಸ್ವೀಕಾರಾರ್ಹವಾಗಿರುತ್ತದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಒಂದು ನಿಮಿಷದ TTL ಎಂದರೆ ಅಧಿಕೃತ DNS ಸರ್ವರ್ಗಳನ್ನು 1 ನಿಮಿಷಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ನಿರ್ಬಂಧಿಸಿದರೆ, ಬೇರೆ ಯಾರೂ ಅವಲಂಬಿತ ಸೇವೆಗಳನ್ನು ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಮತ್ತು ಕಾರಣವು ಸಂರಚನಾ ದೋಷ ಅಥವಾ ಹ್ಯಾಕ್ ಆಗಿದ್ದರೆ ಪುನರುಕ್ತಿ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ಮತ್ತೊಂದೆಡೆ, ಸಮಂಜಸವಾದ TTL ಗಳೊಂದಿಗೆ, ಅನೇಕ ಕ್ಲೈಂಟ್ಗಳು ಹಿಂದಿನ ಸಂರಚನೆಯನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾರೆ ಮತ್ತು ಎಂದಿಗೂ ಗಮನಿಸುವುದಿಲ್ಲ.
ಕಡಿಮೆ TTL ಗಳು ಹೆಚ್ಚಾಗಿ CDN ಸೇವೆಗಳು ಮತ್ತು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ಗಳ ದೋಷವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ಅವು CNAME ಗಳನ್ನು ಕಡಿಮೆ TTL ಗಳೊಂದಿಗೆ ಮತ್ತು ದಾಖಲೆಗಳನ್ನು ಅಷ್ಟೇ ಕಡಿಮೆ (ಆದರೆ ಸ್ವತಂತ್ರ) TTL ಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಿದಾಗ:
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
ಪ್ರತಿ ಬಾರಿ CNAME ಅಥವಾ ಯಾವುದೇ A ದಾಖಲೆಗಳ ಅವಧಿ ಮುಗಿದಾಗ, ಹೊಸ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಬೇಕಾಗುತ್ತದೆ. ಎರಡೂ 30 ಸೆಕೆಂಡುಗಳ TTL ಅನ್ನು ಹೊಂದಿರುತ್ತವೆ, ಆದರೆ ಅವು ಒಂದೇ ಆಗಿರುವುದಿಲ್ಲ. ನಿಜವಾದ ಸರಾಸರಿ TTL 15 ಸೆಕೆಂಡುಗಳಾಗಿರುತ್ತದೆ.
ಆದರೆ ಸ್ವಲ್ಪ ನಿರೀಕ್ಷಿಸಿ! ಇದು ಇನ್ನಷ್ಟು ಕೆಟ್ಟದಾಗುತ್ತದೆ. ಎರಡು ಲಿಂಕ್ ಮಾಡಲಾದ ಕಡಿಮೆ TTL ಗಳೊಂದಿಗೆ ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಕೆಲವು ಪರಿಹಾರಕಗಳು ತುಂಬಾ ಕೆಟ್ಟದಾಗಿ ವರ್ತಿಸುತ್ತವೆ:
$ ಡ್ರಿಲ್ raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Level3 ಪರಿಹಾರಕವು ಬಹುಶಃ BIND ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರಬಹುದು. ನೀವು ಈ ಪ್ರಶ್ನೆಯನ್ನು ಕಳುಹಿಸುತ್ತಲೇ ಇದ್ದರೆ, ಅದು ಯಾವಾಗಲೂ 1 ರ TTL ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಮೂಲಭೂತವಾಗಿ, raw.githubusercontent.com ಎಂದಿಗೂ ಸಂಗ್ರಹಿಸಲಾಗಿಲ್ಲ.
ಬಹಳ ಜನಪ್ರಿಯ ಡೊಮೇನ್ನೊಂದಿಗೆ ಈ ಪರಿಸ್ಥಿತಿಯ ಇನ್ನೊಂದು ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
ಕನಿಷ್ಠ ಮೂರು CNAME ದಾಖಲೆಗಳು. ಓಹ್. ಒಂದರಲ್ಲಿ ಉತ್ತಮ TTL ಇದೆ, ಆದರೆ ಅದು ಸಂಪೂರ್ಣವಾಗಿ ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿದೆ. ಇತರ CNAME ಗಳು 60 ಸೆಕೆಂಡುಗಳ ಆರಂಭಿಕ TTL ಅನ್ನು ಹೊಂದಿವೆ, ಆದರೆ ಡೊಮೇನ್ಗಳಿಗೆ akamai.net ಗರಿಷ್ಠ ಟಿಟಿಎಲ್ 20 ಸೆಕೆಂಡುಗಳು ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಹಂತದಲ್ಲಿಲ್ಲ.
ಆಪಲ್ ಸಾಧನಗಳನ್ನು ನಿರಂತರವಾಗಿ ಸಮೀಕ್ಷೆ ಮಾಡುವ ಡೊಮೇನ್ಗಳ ಬಗ್ಗೆ ಏನು?
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
Level1 ರೆಸಲ್ವರ್ ಬಳಸುವಾಗ Firefox ಮತ್ತು TTL ನಂತಹ ಸಮಸ್ಯೆಯು ಹೆಚ್ಚಿನ ಸಮಯ 3 ಸೆಕೆಂಡ್ನಲ್ಲಿ ಸಿಕ್ಕಿಹಾಕಿಕೊಳ್ಳುತ್ತದೆ.
ಡ್ರಾಪ್ಬಾಕ್ಸ್?
$ ಡ್ರಿಲ್ client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ ಡ್ರಿಲ್ client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
ರೆಕಾರ್ಡಿಂಗ್ನಲ್ಲಿ safebrowsing.googleapis.com ಫೇಸ್ಬುಕ್ ಡೊಮೇನ್ಗಳಂತೆಯೇ 60 ಸೆಕೆಂಡುಗಳ ಟಿಟಿಎಲ್ ಮೌಲ್ಯ. ಮತ್ತು ಮತ್ತೊಮ್ಮೆ, ಕ್ಲೈಂಟ್ನ ದೃಷ್ಟಿಕೋನದಿಂದ, ಈ ಮೌಲ್ಯಗಳನ್ನು ಅರ್ಧಕ್ಕೆ ಇಳಿಸಲಾಗಿದೆ.
ಕನಿಷ್ಠ ಟಿಟಿಎಲ್ ಅನ್ನು ಹೊಂದಿಸುವುದು ಹೇಗೆ?
ಹೆಸರು, ವಿನಂತಿ ಪ್ರಕಾರ, TTL ಮತ್ತು ಮೂಲತಃ ಸಂಗ್ರಹಿಸಲಾದ ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು, ಅವಧಿ ಮೀರಿದ ಕ್ಯಾಶ್ ನಮೂದು ಕಾರಣ ಕಳುಹಿಸಲಾದ ಹೆಚ್ಚುವರಿ ವಿನಂತಿಗಳ ಪ್ರಮಾಣವನ್ನು ಅಂದಾಜು ಮಾಡಲು ಕ್ಯಾಶಿಂಗ್ ರೆಸಲ್ವರ್ ಮೂಲಕ ಹೋಗುವ 1,5 ಮಿಲಿಯನ್ ವಿನಂತಿಗಳನ್ನು ಅನುಕರಿಸಲು ನಾನು ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬರೆದಿದ್ದೇನೆ.
ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ದಾಖಲೆಯ ಅವಧಿ ಮುಗಿದ ನಂತರ 47,4% ವಿನಂತಿಗಳನ್ನು ಮಾಡಲಾಗಿದೆ. ಇದು ಅಸಮಂಜಸವಾಗಿ ಹೆಚ್ಚಾಗಿದೆ.
ಕನಿಷ್ಠ ಟಿಟಿಎಲ್ ಅನ್ನು ಹೊಂದಿಸಿದರೆ ಕ್ಯಾಶಿಂಗ್ ಮೇಲೆ ಏನು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ?
X-ಅಕ್ಷವು ಕನಿಷ್ಠ TTL ಮೌಲ್ಯಗಳಾಗಿವೆ. ಈ ಮೌಲ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಕಚ್ಚಾ TTL ಗಳನ್ನು ಹೊಂದಿರುವ ದಾಖಲೆಗಳು ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.
Y ಅಕ್ಷವು ಈಗಾಗಲೇ ಕ್ಯಾಶ್ ಮಾಡಲಾದ ನಮೂದನ್ನು ಹೊಂದಿರುವ ಆದರೆ ಅವಧಿ ಮುಗಿದು ಹೊಸ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತಿರುವ ಕ್ಲೈಂಟ್ನಿಂದ ವಿನಂತಿಗಳ ಶೇಕಡಾವಾರು ಪ್ರಮಾಣವಾಗಿದೆ.
ಕನಿಷ್ಠ TTL ಅನ್ನು 47 ನಿಮಿಷಗಳಿಗೆ ಹೊಂದಿಸುವ ಮೂಲಕ "ಹೆಚ್ಚುವರಿ" ವಿನಂತಿಗಳ ಪಾಲನ್ನು 36% ರಿಂದ 5% ಕ್ಕೆ ಇಳಿಸಲಾಗುತ್ತದೆ. ಕನಿಷ್ಠ TTL ಅನ್ನು 15 ನಿಮಿಷಗಳಿಗೆ ಹೊಂದಿಸುವುದರಿಂದ ಈ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ 29% ಕ್ಕೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ. 1 ಗಂಟೆಯ ಕನಿಷ್ಠ TTL ಅವುಗಳನ್ನು 17% ಕ್ಕೆ ಇಳಿಸುತ್ತದೆ. ಗಮನಾರ್ಹ ವ್ಯತ್ಯಾಸ!
ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಏನನ್ನೂ ಬದಲಾಯಿಸದೆ, ಕ್ಲೈಂಟ್ DNS ಕ್ಯಾಶ್ಗಳಲ್ಲಿ (ರೂಟರ್ಗಳು, ಸ್ಥಳೀಯ ಪರಿಹಾರಕಗಳು) ಕನಿಷ್ಠ TTL ಗಳನ್ನು ಹೊಂದಿಸುವುದರ ಬಗ್ಗೆ ಹೇಗೆ?
ಕನಿಷ್ಠ TTL ಅನ್ನು 47 ನಿಮಿಷಗಳಿಗೆ ಹೊಂದಿಸಿದಾಗ ಅಗತ್ಯವಿರುವ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ 34% ರಿಂದ 5% ಕ್ಕೆ ಇಳಿಯುತ್ತದೆ, ಕನಿಷ್ಠ 25 ನಿಮಿಷಗಳೊಂದಿಗೆ 15% ಕ್ಕೆ ಮತ್ತು ಕನಿಷ್ಠ 13 ಗಂಟೆಯೊಂದಿಗೆ 1% ಕ್ಕೆ ಇಳಿಯುತ್ತದೆ. ಬಹುಶಃ 40 ನಿಮಿಷಗಳು ಸೂಕ್ತವಾಗಿರುತ್ತದೆ.
ಈ ಕನಿಷ್ಠ ಬದಲಾವಣೆಯ ಪರಿಣಾಮವು ಅಗಾಧವಾಗಿದೆ.
ಪರಿಣಾಮಗಳೇನು?
ಖಂಡಿತ, ನೀವು ಸೇವೆಯನ್ನು ಹೊಸ ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರ, ಹೊಸ ಸರ್ವರ್, ಹೊಸ ನೆಟ್ವರ್ಕ್ಗೆ ಸ್ಥಳಾಂತರಿಸಬಹುದು ಮತ್ತು ಗ್ರಾಹಕರು ಇತ್ತೀಚಿನ DNS ದಾಖಲೆಗಳನ್ನು ಬಳಸುವಂತೆ ಒತ್ತಾಯಿಸಬಹುದು. ಮತ್ತು ಸಾಕಷ್ಟು ಸಣ್ಣ TTL ಆ ಪರಿವರ್ತನೆಯನ್ನು ಸುಗಮ ಮತ್ತು ತಡೆರಹಿತವಾಗಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಆದರೆ ನೀವು ಹೊಸ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ವಲಸೆ ಹೋದಾಗ, ಗ್ರಾಹಕರು 1 ನಿಮಿಷ, 5 ನಿಮಿಷ ಅಥವಾ 15 ನಿಮಿಷಗಳಲ್ಲಿ ಹೊಸ DNS ದಾಖಲೆಗಳಿಗೆ ವಲಸೆ ಹೋಗುತ್ತಾರೆ ಎಂದು ಯಾರೂ ನಿರೀಕ್ಷಿಸುವುದಿಲ್ಲ. ಕನಿಷ್ಠ TTL ಅನ್ನು 40 ನಿಮಿಷಗಳ ಬದಲಿಗೆ 5 ನಿಮಿಷಗಳಿಗೆ ಹೊಂದಿಸುವುದರಿಂದ ಬಳಕೆದಾರರು ಸೇವೆಯನ್ನು ಪ್ರವೇಶಿಸುವುದನ್ನು ತಡೆಯುವುದಿಲ್ಲ.
ಆದಾಗ್ಯೂ, ಇದು ಅನಗತ್ಯ ವಿನಂತಿಗಳನ್ನು ತಪ್ಪಿಸುವ ಮೂಲಕ ವಿಳಂಬವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಗೌಪ್ಯತೆ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ.
ಖಂಡಿತ, RFC ಗಳು TTL ಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಜಾರಿಗೊಳಿಸಬೇಕೆಂದು ಹೇಳುತ್ತವೆ. ಆದರೆ ವಾಸ್ತವವೆಂದರೆ DNS ವ್ಯವಸ್ಥೆಯು ತುಂಬಾ ನಿಷ್ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ.
ನೀವು ಅಧಿಕೃತ DNS ಸರ್ವರ್ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ದಯವಿಟ್ಟು ನಿಮ್ಮ TTL ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ನಿಮಗೆ ನಿಜವಾಗಿಯೂ ಅಂತಹ ಹಾಸ್ಯಾಸ್ಪದ ಕಡಿಮೆ ಮೌಲ್ಯಗಳು ಬೇಕೇ?
ಖಂಡಿತ, DNS ದಾಖಲೆಗಳಿಗಾಗಿ ಸಣ್ಣ TTL ಗಳನ್ನು ಹೊಂದಿಸಲು ಉತ್ತಮ ಕಾರಣಗಳಿವೆ. ಆದರೆ 75% DNS ಟ್ರಾಫಿಕ್ಗೆ ಅದು ಅಷ್ಟೇನೂ ಬದಲಾಗುವುದಿಲ್ಲ.
ಮತ್ತು ಯಾವುದೇ ಕಾರಣಕ್ಕಾಗಿ ನೀವು ನಿಜವಾಗಿಯೂ DNS ಗಾಗಿ ಕಡಿಮೆ TTL ಗಳನ್ನು ಬಳಸಬೇಕಾದರೆ, ನಿಮ್ಮ ಸೈಟ್ನಲ್ಲಿ ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಅದೇ ಕಾರಣಗಳಿಗಾಗಿ.
ನೀವು ಸ್ಥಳೀಯ DNS ಸಂಗ್ರಹವನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ , ಇದು ನಿಮಗೆ ಕನಿಷ್ಠ TTL ಅನ್ನು ಹೊಂದಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಈ ಕಾರ್ಯವನ್ನು ಬಳಸಿ. ಇದು ಸಾಮಾನ್ಯ. ಕೆಟ್ಟದ್ದೇನೂ ಸಂಭವಿಸುವುದಿಲ್ಲ. ಕನಿಷ್ಠ TTL ಅನ್ನು 40 ನಿಮಿಷಗಳು (2400 ಸೆಕೆಂಡುಗಳು) ಮತ್ತು 1 ಗಂಟೆಯ ನಡುವೆ ಹೊಂದಿಸಿ. ಸಮಂಜಸವಾದ ಶ್ರೇಣಿ.
ಮೂಲ: www.habr.com
