У нас есть устаревшее веб-приложение, которое работает в нашем центре обработки данных в Хьюстоне. Мы разработали новое веб-приложение на основе .net 4, чтобы предоставить клиентам новые функции. Новое веб-приложение размещено в среде amazon aws ec2 (регион Северная Вирджиния, зона us-east-1b).
Чтобы легко интегрироваться с унаследованным приложением, новое веб-приложение выполняет вызовы веб-службы для получения данных. Мы наблюдаем необычно высокое время задержки, порядка 5+ секунд для этих вызовов веб-служб. Тот же самый вызов веб-службы возвращается менее чем за секунду на наших локальных ПК (что имеет смысл, учитывая физическую близость к фактическому серверу). Странно то, что у нас есть разработчики в Калифорнии, у которых также время отклика в миллисекундах. Мы тестируем ответ веб-службы с использованием сторонних инструментов, таких как SoapUI, расширений Google Chrome, таких как Advanced REST Client, Postman REST Client и т. Д.
Как будто это не было достаточно странно, мы заметили такую же низкую задержку у некоторых других экземпляров ec2 во время тестирования, которые также находятся в том же регионе и зоне доступности. Если бы мы постоянно испытывали высокую задержку во всех экземплярах ec2, я мог бы понять. Но происходит кое-что еще.
Сравнение различных статистических данных и результатов между серверами ec2 с низкой и высокой задержкой не показывает каких-либо существенных различий: ping (постоянные 40 мс), tracert, winmtr и т. Д.
У нас есть экземпляры, которые тоже есть в VPC. Итак, я попробовал использовать как общедоступный, так и частный IP-адрес хост-сервера веб-службы, и это не повлияло ни на приведенные выше результаты.
Нам необходимо решить эту проблему с задержкой, поскольку это приводит к очень медленной загрузке результирующих веб-страниц (почти 15+ секунд, что просто неприемлемо).
Экземпляры ec2 имеют 64-разрядную версию Windows Server Datacenter. Сообщите мне, есть ли еще информация, которую я могу предоставить, чтобы помочь в диагностике.
Во-первых, это похоже на то, что вам придется устранять неполадки с Amazon. Простая трассировка к вашему целевому хосту покажет вам, где находится задержка.
Во-вторых, вы должны спроектировать свое приложение так, чтобы оно загружало страницу и отображало данные всякий раз, когда они становятся доступными, а не просто ожидать их появления. Мне кажется, что вы не использовали отработку отказа AJAX в своем приложении. Как вы можете быть уверены, что ваше новое приложение ВСЕГДА будет иметь соединение с вашим устаревшим приложением.
TL; DR: Запустите tracert, позвоните в Amazon, проверьте свой код, убедитесь, что он допускает задержки и отсутствие сценариев подключения к Интернету.
Задержка в 5+ секунд выглядит редким, но не необычным событием. Попробуйте использовать что-то вроде iperf, чтобы проверить пропускную способность между вашим центром обработки данных в Хьюстоне и экземпляром ec2 в Вирджинии. Если это поможет, вот некоторые из недавно проведенных нами измерений пропускной способности между двумя регионами Амазонки (восток и запад), а также между этими регионами и хостом нашего центра обработки данных в Калифорнии:
ec2-east -- ec2-west: 25.75 +-7.96
ec2-east -- localhost: 665.0 +-104.5
ec2-west -- localhost: 79.35 +-4.38
Все числа в Мбит / сек, измерены более двадцати раз и усреднены. + - это стандартное отклонение.
Надеюсь это поможет.