مزایای خرید VPS در دالاس و بررسی تأخیر شبکه

مزایای میزبانی VPS در دالاس

میزبانی VPS در دالاس، موقعیت شبکه خاصی را برای شما فراهم می‌کند. یک VPS (سرور مجازی خصوصی) بخشی از یک ماشین فیزیکی در یک ساختمان مشخص است؛ بنابراین آن ساختمان تعیین‌کننده زمان رفت‌وبرگشت (RTT) برای کاربران، هزینه پهنای باند و حوزه‌های قضایی است که به دیسک شما دسترسی دارند. دالاس در نزدیکی مرکز ایالات متحده و در یکی از متراکم‌ترین بازارهای مخابراتی کشور واقع شده است. این تمام استدلال برای انتخاب این مکان است. باقی این راهنما به نحوه بررسی این موضوع می‌پردازد که آیا این استدلال برای کاربران شما صدق می‌کند یا خیر، و در چه مواردی کاربرد ندارد.

اگر هنوز تصمیم نگرفته‌اید که سرور برای چه کاری است، ابتدا آنچه واقعاً می‌توانید با یک VPS انجام دهید را مطالعه کنید. موقعیت مکانی آخرین تصمیمی است که باید بگیرید، نه اولین تصمیم.

چه میزان تأخیری (Latency) می‌توان از یک VPS در دالاس انتظار داشت؟

[
  {
    "label": "Dallas metro",
    "typical_rtt_ms": 2
  },
  {
    "label": "Houston",
    "typical_rtt_ms": 8
  },
  {
    "label": "Chicago",
    "typical_rtt_ms": 23
  },
  {
    "label": "Miami",
    "typical_rtt_ms": 33
  },
  {
    "label": "New York",
    "typical_rtt_ms": 36
  },
  {
    "label": "Los Angeles",
    "typical_rtt_ms": 35
  },
  {
    "label": "Seattle",
    "typical_rtt_ms": 50
  },
  {
    "label": "Mexico City",
    "typical_rtt_ms": 48
  },
  {
    "label": "Bogota",
    "typical_rtt_ms": 78
  },
  {
    "label": "Sao Paulo",
    "typical_rtt_ms": 140
  },
  {
    "label": "London",
    "typical_rtt_ms": 112
  },
  {
    "label": "Frankfurt",
    "typical_rtt_ms": 125
  },
  {
    "label": "Singapore",
    "typical_rtt_ms": 215
  }
]

آن 13 ردیف، ارقام منتشرشدهٔ معمول برای اتصالات کابلی در مسیرهایی با peering مناسب هستند و نه اندازه‌گیری‌های انجام‌شده از دستگاه شما. آن‌ها را صرفاً به عنوان نقطه شروع در نظر بگیرید. نتیجهٔ نهایی شما بیش از آنکه به سرور وابسته باشد، به ارائه‌دهندهٔ اینترنت شما بستگی دارد: Wi-Fi چند میلی‌ثانیه، شبکهٔ موبایل ده‌ها میلی‌ثانیه و یک ارائه‌دهندهٔ خانگی با peering ضعیف می‌تواند 30 میلی‌ثانیه به مسیری اضافه کند که طبق قوانین فیزیک باید 15 میلی‌ثانیه باشد.

به جای تمرکز بر یک عدد خاص، به الگو توجه کنید. هر شهر بزرگ در ایالات متحدهٔ قاره‌ای، تأخیری در حدود 50 میلی‌ثانیه یا کمتر دارد؛ به طوری که هیوستون در 8 میلی‌ثانیه و شیکاگو در 23 میلی‌ثانیه قرار می‌گیرند. مکزیکوسیتی در حدود 48 میلی‌ثانیه است که از هر دو ساحل ایالات متحده به دالاس نزدیک‌تر است، زیرا بخش بزرگی از ترافیک آمریکای لاتین از قبل از تگزاس یا فلوریدا عبور می‌کند. سائوپائولو با 140 میلی‌ثانیه یک مسیر طولانی است و سنگاپور با 215 میلی‌ثانیه، مسئله‌ای کاملاً متفاوت محسوب می‌شود.

