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

Измерьте скорость загрузки между клиентом и нашим сервером

Мы размещаем приложение SAAS, специально настроенное для нескольких клиентов. В частности, для одного клиента - они сообщают о спорадических проблемах с производительностью из разных мест в своей сети, в частности, ЗАГРУЖАЯ документы через форму на нашем веб-сайте.

Клиент утверждает, что у него есть «лишняя пропускная способность» и что использование их «канала» настолько низкое, что это ДОЛЖНО быть нашим приложением, но у нашего приложения МНОГО клиентов, и все функции работают нормально для всех других клиентов.

Достаточно интересно -

ЗАГРУЗКА (т.е. просто доступ к веб-сайту или загрузка документов) работает нормально.
Тест скорости показывает, что они должны подняться на 1,2 Мбит / с. Таким образом, загрузка файла размером 3 МБ должна занять 20 секунд. В их сети это занимает более 60 секунд. Иногда загрузка даже небольших файлов занимает более 10 минут или время ожидания истекает.
Ping и Traceroutes не показывают аномально длинных переходов или времени отклика.
Они утверждают, что другие приложения SAAS, которые они используют, позволяют им загружать файлы без проблем.

Обе ИТ-группы работают вместе, чтобы решить эту проблему. Какие данные я могу запросить у клиентов, чтобы начать исключать ситуацию.

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

С чего мне начать? Любая помощь приветствуется. Я предоставлю дополнительную информацию по запросу

Периодические проблемы с производительностью могут быть настоящим ужасом для отслеживания, как вы, наверное, уже заметили. Когда я борюсь с подобными проблемами, я обычно пытаюсь изолировать различные задействованные системы и исследовать каждую по очереди:

Попросите клиента использовать «чистую» систему. Нет AV / AM / смотри, что-наши-сотрудники-делают-приложение-2012. Попросите клиента записывать, когда он замечает необычное поведение. (Это покрывает большинство ошибок конфигурации на стороне клиента)
Проведите долгосрочное (24 часа +) непрерывное измерение связи с клиентом и от клиента (если возможно). ICMP - достойный, но не идеальный выбор. Есть много специализированных инструментов, которые можно использовать. Убедитесь, что вы выполняете измерения с большими кадрами, поскольку проблемы MTU пути не являются необычными, когда речь идет о плохой производительности. (Это покрывает большинство сетевых ошибок)
Внимательно изучите журналы своей ОС (и гипервизора, если он виртуализирован). Будьте особенно осторожны со статистикой, связанной с производительностью, такой как использование памяти, потерянные сетевые кадры и использование ЦП. Если вы еще не ведете их, начните регистрировать прямо сейчас. Наличие исходного показателя для сравнения делает жизнь намного проще. (Это устраняет многие аппаратные и программные проблемы)
Как предлагает joeqwerty, попросите ваш веб-сервер и базу данных регистрировать любые длительные запросы. (Помогает определить, действительно ли проблема в вашем приложении)