Здесь немного другая картина, соотношение принятых и отправленных пакетов 2823/1412=2 т.е. 2 принятых на 1 отправленный. Средний размер пакета приема 211601/2823=74 байта, средний размер пакета отправки 129921/1412=92. Т.е. здесь используются еще более маленькие пакеты, но соотношение принятых и отправленных пакетов другое.
Из примеров можно сделать вывод, что передача идет по принципу запрос-ответ (как в утилите ping). Если в сети большая задержка на передачу пакета, то она будет накладываться на каждый цикл запрос-ответ.
III Этап
Теперь командой hrping определяем задержку (для пакетов ping мы будем ее называть временем двойного пробега) на пакеты, длину которых мы определили ранее 74, 92, 670, 116 байт.
Используем команду hrping -L 74 -s 5 -n 1000 10.170.3.107 >> d:\temp\p74.txt
Где
-l задает полный размер пакета без накладный 28 байт.
- s время следования пакетов
Всего статистика из 1000 пакетов.
Файлы прилагаются
, на основе их можно построить диаграмму в Excel, которая показывает отсортированное по возрастанию время задержки пакетов.
Можно получить предварительные результаты проанализировав диаграмму.
Для MS SQL server показатели неплохие, время двойного пробега равномерное, только на первых двух пакетах большое время ответа, но этим можно пренебречь.
Для сервера Novell ситуация гораздо хуже. Во-первых, около 10% пакетов идет с очень большим временем двойного пробега. Во вторых, можно сравнить min/avg/max значения
Для MSSQL сервера RTTs of replies in ms: min/avg/max: 0.467 / 0.491 / 8.665, т.е. среднее значение практически не отличается от миниального
Для сервера Novell RTTs of replies in ms: min/avg/max: 0.314 / 9.501 / 296.594 отличие среднего значения от минимального в 30 раз. При этом из статистики видно, что сервер может отвечать быстро (0.3 мс).
Почему так произошло, это вопрос либо администраторам сети, либо к администратору сервера, возможно сетевая карта сервера перегружена в определенные моменты времени, возможно сам сервер занят и не дает приемлемого времени ответа. Наша задача показать на каком уровне проблема, а не почему так произошло. А где кончается сеть и начинается сервер??? (смайл)
IV Этап
Как видно, анализ на этапе III всего лишь предварительный. Возникает вопрос: Для MS SQL сервера время двойного пробега 0.491 мс на пакета 670 байт нормально?
С теоретической точки зрения на сети 100 мегабит без промежуточных задержек такой пакет должен передаваться туда и обратно за Формула (2* (1сек / число пакетов в сек длиной 670 байт ) =2* 1/(12 500 000/670)=0.107 мс
Реально многое зависит от сети и загруженности пк (т.е. как скоро он может ответить).
Для этого можно провести следующий эксперимент - соединить два ПК кросскабелем, и выполнить hrping. (Примечание Кросскабель это немного другая распайка сетевого кабеля, которая позволяет соединять два ПК без концентратора). Так как задержки концентраторов, маршрутизаторов будут исключены, мы получим реальные цифры, к которым следует стремиться.
На практике для двух карт Full Duplex 100 мбит\с , соединенных кросскабелем, время задержки 0.2 мс для пакета 670 байт.
Что бы не думать о миллисекундах с высока можно сравнить теоретические расчеты с практическими измерениями.
Рассмотрим пример c MS SQL Server:
Среднее время задержки для пакета приема 670 байт равно 0.491мс/2=0.245мс для пакета отправки 116 байта 0.344/2=0.172мс
По статистике из раздела II мы знаем, что на каждый отправленный пакет приходится один принятый. Следовательно, за одну секунду мы можем принять 670байт*1с/ (0.000245с+0.000172с+х)=714760байт где x время обработки записи на клиенте и сервере. В данном случае X=0.52 мс.
А какая могла бы быть скорость - если задержка была в как в сети с кросскабелем. В нашем случае. возьмем задержку на пакет в 2 раза меньше.
Получим 670байт*1с/(0.000123с+0.000086с+0.00052с)=919067 т.е. фактически разница на 30%!
Очевидно, что если на 1 отправленный пакет будет 2 принятых показатели будут другими. Но в любом случае их можно посчитать, пользуясь указанной методикой. Здесь наглядно показано, что разница в 0.1 мс на пакет уже существенно влияет на производительность. Проблемы с задержкой возникают именно в том случае, когда мы на отправленный пакет ждем пакет приема.
Но данных показателей недостаточно, наиболее объективны интегральные показатели.