میلی‌ثانیه‌ها بیش از آنچه ارقام خام نشان می‌دهند اهمیت دارند، زیرا یک اتصال از رفت‌وبرگشت‌های متعددی تشکیل شده است. باز کردن یک درخواست HTTPS شامل یک رفت‌وبرگشت برای دست‌دادن (handshake) پروتکل TCP، یک رفت‌وبرگشت دیگر برای TLS 1.3 و یک رفت‌وبرگشت برای خودِ درخواست است. در 35 میلی‌ثانیه، این یعنی بیش از 100 میلی‌ثانیه زمان پیش از آنکه اولین بایت دریافت شود. صفحه‌ای که 20 فراخوانی API را یکی پس از دیگری انجام می‌دهد، 35 میلی‌ثانیه را به 700 میلی‌ثانیه انتظار تبدیل می‌کند. SSH تعاملی در 35 میلی‌ثانیه حس متفاوتی نسبت به 8 میلی‌ثانیه دارد و یک سرور بازی در 35 میلی‌ثانیه عملکرد مناسبی دارد، در حالی که همان سرور در 140 میلی‌ثانیه غیرقابل استفاده است. برای مواردی که هر کاربر بلافاصله آن را حس می‌کند، مانند یک سرور Minecraft روی VPS، موقعیت مرکزی سرور تأثیر واقعی و ملموسی دارد.

آیا مرکز کشور بهتر از سواحل است؟

نور در فیبر نوری با سرعتی در حدود 200,000 کیلومتر بر ثانیه حرکت می‌کند که دو‌سوم سرعت آن در خلأ است. بنابراین، یک رفت‌وبرگشت برای هر 100 کیلومتر فیبر، تقریباً 1 میلی‌ثانیه زمان می‌برد و فیبر هرگز به‌صورت مستقیم بین دو شهر کشیده نمی‌شود. این یک محدودیت فیزیکی است؛ بنابراین هیچ مقدار پولی نمی‌تواند یک بسته داده را سریع‌تر از آنچه شیشه اجازه می‌دهد، از Dallas به Frankfurt منتقل کند. مکان تنها اهرمی است که در اختیار دارید.

فاصله Dallas تا New York حدود 2,200 کیلومتر و تا Los Angeles حدود 2,000 کیلومتر است که توزیعی به‌طور غیرمعمولی متوازن محسوب می‌شود. این پراکندگی را با دو بازار ساحلی که اکثر افراد در وهله اول در نظر می‌گیرند، مقایسه کنید.

[
  {
    "label": "Northern Virginia",
    "to_new_york_ms": 10,
    "to_los_angeles_ms": 62
  },
  {
    "label": "Dallas",
    "to_new_york_ms": 36,
    "to_los_angeles_ms": 35
  },
  {
    "label": "Los Angeles metro",
    "to_new_york_ms": 68,
    "to_los_angeles_ms": 3
  }
]

این‌ها ارقام منتشرشدهٔ استانداردی هستند و نکته اصلی در شکل این توزیع نهفته است. Northern Virginia به New York در حدود 10 میلی‌ثانیه و به Los Angeles در حدود 62 میلی‌ثانیه سرویس می‌دهد که اختلافی بیش از 50 میلی‌ثانیه دارد. یک میزبان در Los Angeles این وضعیت را معکوس می‌کند و به New York در حدود 68 میلی‌ثانیه پاسخ می‌دهد. Dallas برای شهری که در مجاورت هر یک از این دو نقطه قرار دارد، عملکرد ضعیف‌تری دارد، اما برای شهری که از هر دو نقطه دور است، عملکرد بهتری ارائه می‌دهد.

