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