Я в рассоле. Я думал, что мой сервер находится в Канаде, но оказалось, что он находится во Франции. У меня сейчас нет времени на миграцию сервера (конечная цель - 75%, если посетители из США).
Используя тест скорости веб-сайта на pingdom, время ожидания первого байта составляет около 140 мс, когда я тестировал его из Швеции. Когда я тестирую из Калифорнии, это около 680 мс. Мне нужно попытаться уменьшить это количество, поскольку Google утверждает, что сканирование сайта выполняется медленно, и в целом большинство посетителей из США, поэтому мне нужно улучшить их опыт.
Cloudflare кэширует статические ресурсы, поэтому, хотя задержка также находится в области 600+ для css, js и изображений, они падают сразу после того, как Cloudflare выбирает файлы. Сейчас я сосредоточен на файлах php.
Я не могу использовать nginx, так как не могу сделать 100% кеш HTML через прокси. Однако я могу использовать redis для кеширования 99% HTML. Я обновился до php7, и теперь Apache работает с ним через быстрый CGI. Я сделал сайт настолько быстрым, насколько это возможно, с тяжелым кэшированием памяти и избавлением от всех неиспользуемых модулей и т.д. HTML-кеш. Однако, если я смогу избавиться от части этой 600-миллисекундной задержки, я буду на лету.
Помимо владения сервером в ЕС и США и использования балансировщика нагрузки, что я могу сделать, чтобы ускорить работу пользователей из США и избавиться от некоторых из этих требований?
Я запускаю Centos 7 с Apache 2.4 и php7 (быстрый CGI) через соединение 100 МБ на сервере во Франции. Сервер выделен с оперативной памятью 16 ГБ и 4-ядерным процессором xeon с 8 потоками @ 2,4 ГГц.
Время отклика, о котором вы говорите, кажется чрезмерным. Сначала я хотел бы проверить, насколько быстро могут быть получены ответы, когда сеть исключена из уравнения.
Попробуйте запустить команду на самом сервере, чтобы загрузить страницу, и посмотрите, сколько времени это займет. Если вы хотите рассчитать время для одного ресурса, вы можете легко сделать это, используя wget или curl. Если вам нужно что-то, что может идентифицировать все ресурсы, необходимые для рендеринга страницы и их загрузки, вам нужно изучить другие инструменты.
Чтобы измерить, какая задержка у вас есть, попробуйте использовать один эхо-запрос ICMP из точек по всему миру на ваш сервер, чтобы увидеть, сколько времени добавляет только сеть. Есть множество сайтов, которые могут сделать за вас такую проверку.
Даже если содержимое не может быть кэшировано, есть потенциальная выгода от установки прокси перед сервером. Прокси-сервер может быть расположен рядом с пользователями, и прокси-сервер может заранее установить https-соединение с внутренним сервером, так что пользователям нужно будет ждать только одного обратного прохода по трансатлантической ссылке, а не двух или более, необходимых, если соединение должен быть настроен, когда пользователь начинает загружать страницу.
Более того, когда вы управляете сервером на каждом конце соединения, вы будете в лучшем положении для измерения двустороннего трафика, джиттера и потерь пакетов в соединении через Атлантику. Возможность его измерить - это первый шаг к возможности его улучшить.
Наконец, узнайте, сколько циклов туда и обратно добавляет структура вашей страницы к загрузке всех ресурсов. Прокси-сервер может сократить количество обращений к каждому ресурсу, но структура страницы определяет, сколько файлов можно загрузить параллельно. Например, если страница ссылается на файл javascript, и этот сценарий затем загружает изображение при запуске, вам потребуется как минимум три обхода, потому что браузер не может начать загрузку следующего, пока не будет предыдущее.