بنابراین سؤال این نیست که کدام شهر سریع‌تر است؛ بلکه این است که چه شکلی از توزیع را می‌خواهید. زمانی که اکثر کاربران شما در یک ساحل هستند و می‌خواهید میانه تأخیر (median) پایین باشد، یک ساحل را انتخاب کنید. زمانی که کاربران شما در سراسر کشور پراکنده‌اند و می‌خواهید بدترین حالت تأخیر (worst case) کوچک باشد، Dallas را انتخاب کنید. این همان مبادله‌ای است که در آنچه هنگام انتخاب یک VPS کانادایی واقعاً اهمیت دارد بررسی شده است، جایی که جمعیت به‌جای دو ساحل، روی یک خط طولانی قرار گرفته‌اند.

تراکم حامل در دالاس واقعاً چه چیزی برای شما فراهم می‌کند

یک carrier hotel ساختمانی است که شبکه‌های بسیاری در آن پایان می‌یابند و مستقیماً به یکدیگر متصل می‌شوند. دالاس یک نمونه مشهور دارد: Infomart در آدرس 1950 North Stemmons Freeway که Equinix آن را در سال 2018 به مبلغ 800 میلیون دلار خریداری کرد. یک internet exchange یا IX، یک سوئیچ اشتراکی در داخل چنین ساختمانی است که شبکه‌ها در آن به جای پرداخت هزینه به شخص ثالث برای انتقال ترافیک، با یکدیگر peer می‌شوند. DE-CIX از نوامبر 2016 یک exchange در دالاس اداره می‌کند و Equinix نیز exchange اختصاصی خود را دارد.

این موضوع در traceroute قابل مشاهده است. هنگامی که میزبان شما و ارائه‌دهنده اینترنت کاربرتان هر دو در یک exchange قرار دارند، بسته از یک مرز عبور می‌کند. وقتی این‌طور نیست، بسته به یک transit provider تحویل داده می‌شود که ممکن است آن را به Ashburn یا Atlanta ببرد و بازگرداند تا تحویل داده شود. این مسافت اضافی به معنای میلی‌ثانیه‌های واقعی است و هر شبکه اضافی، یک نقطه دیگر است که در آن لینکی که ساعت 9 شب پر می‌شود، به packet loss تبدیل می‌گردد.

شما می‌توانید پیش از پرداخت هزینه، همه این موارد را بررسی کنید.

• از ارائه‌دهنده، ASN (شماره سیستم خودمختار) آن را بخواهید. هر شبکه‌ای که از BGP (پروتکل دروازه مرزی) استفاده می‌کند، یک ASN دارد.
• آن ASN را در PeeringDB جستجو کنید. این پایگاه داده فهرست می‌کند که یک شبکه به کدام exchangeها متصل است و در کدام ساختمان‌ها حضور دارد؛ شبکه‌ها خودشان ورودی‌های مربوط به خود را مدیریت می‌کنند.
• بررسی کنید که چه exchangeهایی در خودِ آن مرکز حضور دارند. ارائه‌دهنده‌ای که در همان ساختمانِ یک exchange است اما به آن نپیوسته، هیچ مزیتی برای شما ندارد.
• مسیر را از شبکه‌ای که کاربران شما در آن هستند ردیابی کنید و بشمارید که از چند شبکه مجزا عبور می‌کند.

mtr -rwzc 100 203.0.113.10

گزارش، برای هر hop یک خط شامل شماره شبکه، درصد loss و زمان‌بندی چاپ می‌کند. ابتدا خط آخر را بخوانید، زیرا آن خط سرور شماست. loss در یک hop میانی بدون وجود loss در انتها طبیعی است، زیرا روترها به پاسخ‌های ICMP (پروتکل پیام کنترل اینترنت) که خودشان تولید می‌کنند اولویت پایینی می‌دهند، بنابراین آن hop گزارش‌دهی ناقصی دارد. lossای که از یک hop شروع شده و در تمام hopهای بعدی ادامه می‌یابد، یک خطای واقعی است و باید همراه با گزارش در یک تیکت پشتیبانی ارسال شود.

