Назад | Перейти на главную страницу

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

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

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

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

Стек серверов Winni:

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

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

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

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

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

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