Назад | Перейти на главную страницу

Выявление проблем с пропускной способностью канала, не находящегося под нашим контролем

Наша компания размещает веб-сайт вне нашего офиса, на нем размещается сайт, некоторые загрузки и тонны обучающих видео. Сам сервер представляет собой Poweredge1900, на котором работает 64-битный веб-сервер 2008, двухъядерный процессор и 16 ГБ оперативной памяти.

Здание, в котором мы находимся, предоставляет нам доступ к интернету как часть арендной платы. Проведение спидтеста в любой день обычно дает скорость не менее 14 Мбит / с, пинг 5 мс, так что не так уж плохо. Наше здание является сестринским зданием университета, поэтому его половина технологических предприятий и половина классных комнат, а пропускная способность обеспечивается главным зданием университета через оптоволокно.

Иногда у нас возникают проблемы с тем, что Интернет смертельно медленный, и наши клиенты жалуются на то, что наши обучающие видео прерывистые, медленно загружаются и т. Д. Выполнение спидтеста в это время по-прежнему приводит к высокой скорости и низкой задержке. Сервер также не показывает дополнительной нагрузки или индикации проблем.

В принципе, я почти уверен, что проблема не в нас, поскольку к нам приходят 2 разных общедоступных IP-адреса, наша сеть бэк-офиса находится в одной физической сети, а веб-сайт сам по себе, и производительность падает на обоих одновременно. Как я могу собрать данные, чтобы подтвердить связь?

У нас возникла проблема с исходящим интернет-провайдером, «формирующим» трафик и вызывающим проблемы с нашим трафиком VPN между сайтами.

http://www.measurementlab.net/measurement-lab-tools#diffprobe

Мы использовали инструмент ShaperPrope для определения вышестоящего интернет-провайдера, и, похоже, ситуация улучшилась, когда мы смогли определить вовлеченного интернет-провайдера. Они отрицали любые подобные манипуляции.

В то время наш основной интернет-провайдер предположил, что некоторые другие формируют видео- и аудиопотоки.

Удачи

Расширяя мой комментарий к ответу Дэйва М, если вы имеете дело с формированием трафика здесь, оно может применяться только в определенное время дня или когда канал достигает определенного уровня трафика в течение длительного времени.

Другая теория - вашему результату спидтеста может мешать прозрачный прокси-сервер. Эта теория предполагает, что скопление должно быть за пределами где бы ни находился этот теоретический прозрачный прокси.

Хороший и простой способ сделать это, на мой взгляд, бесплатный ...

  1. Получите машину вне сети в Интернете
  2. Позвольте ему сделать "дыру" через брандмауэр в вашем сервере ... даже если это означает соединение VPN ... это было бы "нормально" (хотя и не идеально)
  3. Получите Qcheck бесплатно (http://www.ixchariot.com/downloads/qcheck.html) и установить как на клиенте, так и на сервере.
  4. Ставить http://www.numion.com/stopwatch/index.html в закладках вашего клиента.

Теперь ... сделайте базовый тест Qcheck (тесты пропускной способности и время отклика) и таймер загрузки секундомера numion на веб-сайте в обычное время. Сделайте это 2 или 3 раза, чтобы получить точные измерения для базовой линии.

Затем ... когда появится сообщение о "замедлении", снова запустите Qcheck и сайт таймера и посмотрите, в чем разница.

ЭТО ^^^, по крайней мере, подтвердит ваши проблемы.

Для устранения основной причины вам необходимо начать разбивать сегменты (сервер на брандмауэр, сервер для переключения, переключиться на брандмауэр, брандмауэр на ISP и т. Д.) И выполнить аналогичные тесты или проверку потери пакетов и т. Д. На этих сегментах. сегменты, чтобы попытаться сузить, где находится виноват.

Мы выяснили, что восходящий поток Интернет-провайдера выполнял некоторое регулирование / формирование. Спасибо за ответы.