Я размещаю зашифрованную базу данных SQL-сервера (SQL Server 2012) на хосте VMware в моем местоположении в Солт-Лейк-Сити. Мой канал передачи данных в Солт-Лейк-Сити - 100 Мбит / с по оптоволокну через Comcast. На моей стороне Phoenix есть 50 Мбит / с по оптоволокну через Cox. Моя задержка между сайтами составляет 45 мс. В каждом офисе около 40 пользователей. 20 пользователей входят в наше приложение электронного управления из Феникса и около 20 входят в систему со стороны Солт-Лейк-Сити.
Пользователи LAN в Солт-Лейк-Сити, использующие E-manage, не имеют проблем со скоростью, однако мои пользователи LAN Phoenix сообщают о медленном доступе при работе с приложением E-manage. Разработчик считает, что проблема связана с использованием виртуализации (VMWare ESxi 5.5). Когда я изучаю использование ресурсов VMware и моей SAN, я вижу, что все ресурсы (ЦП, ОЗУ и т. Д.) В основном спят. У меня были отчеты о пропускной способности для Cox и Comcast, и моя пропускная способность находится в пределах нормы. Других проблем с замедлением работы внутренних приложений у меня нет.
Я открыл билеты с Comcast и Cox, чтобы посмотреть, что можно сделать, чтобы уменьшить задержку с 45 мс до высоких 20 и низких 30. Я чувствую, что это изменит ситуацию. Я использую ускорители WAN на обеих сторонах сети для ускорения трафика TCP и исключаю трафик SQL. Чтобы исключить сеть Phoenix, я попросил пользователя подключить ноутбук непосредственно к оптоволоконной сети Cox, а затем использовать E-manage. Те же результаты. Время отклика было медленным. У меня есть туннель IPSec между сайтами, и, чтобы исключить туннель IPSec, я изменил запись Phoenix DNS, чтобы использовать общедоступную запись A, которую я настроил для своего SQL-сервера.
Я попросил разработчика SQL предоставить контакт с другим клиентом, чтобы я мог видеть, каково их время доступа / ответа при работе с удаленного сайта. Я был бы рад предоставить более подробную информацию, чтобы увидеть, что мне не хватает. Я также рассмотрел возможность запуска независимых SQL-запросов от третьей стороны, чтобы узнать, в каком состоянии находится мой SQL-сервер и есть ли какие-либо потенциальные проблемы с базой данных SQL.
У меня есть физический сервер, который я собираюсь настроить, чтобы посмотреть, будет ли это иметь значение.
Я с нетерпением жду любых комментариев, предложений и советов.
Заранее спасибо - Трой
IMO (и у меня нет никаких эмпирических данных) запуск приложения на основе SQL через соединение WAN редко работает хорошо с точки зрения производительности. Существует несколько уровней, которые могут вызывать проблемы для пользователей WAN, которые не будут очевидны для пользователей LAN; задержка приложения, задержка шифрования SQL, задержка операционной системы, задержка сети и т. д. При прочих равных, как вы заявили, задержка в сети, вероятно, является тем местом, где проблема проявляется с точки зрения пользователя. Если у вас нет выделенного частного соединения между двумя точками от одного и того же провайдера, вероятно, никто ничего не сможет сделать. У них есть контроль только над собственной сетевой инфраструктурой, но не друг над другом и, конечно же, не над чем-либо промежуточным. Ваша задержка не кажется мне слишком ужасной, поэтому мне было бы интересно узнать, какая потеря пакетов (если таковая имеется) происходит между двумя офисами.