آیا شبکه برق تگزاس پایداری سرویس شما را به خطر می‌اندازد؟

تگزاس شبکه برق مستقل خود را دارد. ERCOT (شورای قابلیت اطمینان برق تگزاس) حدود 90 درصد از بار الکتریکی این ایالت را پوشش می‌دهد و با باقی شبکه آمریکای شمالی همگام‌سازی نشده است. این شبکه از طریق مجموعه‌ای محدود از اتصالات جریان مستقیم (DC) به همسایگان خود متصل است که مجموعاً حدود 1.2 GW ظرفیت دارند؛ این در حالی است که اوج تقاضا در 22 July 2026 بیش از 91 GW ثبت شده است. بنابراین، وقتی تگزاس با کمبود مواجه می‌شود، نمی‌تواند با واردات برق مشکل را حل کند. این همان مکانیزمی است که در February 2021 باعث شد طوفان زمستانی Uri منجر به روزها قطعی برق چرخشی در سراسر محدوده ERCOT شود.

برای سرور شما، شبکه برق مسئله اصلی نیست، بلکه ساختمان دیتاسنتر اهمیت دارد. یک دیتاسنتر در زمان قطعی برق شبکه، برای چند دقیقه از باتری‌های UPS (منبع تغذیه بدون وقفه) استفاده می‌کند و سپس تا زمانی که سوخت موجود باشد، از ژنراتورهای دیزلی بهره می‌برد. چهار سوال زیر را بپرسید و پاسخ‌ها را به‌صورت کتبی دریافت کنید: آیا مسیر انتقال برق N+1 است یا 2N، ژنراتورها با سوخت موجود در محل چند ساعت در بار کامل کار می‌کنند، آیا قرارداد اولویت‌دار برای تأمین سوخت وجود دارد، و آخرین باری که ژنراتورها را تحت بار واقعی تست کرده‌اند چه زمانی بوده است. ارائه‌دهنده‌ای که نتواند به سوال آخر پاسخ دهد، تست را انجام نداده است.

همین شبکه برق دلیل ارزان بودن ظرفیت در این منطقه است. هزینه برق صنعتی در تگزاس کمتر از میانگین ایالات متحده است و از آنجا که برق بزرگ‌ترین هزینه جاری در یک دیتاسنتر محسوب می‌شود، قیمت‌گذاری در دالاس پایین‌تر از بازارهای محدودتری مانند شمال ویرجینیا است. این تفاوت در فاکتور شما نمایان می‌شود. هنگامی که قیمت‌ها را در شهرهای مختلف مقایسه می‌کنید، هزینه واقعی یک VPS را در کنار آن‌ها باز نگه دارید، زیرا مشاهده حق‌اشتراک موقعیت مکانی در کنار نرخ پایه بسیار آسان‌تر است.

آیا گردبادها و گرمای تگزاس، دیتاسنترهای دالاس را تهدید می‌کنند؟

این دو پرسش، دو پاسخ متفاوت دارند.

باد و تگرگ، مسئله‌ای مربوط به ساختمان است. در تاریخ 20 اکتبر 2019، یک گردباد EF3 با سرعت باد نزدیک به 140 مایل بر ساعت، در نزدیکی فرودگاه Dallas Love Field فرود آمد و مسیری 15 مایلی را در شمال دالاس طی کرد که حدود 1.5 میلیارد دلار خسارت به بار آورد. این مسیر از چند مایلی کریدور دیتاسنترهای Stemmons Freeway می‌گذرد. یک سالن دیتاسنتر که با هدف خاص ساخته شده، سازه‌ای بتنی و بدون پنجره است و در برابر بادی که سقف یک مرکز خرید را از جا می‌کند، مقاومت می‌کند. بخش‌های در معرض خطر، بالای آن قرار دارند: کندانسورها و برج‌های خنک‌کننده. تگرگ‌های بزرگ در بیشتر بهارها می‌بارند و دقیقاً روی همان تجهیزات فرود می‌آیند. بپرسید که پوسته ساختمان برای چه سرعتی رتبه‌بندی شده و تأسیسات مکانیکی در کجا قرار دارند.

