Все время соединения связано с проблемой задержки?

Вопрос к серверу: я работал над увеличением скорости веб-сайта https://www.winni.in/ и я столкнулся с очень странным явлением. Если кто-то может, пожалуйста, объясните об этом.

Я сравнивал время загрузки Winni и Snapdeal и обнаружил, что где Winni занимает в среднем 450 мс времени соединения, тогда как snapdeal занимает в среднем всего 30 мс времени соединения. Хотя оба сайта размещены в сингапурском регионе AWS. Я предположил, что это время соединения из-за задержки, как будто я получаю доступ к Winni из Индии или Австралии, тогда оно падает примерно на 150 мс или меньше, но мгновенно (www.snapdeal.com) всегда ниже 30 мс независимо от того, из какого географического местоположения вы к нему обращаетесь.

Я прилагаю скриншоты, сделанные из pingdom для Winni и Snapdeal, показывающие время подключения при тестировании из Нью-Йорка. Есть ли в AWS что-то, чего нам не хватает, что могло бы сократить время подключения или это из-за какой-то проблемы конфигурации сервера.

Серверный стек Winni:

  1. EC2 - сингапурский SSD жесткий диск 2-ядерный процессор
  2. Nginx
  3. Кот
Источник

1 ответ

Решение

Задержка может сыграть значительную роль в производительности сайта, но это не вся причина. Время генерации страницы - еще один важный фактор. Для настройки HTTPS требуется несколько циклов, поэтому задержка может сыграть существенную роль. HTTP/2 справляется с этим, устанавливая соединение один раз на сервер и передавая файлы параллельно.

Другое решение или обходной путь - использовать сеть распространения контента, что делает Snapdeal - они используют Akami, один из старейших и наиболее известных CDN. Наверное, это тоже один из самых дорогих. Доступны десятки CDN - Max, CloudFront и т. Д.

Вы можете использовать CloudFlare, который является бесплатным CDN и хорошо работает с AWS. Обычно страницы все еще загружаются с вашего сервера, поэтому задержка для первой страницы не будет уменьшаться, а задержка для извлечения статических ресурсов будет уменьшаться. У вас могут быть страницы кэширования CF, но если пользователи могут войти в систему, это не практично - вы не хотите, чтобы пользователи, не вошедшие в систему, видели страницу, кэшированную из личного сеанса пользователя, вошедшего в систему. Еще одним преимуществом использования CloudFlare является то, что они автоматически выполняют HTTP / 2 для вас, если вы позволите.

Чтобы набрать 30 мс, независимо от того, откуда вы получаете доступ, они должны кэшировать свои страницы на Аками. Akami, вероятно, немного умнее, чем CloudFlare, свободно использует кэширование страниц, например, не кэширует их, если отправляется определенный файл cookie, или это POST. Они могут поочередно иметь серверы приложений во многих периферийных точках Akami.

Я написал небольшое руководство по производительности AWS/Nginx здесь. Я опубликую заключительную часть на CDF CloudFlare, когда у меня будет немного больше времени, но это не так сложно настроить.

Источник
Другие вопросы по тегам