У меня есть вопрос о сетевом трафике, на который я могу получить много ответов. На работе я подключаюсь к внутренней сети клиента, где у него есть сценическая база данных SQL. Каждый раз, когда я занимаюсь разработкой (исправлениями / улучшениями), мне нравится проводить раунд быстрого контроля качества. Когда я запускаю SQL-запросы в SQL Server Management Studio, все не кажется медленным. Но когда я запускаю их веб-приложение со сценической версией web.config, используя мою локальную сборку, задержка ОЧЕНЬ медленная по сравнению с использованием базы данных SQL для разработчиков нашей компании web.config. файл.
Для сравнения, я начинаю считать 1–1000, 2–1000 и т. Д. Для одной конкретной страницы. Загрузка страницы с нашим dev web.config занимает 1,5 секунды. Но при использовании stage web.config я считал чуть больше 8 секунд. Я начинаю переводить модули приложения на использование AJAX, поэтому я вижу некоторые улучшения на этих страницах, но страницы все еще должны загружаться. Так что это действительно замедлит мое тестирование, если я выпущу большой пакет обновлений.
Если вы можете порекомендовать какие-то инструменты для диагностики этой медлительности / отставания, это то, что меня интересует. Кроме того, если вы можете описать, как я могу это устранить, это то, что я ищу. Я разработчик приложения .NET, а не сетевой администратор, поэтому я не знаю, с чего начать.
===============================================знак равно
Разъяснение сверху (обновление 23.05.2011):
================================================
Судя по всему, SQL Server Management Studio также работает медленно, так что это определенно соединение SQL по сети. Я сделал быстрый пинг на своем локальном сервере, когда VPN подключился к сети, в которой находится ящик * .234 Windows Server 2008. Затем я сделал еще один с другого компьютера в той же сети, что и * .235. Так что, может быть, на это нет ответа. Они используют линию T1, так что может быть проблема. Эти времена от пинга сильно отличаются.
На удаленном рабочем столе на другом компьютере, но на другом сетевом компьютере. Пинг из той же сети, что и ящик * .234:
C: \ Users \ Administrator> пинг 192.168.2.234
Пинг 192.168.2.234 с 32 байтами данных:
Ответ от 192.168.2.234: байты = 32 время <1 мс TTL = 128
Ответ от 192.168.2.234: байты = 32 время <1 мс TTL = 128
Ответ от 192.168.2.234: байты = 32 время <1 мс TTL = 128
Ответ от 192.168.2.234: байты = 32 время <1 мс TTL = 128
Статистика Ping для 192.168.2.234: пакеты: отправлено = 4, получено = 4, потеряно = 0 (потеря 0%), приблизительное время приема-передачи в миллисекундах: минимум = 0 мс, максимум = 0 мс, средний = 0 мс
C: \ Пользователи \ Администратор>
На локальной машине, когда VPN подключился к машине, я пингуюсь. Пинг из другой сети как ящик * .234.
C: \ Windows \ system32> пинг 192.168.2.234
Пинг 192.168.2.234 с 32 байтами данных:
Ответ от 192.168.2.234: байты = 32 время = 856 мс TTL = 127
Ответ от 192.168.2.234: байты = 32 время = 717 мс TTL = 127
Ответ от 192.168.2.234: байты = 32 время = 561 мс TTL = 127
Ответ от 192.168.2.234: байты = 32 время = 708 мс TTL = 127
Статистика Ping для 192.168.2.234: пакеты: отправлено = 4, получено = 4, потеряно = 0 (потеря 0%), приблизительное время приема-передачи в миллисекундах: минимум = 561 мс, максимум = 856 мс, среднее = 710 мс
C: \ Windows \ system32>
Это отличная информация о выполнении многих запросов, но позвольте мне дать вам немного больше информации? Я все еще немного запутался в этом. Я вчера обнаружил кое-что очень интересное И НАСТОЛЬКО ПРОСТОЕ. Забудьте о сценариях файла web.configs. Когда я делаю удаленный рабочий стол и обращаюсь к URL-адресу на удаленном рабочем столе (который является машиной в этой сети, на которой размещены приложение и сервер SQL), это ОЧЕНЬ БЫСТРО (<1 мс) для каждой загрузки страницы. Но когда я подключаюсь через веб-браузер на своем локальном компьютере, это ОЧЕНЬ МЕДЛЕННО (500 + мс). Я пользуюсь VPN в обоих случаях. Мое решение моей проблемы - использовать удаленный рабочий стол. В этом новом сценарии я размещаю веб-приложение на удаленном сервере в сети, в которую я выполняю удаленное подключение. Вот простой вопрос. Почему удаленный рабочий стол такой быстрый? ДОЛЖЕН быть способ имитировать это на моей локальной машине. Почему подключение к удаленному рабочему столу (локально) и открытие веб-браузера локально должно отличаться от просмотра сайта на моем локальном компьютере?
Кстати, о моем первом сценарии ... Я также обнаружил, что параметр реестра "MaxPacketSize" уменьшил мс вдвое. Но дела по-прежнему шли очень медленно.
http://support.microsoft.com/default.aspx?scid=kb;en-us;244474#LetMeFixItMyselfAlways
Когда вы запускаете запрос в SQL Management Studio, вы выполняете один круговой обход. Вы наблюдаете увеличение задержки сети только один раз (например, ~ 500 мс).
В вашем приложении вы, вероятно, выполняете много запросов; каждый из них испытывает одинаковую задержку в последовательном соединении. Так что, если ваше приложение выполняет 10 запросов (или, возможно, имеет некоторую форму запросов основных деталей), вы скоро получите много дополнительных секунд во времени ответа.
Когда вы используете удаленный рабочий стол, на ваш компьютер отправляются только обновления экрана, поэтому трафик, проходящий через VPN, минимален. В этом сценарии вызов базы данных, который вы делаете с удаленного рабочего стола на SQL Server, на самом деле происходит в локальной сети на другой стороне VPN. Ваша машина только что получает изменения экрана удаленного рабочего стола.
Когда вы обращаетесь к сайту через локальный браузер, вы извлекаете весь набор результатов через VPN, что представляет собой гораздо больше данных, чем ваш сеанс удаленного рабочего стола (удаленный рабочий стол довольно эффективен и работает примерно со скоростью 2-10 кбит / с, в зависимости от ваших настроек. ).
Единственный способ ускорить процесс в этом случае:
Все дело в пропускной способности. Если вы не готовы вкладывать серьезные деньги в быстрое сетевое соединение между вами и удаленным хостом, вам будет трудно достичь скорости где-либо в пределах того, что может сделать локальная сеть.