گرما، مسئله‌ای مربوط به هزینه است. دالاس در ماه‌های ژوئیه و اوت برای دوره‌های طولانی دمای بالای 100 درجه فارنهایت (38 درجه سانتی‌گراد) را تجربه می‌کند. سیستم سرمایش برای روزهای اوج طراحی محلی تنظیم شده است، بنابراین دما در اتاق ثابت می‌ماند. آنچه افزایش می‌یابد، PUE (کارایی مصرف انرژی؛ کل توان مصرفی مرکز تقسیم بر توانی که به سرورها می‌رسد) است، زیرا چیلرها در ماه اوت سخت‌تر از ماه فوریه کار می‌کنند و این هزینه از قبل در قیمت شما لحاظ شده است. ریسک واقعی گرما، خرابی سیستم سرمایش در طول موج گرما است: با دمای 104 درجه فارنهایت (40 درجه سانتی‌گراد) در بیرون، اتاقی که سرمایش ندارد، در عرض چند دقیقه به دمای خاموشی اضطراری می‌رسد، نه یک ساعت؛ بنابراین کارکنان زمان بسیار کمتری برای تعمیر چیلر دارند. بپرسید که آیا سیستم سرمایش N+1 است یا خیر، نه فقط اینکه آیا برق N+1 است.

هیچ‌کدام از این پاسخ‌ها دلیلی برای اجتناب از دالاس نیستند. هر دو، دلایلی برای نگهداری نسخه‌ای از داده‌های شما در مکانی دیگر هستند. پشتیبان‌گیری در همان ساختمان، پشتیبان‌گیری محسوب نمی‌شود و پشتیبان‌گیری‌های رمزنگاری‌شده خارج از سایت با restic تنها یک بعدازظهر زمان برای راه‌اندازی نیاز دارند.

چه زمانی Dallas پاسخ اشتباهی است؟

Dallas یک انتخاب پیش‌فرض منطقی است، نه یک قانون. در موارد زیر، میزبانی را در جای دیگری انجام دهید:

• کاربران شما در اروپا هستند. یک سرور در Dallas به Frankfurt با تأخیر حدود 125 میلی‌ثانیه و به London با تأخیر حدود 112 میلی‌ثانیه پاسخ می‌دهد. این فاصله ناشی از مسافت فیزیکی است و هیچ تغییر پیکربندی نمی‌تواند آن را بهبود بخشد.
• کاربران شما در آسیا یا استرالیا هستند. تأخیر Singapore با 215 میلی‌ثانیه حتی بیشتر است و داشتن سرور دوم در نزدیکی آن کاربران، بهتر از هرگونه بهینه‌سازی روی سرور اول عمل می‌کند.
• تمام کاربران شما در یک کلان‌شهر غیر از Dallas هستند. اگر تمام کسانی که از برنامه شما استفاده می‌کنند در Seattle حضور دارند، میزبانی را در Seattle انجام دهید. موقعیت مرکزی تنها زمانی سودمند است که لبه‌های شبکه (کاربران) پراکنده باشند.
• یک قرارداد یا نهاد نظارتی ایجاب می‌کند که داده‌ها در یک کشور خاص باقی بمانند. این یک مسئله عملکردی نیست و هیچ بنچمارکی نمی‌تواند آن را حل کند.
• تأخیر (Latency) استراتژی اصلی شما در یک بورس ایالات متحده است. موتور تطبیق CME Group در Aurora, Illinois قرار دارد. NYSE از Mahwah, New Jersey و Nasdaq از Carteret, New Jersey فعالیت می‌کنند. Dallas بیش از 20 میلی‌ثانیه با همه آن‌ها فاصله دارد. اکثر اتوماسیون‌های خرده‌فروشی به این موضوع اهمیت نمی‌دهند، اما انتخاب یک VPS برای ربات‌های معامله‌گر بر اساس محل دقیق قرارگیری آن خط ارتباطی تعیین می‌شود.

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

