روش اندازه‌گیری DNS Lookup Time + مقدار استاندارد برای آن

تأثیر موقعیت جغرافیایی بازدیدکننده بر DNS Lookup Time

سرورهای دخیل در DNS Resolution دارای موقعیت جغرافیایی خاصی هستند. هرچه فاصله فیزیکی دیوایس بازدیدکننده از این سرورها بیشتر باشد، زمان بیشتری طول می‌کشد تا درخواست مرورگر برای آدرسIP به Authoritative DNS server برسد و سپس آدرس IP از Authoritative DNS server به مرورگر ارسال شود. هر چه فاصله فیزیکی بیشتر باشد، تأخیر یا زمان تاخیر(latency) نیز بیشتر خواهد بود. اقدامات مختلفی می‌توان انجام داد تا زمان تاخیر را به حداقل رساند که در ادامه فصل به آن خواهیم پرداخت. مهم است که زمان‌های جست‌وجویDNS را از هر مکانی در جهان که بازدیدکنندگان سایت شما حضور دارند، اندازه‌گیری کنید.
اگر بیشتر بازدیدکنندگان از نظر فیزیکی به Authoritative DNS Server نزدیک باشند، DNS Lookup Time معمولاً سریع‌تر خواهد بود.

TTL DNS: مدت‌زمان کَش آدرس IP

کشینگ، فرآیند DNS Resolution را به دلیل عدم نیاز به ارسال همیشگی درخواست به Authoritative DNS Server، تسریع می‌کند. با این حال، آدرس IP یک دامنه ممکن است تغییر کند، بنابراین فقط برای مدت معینی می‌توان آن را ذخیره کرد. پارامتر نشان‌دهنده مدت‌زمانی که آدرس IP می‌تواند در کش ذخیره شود، (TTL) Time to Live است. مقدار TTL به ثانیه تعیین می‌شود و می‌تواند از 1 ثانیه تا 604,800 ثانیه (7 روز) متغیر باشد. معمولاً مقادیر TTL بین 30 ثانیه تا 86,400 ثانیه (1 روز) تنظیم می‌شوند.

مقدار بهینه TTL چقدر است؟

مقدار بیشتر TTL منجر به کشینگ طولانی‌تری می‌شود. زمان‌ کشینگ طولانی‌تر تعداد مراحل مورد نیاز برای بازیابی آدرس IP را کاهش می‌دهند، بنابراین زمان ‌کشینگ طولانی‌تر می‌تواند سرعت وب‌سایت را بهبود بخشد. به عنوان مثال، اگر بازدیدکننده‌ای در مدت زمان کش به وب‌سایت بازگردد، اطلاعات DNS دوباره بازیابی نخواهند شد، زیرا این اطلاعات قبلاً در مرورگر ذخیره شده‌اند. حتی اگر یک بازدیدکننده خاص اطلاعات آدرس IP را در کش لوکال در دیوایس خود نداشته باشد، ممکن است اطلاعات آدرس IP توسط ISP کش شده باشد. این امر نیاز به اتصال به روت سرور، TLD سرور و Authoritative DNS Server را از بین می‌برد.

اگرچه زمان‌ کشینگ طولانی‌تر می‌تواند سرعت را بهبود بخشد، اما مقادیر بالاتر TTL به این معناست که ارسال به‌روزرسانی‌ها به اطلاعات DNS برای بازدیدکننده زمان بیشتری می‌برد. ممکن است موقعیتی اضطراری مانند خرابی سرور پیش بیاید. در این حالت نیاز به تغییر سریع آدرس IP سرور داریم. اگر مقدار TTL وب‌سایت 86,400 ثانیه (1 روز) باشد، یک روز کامل طول می‌کشد تا کش پاک شود و اطلاعات آدرس IP جدید درخواست شود.
بدیهی است که منتظر نگه داشتن بازدیدکنندگان برای یک روز کامل تا مشاهده آدرس IP جدید قابل قبول نیست، به‌ویژه اگر آدرس IP به دلیل یک وضعیت اضطراری تغییر کرده باشد.

