Запис затримки між керованою початковою точкою та неконтрольованою кінцевою точкою

Це може бути дуже основним питанням усунення несправностей, але варто попросити переконатися, що я перевіряю речі правильним способом та ефективно інтерпретую результати.

У мене є контрольована початкова точка (кластер сервера під моїм контролем) і неконтрольована кінцева точка (центр обробки даних, до якого я не маю фізичного або віддаленого доступу). У рамках звичайного усунення несправностей мені часто потрібно встановити номери затримки.

В даний час я використовую пінг-плотер або просто старий старомодний безперервний pingабоtracert

Якщо я намагаюся встановити більш реалістичні цифри від кінця до кінця (програмне забезпечення, з яким я працюю, це програмне забезпечення для баз даних), я іноді використовую Fiddler 2 для зйомки веб-трафіку та порівняння деяких таймерів там (таких як ClientDoneRequest-> ServerBeginResponse) з отримати повний час до кінця.

Що ви, хлопці, дивитесь, визначаючи числа для прямої мережевої затримки?

Остання половина вашого запитання, схоже, вказує на те, що ви шукаєте показники затримки, які враховують процес формування даних на рівні додатків, і в цьому випадку "ping" не допоможе сильно, враховуючи, що в ping не буде сформовано багато даних. пакет.

Мережі зазвичай покладаються на ping, оскільки це відносно легкий і надійний спосіб отримати певну кількість випадкових даних для перевірки доступності та затримки для певного шляху. Наприклад, програма, яка використовує дзвінки HTTP, поводитиметься по-різному, оскільки HTTP не є тим самим, що й ICMP.

Якщо ви переймаєтесь загальними показниками затримки в мережі, поза будь-яким контекстом програми (що є найкращим способом тестування), ping працює чудово.

Чи є у вас можливість використання IP SLA між двома маршрутизаторами в кожній точці? Я не впевнений у вашій топології на віддаленому кінці, тому не впевнений, чи є у вас сервер з іншого боку, чи цей сервер підключається до маршрутизатора, який теоретично міг би запустити IP SLA

Я просто хочу згадати пару речей. Затримка може сильно залежати від вашого господаря. Переконайтеся, що це сервер, з якого ви тестуєте, а не ваш ноутбук. Залежно від операційної системи (Windows або Linux) час затримки пінг може бути різним. У мене був досвід, коли системи Windows демонстрували повільніші затримки, ніж системи Linux через ті самі мережеві шляхи.

Пінг як розумний тест. Однак якщо ви зможете зробити сеанс TCP від ​​свого сервера до кінцевої точки в цьому центрі обробки даних, ви отримаєте більш точні номери, не контролюючи кінцеву точку. Я б запустив захоплення пакетів, поки встановлено ваш сеанс TCP. Потім слідкуйте за потоком TCP і подивіться на свій час дельти. Яка різниця у часі між вашим початковим пакетом TCP та наступною послідовністю? Тобто приблизно в режимі реального часу, яку затримку ви бачите.

Ви намагаєтесь з’ясувати, чи добре працює мережа чи сервери виконують свою роботу?

Затримка може бути смішною річчю - особливо точно. Ping робить досить хорошу роботу для загального уявлення про те, як затримується затримка вашої мережі, але якщо мова йде про дуже низькі числа, це може стати неправильним інструментом для роботи. Він також не робить нічого для тестування більш високого рівня (наприклад, час відгуку веб-сайту).

Для чіткого вимірювання продуктивності мережі (затримка / пропускна здатність / втрати / і т.д.) мені подобається тестовий механізм Exfo . Це просто вподобання, і, чесно кажучи, це перший пристрій, який я використовував, тому впевнений, що конкуруючі пристрої працюватимуть так само добре. JDSU також є основним постачальником цього обладнання.

Існує також PCHAR, який є інструментом з відкритим кодом для точнішого вимірювання затримки, ніж ping. Я безпосередньо не використовував це, але знаю людей, які мають і подобаються.

Ця стаття дає хороший огляд деяких речей, які ICMP Echo може / не може зробити добре.