سروری در دالاس تحت حاکمیت قوانین فدرال ایالات متحده و قوانین ایالتی تگزاس قرار دارد. در هر بررسی امنیتی، دو نکته مطرح می‌شود.

قانون CLOUD Act ایالات متحده به مقامات این کشور اجازه می‌دهد تا ارائه‌دهندگان خدمات آمریکایی را ملزم به ارائه داده‌های تحت کنترل خود کنند، فارغ از اینکه دیسک فیزیکی در کجا قرار دارد. انتخاب شهری دیگر در ایالات متحده تغییری در این وضعیت ایجاد نمی‌کند و انتخاب شهری خارج از ایالات متحده نیز، در صورتی که ارائه‌دهنده یک شرکت آمریکایی باشد، شما را از این قانون مصون نمی‌دارد.

میزبانی در تگزاس به معنای قرار گرفتن تحت قوانین حریم خصوصی تگزاس نیست. قانون TDPSA (قانون حریم خصوصی و امنیت داده‌های تگزاس) که از 1 ژوئیه 2024 اجرایی شده است، برای کسب‌وکاری اعمال می‌شود که در تگزاس فعالیت می‌کند یا محصول یا خدماتی را به ساکنان تگزاس می‌فروشد و طبق تعریف Small Business Administration فدرال، یک کسب‌وکار کوچک محسوب نمی‌شود. این قانون مشتریان شما را دنبال می‌کند، نه رک سرور شما را. انتقال سرور به شیکاگو شما را از این قانون معاف نمی‌کند و انتقال آن به دالاس نیز شما را مشمول آن نمی‌سازد.

برای داده‌های شخصی مربوط به اتحادیه اروپا، میزبانی در ایالات متحده در صورت داشتن یک مکانیسم انتقال داده مجاز است. از اوت 2026، تصمیم کفایت چارچوب حریم خصوصی داده‌های اتحادیه اروپا و ایالات متحده (EU to US Data Privacy Framework) همچنان معتبر است؛ این تصمیم در سپتامبر 2025 توسط دادگاه عمومی اتحادیه اروپا تایید شد و درخواست تجدیدنظری در دیوان دادگستری در جریان است. اقدام عملی این است که از ارائه‌دهنده خود به‌صورت کتبی بپرسید که آیا تحت این چارچوب خوداظهاری کرده است یا بندهای قراردادی استاندارد (SCC) را امضا می‌کند، سپس پاسخ را در جایی بایگانی کنید که حسابرس شما به آن دسترسی داشته باشد. سایر جنبه‌های حقوقی را به یک وکیل بسپارید، زیرا این حوزه دائماً در حال تغییر است.

نحوه تست یک VPS در دالاس از سیستم شخصی

تمام اعداد بالا اندازه‌گیری‌های دیگران هستند. عدد شما همان چیزی است که تصمیم نهایی را تعیین می‌کند و جمع‌آوری آن حدود بیست دقیقه زمان می‌برد.

1. از ارائه‌دهنده بخواهید یک IP تست و یک فایل تست در دیتاسنتر دالاس به شما بدهد. اکثر آن‌ها یک صفحه Looking Glass دارند که هر دو را در اختیار می‌گذارد.
2. از هر شبکه‌ای که کاربران شما در آن حضور دارند، حداقل 20 پینگ ارسال کنید و خط خلاصه (summary line) را بخوانید.
3. مسیر را Trace کنید و تعداد شبکه‌هایی که از آن‌ها عبور می‌کند را بشمارید.
4. فایل تست را دانلود کنید و سرعت پایدار را مشاهده کنید.
5. این کار را در ساعات اوج مصرف کاربران خود، در یک عصر روز کاری و در طول حداقل دو روز تکرار کنید. ازدحام شبکه ساعت 9 شب خود را نشان می‌دهد، نه ساعت 11 صبح.