احتمالا سوال شما این است که بهترین مقدار برای TTL چیست؟ پاسخ این است که مقدار درستی برای TTL وجود ندارد. پیشنهادات متعددی در این زمینه وجود دارد. برخی متخصصان پیشنهاد می‌کنند که مقادیر TTL یک ساعت (3600 ثانیه) تنظیم شوند و برخی دیگر پیشنهاد می‌کنند که مقادیر TTL روی پنج دقیقه (600 ثانیه) یا کمتر تنظیم شود. در واقع هدف این است که تعادلی بین سایت سریع‌تر و نیاز به پاسخ‌دهی به وضعیت‌های اضطراری برقرار شود. اگرDNS Lookup Time خیلی زیاد باشد، تنظیم مقادیر TTL برای افزایش کشینگ تایم ممکن است به بهبود سرعت وب‌سایت کمک کند.

تاثیرات منابع ثالث ( Third-Party Resources) روی TTL

هنگامی که یک وب‌سایت در حال بارگذاری است، ممکن است نیاز باشد فایل‌هایی مانند فونت‌ها، ویدئوها یا تصاویر از دامنه‌های مختلف درخواست شوند. چون این فایل‌ها روی دامنه‌های دیگری میزبانی می‌شوند. به عنوان مثال، وب‌سایتی ممکن است از کتابخانه فونت‌های گوگل استفاده کند. در این صورت باید، یک پروسهٔ DNS Lookup Time برایfonts.gstatic.com که فونت‌ها بر روی آن میزبانی می‌شوند، انجام شود. در این حالت زمان لازم برای انجام این کار به DNS Lookup Time DNS دامنه اصلی اضافه می‌شود.

اندازه‌گیری DNS Lookup Time

DNS Lookup Time باید در سطح دامنه برای دامنه اصلی و تمام دامنه‌های ثالثی که وب‌سایت از آن‌ها استفاده می‌کند، اندازه‌گیری شود. تست یک صفحه از دامنه کافی برای اندازه‌گیری کافی است زیرا این متریک برای صفحات مختلف تغییر نمی‌کند.

البته سابدامین‌ها باید به طور جداگانه بررسی شوند چون ممکن است از هاستینگ‌های مختلفی استفاده کنند. به عنوان مثال ممکن است mysite.com و images.mysite.com در دو سرور متفاوت میزبانی شوند و هر کدام Authoritative DNS Server جداگانه‌ای داشته باشند.

DNS Lookup Time برای هر دامنه باید در مکان‌های جغرافیایی مختلف اندازه‌گیری شود تا میران تأخیر (latency) ارزیابی شود. اگر DNS Lookup Time برای یک دامنه خاص کند باشد، باید فرآیند DNS Lookup را بررسی کرد تا مشخص شود که مشکل در کدام بخش از فرآیند است.

مقدار استاندارد DNS Lookup Time

بهترین توصیه برای DNS Lookup Time (که توسط Sematext اعلام شده است) بین 20 تا 120 میلی‌ثانیه است. تست DNSPerfکه در ادامه این بخش به آن خواهیم پرداخت DNS Lookup Time بالاتر از 40 میلی‌ثانیه را کند تلقی می‌کند.

DNS Lookup Time جهانی: مقدار استاندارد سرعت DNS

گزارش DNSPerf برای استاندارد سرعت DNS (www.dnsperf.com/dns-speed-benchmark)
یک گزارش بسیار مفید را در قالب یک نمودار بصری ساده ارائه می‌دهد که DNS Lookup Time را در سراسر جهان اندازه‌گیری می‌کند. این گزارش یک دید اولیه مفید برای شناسایی مشکلات احتمالی ناشی از تأخیر به دلیل موقعیت جغرافیایی بازدیدکننده فراهم می‌کند. بعد از شناسایی مشکلات، می‌توان تحلیل دقیق‌تری با استفاده از ابزارهای دیگر انجام داد.