ping -c 20 203.0.113.10
mtr -rwzc 100 203.0.113.10
curl -o /dev/null -s -w 'connect=%{time_connect}s ttfb=%{time_starttransfer}s speed=%{speed_download} B/s\n' "https://<test file host>/100mb.bin"

در ویندوز اولین دستور ping -n 20 203.0.113.10 است. خط خلاصه‌ای که در پایان پینگ ظاهر می‌شود، همان چیزی است که باید نگه دارید:

rtt min/avg/max/mdev = 34.112/34.905/41.203/0.884 ms

مقدار mdev (انحراف معیار) را به عنوان Jitter در نظر بگیرید. میانگین 35 میلی‌ثانیه با mdev کمتر از 2 میلی‌ثانیه، یک مسیر تمیز است. همان میانگین 35 میلی‌ثانیه با mdev برابر 20 میلی‌ثانیه به این معنی است که بخشی از مسیر ناپایدار است و در هر کار تعاملی، حس بدتری نسبت به یک مسیر ثابت 60 میلی‌ثانیه‌ای خواهد داشت. از دست رفتن بسته (Packet loss) بیش از صفر در هاپ نهایی، اگر در طول 100 بسته تداوم داشته باشد، یک نقص فنی است نه یک نوسان عادی.

میزان توان عملیاتی (Throughput) به تست متفاوتی نیاز دارد. یک اتصال TCP در یک مسیر طولانی توسط پنجره دریافت (receive window) تقسیم بر زمان رفت و برگشت (RTT) محدود می‌شود، بنابراین یک دانلود تک‌رشته‌ایِ کند، ثابت نمی‌کند که لینک ضعیف است. به جای آن از جریان‌های موازی استفاده کنید. دستور iperf3 -s را روی VPS اجرا کنید، آن پورت را فقط برای آدرس خودتان باز کنید، سپس از سیستم خود دستور زیر را بزنید:

iperf3 -c 203.0.113.10 -P 4 -t 30
iperf3 -c 203.0.113.10 -P 4 -t 30 -R

-P 4 چهار جریان موازی باز می‌کند و -R جهت را معکوس می‌کند، بنابراین اجرای دوم، مسیر دانلودی که کاربران شما واقعاً استفاده خواهند کرد را اندازه‌گیری می‌کند. پس از پایان کار، پورت را دوباره ببندید، زیرا iperf3 هیچ احراز هویتی ندارد.

شبکه تنها یک محور است. CPU steal و سرعت دیسک محورهای جداگانه‌ای هستند و یک پلن ارزان در موقعیت مکانی عالی، همچنان در صورت oversell بودن سرور میزبان، کند عمل می‌کند. پیش از انتقال هر داده واقعی، مراحل نحوه بنچمارک گرفتن از VPS را انجام دهید و سپس ده دقیقه اول روی یک VPS جدید را صرف ایمن‌سازی آن کنید.

FAQ

آیا یک VPS در دالاس برای کاربران هر دو ساحل ایالات متحده به اندازه کافی سریع است؟

بله، برای همه موارد به جز بازی‌های بلادرنگ و معاملات حساس به تأخیر. زمان رفت و برگشت (RTT) معمول در شبکه کابلی از دالاس تا نیویورک حدود 36 میلی‌ثانیه و تا لس‌آنجلس حدود 35 میلی‌ثانیه است، بنابراین هیچ کاربری در ایالات متحده قاره‌ای از سرور دور نیست. سروری در شمال ویرجینیا برای نیویورک با حدود 10 میلی‌ثانیه عملکرد بهتری دارد، اما برای لس‌آنجلس با حدود 62 میلی‌ثانیه عملکرد بسیار ضعیف‌تری خواهد داشت. زمانی که می‌خواهید بدترین حالت تأخیر کوچک باشد، نه میانگین پایین، دالاس را انتخاب کنید.

آیا شبکه برق تگزاس باعث کاهش پایداری یک VPS در دالاس می‌شود؟

شبکه ERCOT یک شبکه مجزا با حدود 1.2 گیگاوات اتصال جریان مستقیم به همسایگان خود است، بنابراین تگزاس نمی‌تواند در زمان کمبود، برق زیادی وارد کند. طوفان زمستانی Uri در فوریه 2021 به همین دلیل باعث روزها قطعی برق چرخشی شد. آپ‌تایم شما بیشتر از شبکه به ساختمان بستگی دارد، زیرا باتری‌های UPS بار را برای چند دقیقه تحمل می‌کنند و ژنراتورهای دیزلی تا زمانی که سوخت موجود باشد، آن را تأمین می‌کنند. از ارائه‌دهنده در مورد مدت زمان کارکرد ژنراتور در بار کامل با سوخت موجود در محل و تاریخ آخرین تست بار کامل سؤال کنید.

آیا گردباد یا موج گرمای تگزاس سرور من را از دسترس خارج می‌کند؟

به خودی خود خیر. گردباد EF3 که در 20 اکتبر 2019 از شمال دالاس عبور کرد، مراکز خرید و خانه‌ها را ویران کرد، اما یک سالن دیتاسنتر که با هدف خاص ساخته شده، سازه‌ای بتنی و بدون پنجره است که برای تحمل آن باد طراحی شده است. بخش‌های در معرض خطر، واحدهای خنک‌کننده روی پشت‌بام هستند که در معرض تگرگ‌های بزرگ بهاری نیز قرار دارند. گرما بیشتر از اینکه آپ‌تایم را تهدید کند، هزینه ایجاد می‌کند، زیرا سیستم خنک‌کننده برای گرم‌ترین روزهای سال طراحی شده است؛ هرچند خرابی سیستم خنک‌کننده در طول موج گرما، زمان واکنش کارکنان را بسیار کاهش می‌دهد. نسخه‌های پشتیبان را در منطقه دیگری نگهداری کنید، زیرا ریسکی که نمی‌توان برای آن طراحی کرد، از دست رفتن کل سایت است.

اگر کاربران من در اروپا هستند، آیا باید در دالاس میزبانی کنم؟

خیر. یک سرور در دالاس به فرانکفورت در حدود 125 میلی‌ثانیه و به لندن در حدود 112 میلی‌ثانیه پاسخ می‌دهد و این فاصله ناشی از مسافت است، بنابراین هیچ تغییری در پیکربندی شما آن را برطرف نمی‌کند. نزدیک به کاربران خود میزبانی کنید و یک سرور در دالاس برای کارهایی که کسی منتظر آن‌ها نیست، مانند پشتیبان‌گیری یا پردازش‌های دسته‌ای (batch jobs)، نگه دارید. اگر داده‌های شخصی اروپایی در میان باشد، یک موقعیت مکانی در اتحادیه اروپا، مسئله انتقال داده را که در غیر این صورت باید مستند کنید، حذف می‌کند.

چگونه قبل از خرید، تأخیر (latency) به یک VPS در دالاس را اندازه بگیرم؟

یک آدرس IP تست از ارائه‌دهنده بگیرید، سپس ping -c 20 و mtr -rwzc 100 را از هر شبکه‌ای که کاربران شما استفاده می‌کنند، روی آن اجرا کنید. در خلاصه دستور ping، میانگین را همراه با مقدار mdev بخوانید: میانگین پایین با mdev بالا به معنای وجود جیتر (jitter) است که از یک عدد ثابت بالاتر، آزاردهنده‌تر است. این کار را در ساعات شلوغی عصر کاربران در طول دو روز تکرار کنید، زیرا ازدحام شبکه یک مشکل وابسته به زمان است. برای اندازه‌گیری پهنای باند از iperf3 با چهار جریان موازی استفاده کنید، زیرا یک جریان TCP در یک مسیر طولانی، توسط اندازه پنجره (window size) محدود می‌شود، نه توسط پهنای باند لینک.