درDNSPerf، ابتدا نام دامنه‌ای که می‌خواهید بررسی کنید را وارد کرده و لوکیشن آزمایش را انتخاب کنید. به طور پیش‌فرض، این ابزار DNS Lookup Time را در سراسر جهان اندازه‌گیری می‌کند. این آزمایش می‌تواند محدود به یک قاره یا کشوری نزدیک به لوکیشن بازدیدکنندگان وب‌سایت شما شود. اگر بیشتر بازدیدکنندگان از ایران باشند، بررسی زمان تأخیر از سمت انگلستان الزامی نیست.

در شکل ۳-۱ نمونه تست سرعت DNS برای سایت دیجیکالا را مشاهده می‌کنید. در پایین نقشه، جدول میزان تأخیر بصورت دقیق برای شهرهای مختلف قید شده است. در این نمونه، زمان‌های تأخیر در قسمت غربی آسیا کمتر هستند؛ اگرچه تمام مقادیر بالاتر از ۴۰ میلی ثانیه هستند.

میران تأخیر در سمت غرب آسیا بیشتر می‌شوند و در سنگاپور به ۲۸۴ میلی‌ثانیه می‌رسد.

استفاده از سایت WebPageTestبرای بررسی دامین

منابع ثالث (Third-Party Resources) موجود در دامنه‌های دیگر نیاز به کانکشن DNS جداگانه دارند. همانطور که در بخش پیشین توضیح داده شد این مسئله، زمان بارگذاری کلی وب‌سایت را افزایش می‌دهد. برای تعیین اینکه آیا منابع ثالث در کاهش سرعت تاثیرگذار بوده‌اند یا خیر، DNS Lookup Time باید برای تمام دامنه‌های ثالث استفاده‌شده در وب‌سایت اندازه‌گیری شود. اگر DNS Lookup Time برای دامنهٔ خاصی کندتر باشد، استفاده از prefetch (که در ادامه این فصل توضیح داده خواهد شد) می‌تواند کمک‌کننده باشد.

وبسایت WebPageTest (https://webpagetest.org/)برای دامنه اصلی وب‌سایت و هر دامنهٔ ثالثی که در وب‌سایت استفاده می‌شود DNS Lookup Time را بصورت مجزا اندازه‌گیری می‌کند. تست‌های WebPageTest از مکان‌های مختلف انجام می‌شوند و باعث می‌شوند تفاوت‌ها ناشی از تغییر لوکیشن نشان داده شود. در بخش تنظیمات Simple Configuration چند مکان برای تست پیشنهاد داده می‌شود. در تنظیمات Advanced Configuration فهرستی گسترده‌تر از لوکیشن‌های آزمایشی در اختیار شماست.

این آزمایش‌ها باید روی صفحات مختلف وب‌سایت انجام شوند زیرا در هر صفحه ممکن است منابع ثالث متفاوتی استفاده شده باشد.

اطلاعات مربوط به منابع ثالث در گزارش Connection View ارائه می‌شود. پس از انجام تست درWebPageTest، برای دسترسی به این گزارش، گزینه Details را از منوی View انتخاب کرده و سپس به Connection View اسکرول کنید. همان‌طور که در گزارش نمونه شکل ۵-۱ نشان داده شده، هر دامنه‌ای که هنگام بارگذاری این صفحه در وب‌سایت درخواست شده است، فهرست می‌شود.

وقتی افقی به نمودار نگاه می‌کنید، برای هر دامنه یک نوار نشان داده می‌شود که جنبه‌های مختلف فرآیند بارگذاری آن دامنه را نشان می‌دهد. DNS Lookup Time در اولین بخش این نوار قرار دارد، که با رنگ سبز تیره نشان داده شده است و تصویری از میزان زمانی که DNS Resolution برای دامنه اصلی و هر دامنهٔ ثالثی که در صفحه آزمایشی استفاده شده، مصرف می‌کند، نشان می‌دهد.

زمان‌های DNS Lookup که به میلی‌ثانیه نمایش داده می‌شوند، می‌توانند با استفاده از جدول Request Details در زیر گزارش Connection View که در شکل ۶-۱ نشان داده شده، اندازه‌گیری شوند. جدول را بر اساس ستون DNS Lookup Time مرتب (Sort) کنید تا میلی‌ثانیه‌های لازم برای اتصال به هر دامنه را مشاهده کنید.

گزارش Connection View که زمان‌های بارگذاری هر دامنه را نشان می‌دهد

جدول جزئیات درخواست که زمان جست‌وجوی DNS برای هر دامنه

DIG تست:DiG GUI

تست‌ Domain Information Groper (DiG)جزئیات بیشتری درباره فرآیند درخواست و ارسال پاسخ در اختیار شما قرار می‌دهد. آزمایش‌های DiG زمانی مفید هستند که نیاز به تشخیص عمیق‌تری باشد و با استفاده از ابزارهایی مانند DNSPerf یا WebPageTest به این نتیجه رسیده باشیم که DNS Lookup Time کند است.

اگرچه آزمایش‌هایDiG می‌توانند روی یک کامپیوتر محلی اجرا شوند، اما با استفاده از ابزار آنلاین مانند DiG GUI (http://www.diggui.com) راحت‌تر است. درDiG GUI، URLوب‌سایت را در فیلد نام میزبان وارد کنید. نتایج یک نمونه تست DiG GUI در شکل ۷-۱ نشان داده شده است. بخش Answer Section، آدرس IP این دامنه و مقادیر TTL را نشان می‌دهد. در مثال زیر که مربوط به سایت دیجیکالا است، TTL برابر با 2930 ثانیه است. زیر این بخش، می‌توانیدQuery Time را مشاهده کنید که در این مثال ۷ میلی‌ثانیه است.

DiG GUI گزینه‌های دیگری برای بررسی بیشتر DNS Lookup Time دارد. یکی از این گزینه‌ها، گزینه trace است که جزئیات بیشتری از فرآیند گام به گام DNS را نشان می‌دهد. این گزینه می‌تواند به تشخیص بیشتر هرگونه مشکل موجود کمک کند.

روش‌های بهبود DNS Lookup Time

بهبود زمان تأخیر DNS اغلب نیاز به تغییرات قابل توجه و پیچیده‌ای دارد، از جمله بهبود اتصال شبکه و تنظیم نحوهٔ مدیریت .DNS بهبود قابل توجه در این متریک معمولاً نیاز به سرمایه‌گذاری‌های زیادی دارد، زیرا این تغییرات نیاز به بررسی توسط متخصصان خبره این حوزه را دارد. با این حال، روش‌های ساده‌تری نیز وجود دارد که می‌توان ابتدا برای بهبود DNS Lookup Time به سراغ آنها رفت.

۱- انتخاب DNS Provider سریع‌تر

یکی از مؤثرترین و ساده‌ترین روش‌ها برای کاهش DNS Lookup Time، استفاده از یک تأمین‌کننده سریع‌تر است که می‌تواند آدرس IP را سریع‌تر به مرورگر ارسال کند. DNS Provider مسئول مدیریت رکوردهای DNS برای یک دامنه است.

بسیاری از شرکت‌ها گزینه پیش‌فرض سرورها را انتخاب می‌کنند و به ثبت‌کننده دامنه یا شرکت میزبانی وب‌ اجازه می‌دهند تا DNS دامنه را مدیریت کند. در صورتی که ثبت‌کننده دامنه یا شرکت میزبانی، DNS را به‌خوبی مدیریت کند ممکن است عملکرد قابل قبولی ایجاد شود. اما، ممکن است ثبت‌کننده یا شرکت میزبانی وب به اندازه یک DNS Provider اختصاصی مؤثر نباشد. استفاده از یک DNS Provider اختصاصی می‌تواند زمان‌های DNS Lookup را کاهش دهد.

Provider DNS اختصاصی سرعت‌های بالاتری ارائه می‌دهد زیرا زیرساخت‌های بیشتری برای پاسخ به درخواست‌های DNS دارند و این زیرساخت‌ها به‌طور بهتر و موثرتری در سطح جهانی توزیع شده‌اند، که به DNS Provider این امکان را می‌دهد تا تأخیر را کاهش دهد.

فهرست DNS Providers List در DNSPerf زمان‌های جست‌وجوی DNS برای تأمین‌کنندگان مختلف در سطح جهان را گزارش می‌کند (www.dnsperf.com/dns-providers-list) .

یک نمونه در شکل ۸-۱ نشان داده شده است. برای مثال، Cloudflareکوئری تایم 12.41 میلی‌ثانیه دارد و یکی از سریع‌ترین تأمین‌کنندگان است زیرا از توزیع سرور جهانی استفاده می‌کند و سرورها را به‌طور فیزیکی نزدیک‌تر به بازدیدکننده وب‌سایت قرار می‌دهد و تأخیر را کاهش می‌دهد.

۲- prefetch دامنه‌های ثالث: dns-prefetch و preconnect

اتصال به دامنه‌های ثالث به زمان‌های کلی DNS Lookup Time افزوده می‌شود. این مشکل می‌تواند با حذف منابع غیرضروری ثالث بهبود یابد. با این حال، نمی‌توان تمام منابع ثالث را حذف کرد. برای منابعی که نمی‌توان آنها را حذف کرد، می‌توان از تگ لینک dns-prefetch در بخش کد HTML صفحه وب استفاده کرد. این تگ به مرورگر دستور می‌دهد که اطلاعات DNS دامنه مشخص‌شده را زودتر در فرآیند بارگذاری صفحه دریافت کند.

برای مثال، اگر کد زیر به بخش<head> صفحه وب اضافه شود، مرورگر جست‌وجوی DNS دامنه ثالث otherdomain.com را زودتر در فرآیند بارگذاری صفحه انجام می‌دهد و آن اطلاعات DNS را به‌طور محلی ذخیره می‌کند. زمانی که مرورگر بعداً فایلی از otherdomain.com درخواست کند (مثل تصویر، ویدیو یا فونت)، آدرس IP این دامنه قبلاً در کش ذخیره شده است.

این تگ فقط باید برای دامنه‌های بین‌سایتی (cross-origin) استفاده شود و نه برای دامنه اصلی. برای سایت اصلی هرگز نیازی به استفاده از dns-prefetch نخواهد بود، زیرا مرورگر قبلاً ارتباط با دامنه اصلی را برقرار کرده است.

راه دیگر استفاده از تگ لینک preconnect است. preconnect علاوه بر درخواست اطلاعات DNS، اتصال TCP و TLS را به آن سرور برقرار می‌کند.درباره اتصالات TCP و TLS در فصل بعد به‌طور مفصل‌تر بحث خواهیم کرد. مشابه dns-prefetch، زمانی که مرورگر با preconnect روبرو می‌شود، درخواستDNS، اتصال TCP و اتصال TLS را زودتر انجام می‌دهد تا دامنه برای استفاده بعدی آماده شود. این رویکرد می‌تواند سرعت بارگذاری فایل‌ها از دامنه‌های ثالث را بهبود بخشد.

البته، تگ preconnectنیاز به انجام کار بیشتری برای مرورگر نسبت به dns-prefetch دارد. بنابراین اگر به درستی استفاده نشود، حتی می‌تواند سرعت سایت را کاهش دهد. به‌طور معمول، preconnect فقط باید برای منابع حیاتی استفاده شود و dns-prefetch برای منابع کم‌اهمیت‌تر ثالث. درباره این موضوع در فصل 5 بیشتر بحث خواهیم کرد.

یک نمونه تگ preconnect به صورت زیر است. مشابه تگ dns-prefetch، تگ preconnect نیز در بخش <head> کد HTML صفحه وب قرار می‌گیرد.

خلاصه

DNS Lookup Time متریکی مفید برای درک اولین مرحلهٔ کانکشن یک مرورگر وب برای اتصال به یک وب‌سایت مفید است.

آیا گنجاندن این متریک در گزارشات دوره‌ای معنادار و مفید است؟

DNS Lookup Time یک اتفاق خاص را اندازه‌گیری می‌کند که بسیار مهم است، اما از آنجایی که دامنهٔ محدودی دارد، بیشتر زمانی که نیاز به بررسی عمیق‌ و دقیق که همه جنبه‌های سرعت وب‌سایت را بررسی می‌کند، مفید است. بدین ترتیب مشخص می‌شود که آیا مشکلی در اولین مرحله اتصال به وب‌سایت وجود دارد یا خیر. معمولاً گزارش این متریک در گزارش‌دهی منظم گنجانده نمی‌شود.

آیا بهینه‌سازی DNS Lookup Time از نظر تجاری قابل توجیه است؟

به دلیل اندازه کم این متریک به‌طور مستقیم تاثیر چندانی بر فاکتورهای تجاری مانند کانورژن ریت و تعاملات کاربر ندارد. البته کند بودن DNS Lookup Time ممکن است از طریق کند کردن سایت، به‌طور غیرمستقیم، بر اهداف بیزینس تأثیر بگذارد. این ارتباط غیرمستقیم باعث می‌شود اغلب DNS Lookup Time را به‌عنوان یک KPI سرعت در نظر نگیریم. زیرا در عمل کنترل کاملی بر مقدار آن وجود ندارند، به خصوص در ایران. بنابراین حتی اگر DNS Lookup Time کند باشد، بهینه کردن آن به نسبت سایر مواردی که در ادامه بررسی خواهیم کرد کمتر عملی است.

آیا DNS Lookup Time روی تجربه کاربری موثر است؟

به‌عنوان یک متریک ابتدایی، کند بودن آن می‌تواند سایر متریک‌ها را تحت تاثیر قرار دهد و در کل وب‌سایت را برای بازدیدکنندگان کند کنند. با این حال، DNS Lookup Time بطور ویژه تجربهٔ خاصی که بازدیدکنندگان در وب‌سایت دارند را توصیف نمی‌کنند. زیرا حتی اگر این متریک کند باشد باز هم می‌توان یک تجربه سریع و رضایت‌بخش برای بازدیدکنندگان فراهم کرد.

بهبود این متریک چقدر آسان است؟

تغییر DNS Provider و تغییر روش بارگذاری منابع ثالث می‌تواند زمان‌های DNS Lookup را کاهش دهد، اگر این کارها کافی نباشند، تغییرات گسترده‌تر و فنی‌تری لازم است که می‌تواند چالش‌برانگیز باشد. به یاد داشته باشید حذف منابع ثالث در وبسایت لزوما راهکار مناسبی نیست، مخصوصاً اگر آن منابع برای عملکرد کلی وب‌سایت حیاتی باشند.

بهبود DNS Lookup Time چقدر تأثیرگذار است؟

اگر DNS Lookup Time کند باشد بهبودش می‌تواند تأثیرات زیادی داشته باشند. زیرا زمان اولین مرحله‌ای را اندازه‌گیری می‌کند که برای بارگذاری یک وب‌سایت انجام می‌شود، هر گونه بهبودی در مراحل بعدی موثر خواهد بود. به‌ویژه زمانی که DNS Lookup Time در لوکیشن‌هایی با تأخیر بیشتر بهتر شوند. اگر زمان‌های DNS Lookup در سطح قابل قبول قرار داشته باشند، اثرات بهبود ناچیز خواهد بود.