Nginx: Оптимизация времени отклика сервера для кэшированного веб-сайта HTTP

У меня есть веб-сайт, на котором все страницы обслуживаются из http-кэша nginx и редко становятся недействительными или просроченными.

Средний общий размер загрузки страницы составляет около 2 МБ. Но, несмотря на то, что сайт статичный, без какой-либо забавной логики, мой ответ сервера составляет около секунды.

Я записал nginx $request_time и доходит до 400 миллисекунд с сервера

и каждый файл в среднем 20-30 КБ

400 миллисекунд кажутся абсурдными.

Я за Cloudflare и

sendfile        on;
tcp_nopush     off;
tcp_nodelay on;
keepalive_timeout  300s;
keepalive_requests 10000;

Что я должен делать, чтобы снизить время отклика до 150-миллисекундного диапазона?

Изменить: первая часть моего тюнинга.

Понял, что у меня не был включен SSL OSCP. Подправлен код для

# https://github.com/autopilotpattern/wordpress/issues/19
    ssl_session_cache   shared:SSL:50m;
    ssl_session_timeout 1d;

    ssl_certificate /etc/letsencrypt/live/site.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/site.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/site.com/chain.pem;
    ssl on;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
    ssl_prefer_server_ciphers on;
    ssl_stapling on;
    ssl_stapling_verify on;

Я сообщу об улучшении.

Изменить 2:

Вот результат теста веб-страницы для соединения 3G от Индии до сервера на западном побережье США

Источник

2 ответа

В вашей настройке много фундаментально неправильного.

  • Во-первых, вам вообще не нужен NGINX. У вас уже есть система кэширования в Cloudflare, используйте ее. Этот будет намного ближе к пользователю, чем ваш NGINX.

  • Во-вторых, вы заявляете "для попадания 3G-соединения" - вот и все. В Индии плохо со стационарной связью (Индия -> мы... измерьте там чистую задержку пинга из интернет-кафе). 3g сверху как то ужасно старый и медленный. Задержка от 100 до 500 мс согласно https://hpbn.co/mobile-networks/

Вы добавляете это к своим базовым показателям: «Средний общий размер загружаемой страницы составляет около 2 МБ» и «каждый файл в среднем весит 20-30 КБ», и все готово. Браузеры не выполняют слишком много запросов параллельно, а это означает, что вы передаете много файлов по каналу с высокой задержкой.

Ты можешь:

  • Уменьшите РАЗМЕР, но хотя бы
  • Уменьшите количество файлов, что приведет к меньшему количеству рукопожатий.

Но не ждите слишком многого. Обратите внимание, что вы тратите почти 500 мс на поиск DNS согласно вашим измерениям И почти 500 мс на первоначальную настройку соединения И еще 600 мс на подтверждение SSL (между вами и сервером Cloudflare) — это цена установки соединения с высокой задержкой. Ничто не может это исправить. Это 1,5 секунды, потому что я бы сказал, в основном 3g.

Cloudflare сам по себе кэширует, если только у вас не ужасные настройки на вашем веб-сервере — это означает, что вся ваша оптимизация бесполезна, потому что ваш сервер следует затрагивать только изредка. И опять же 3g просто медленный. Почему вы думаете, что мы сейчас на 5G?

Гораздо лучше задать этот вопрос непосредственно в stackoverflow — как можно оптимизировать код вашего веб-сайта, чтобы он был более дружелюбен к соединениям с низкой задержкой. Нравится меньше файлов. А в противном случае просто живите с тем, что «старые технологии неоптимальны».

Источник

Я не думаю, что вы дошли до вопроса оптимизации. Сначала нужно выяснить, куда идет время.

Я не думаю, что вы говорите о времени для отображения в вашем браузере, поэтому пока оставьте ваш браузер вне его. Используйте легкие инструменты командной строки, такие как curl и ab, чтобы собрать информацию о времени. Использование таких инструментов на рабочем столе или на хорошо подключенном сервере, отличном от того, который обслуживает этот сайт, может быть полезно для исключения проблем с локальной системой, сетью или браузером.

Запустите некоторые тесты, используя ab (поставляется с инструментами apache) или curl, запустив их на своем сервере, так что вы уберете сетевые задержки и из-за облачности. вам нужно будет поиграть с опциями, чтобы подключиться к локальному http-серверу, а не к тому, на который указывает DNS, и все же использовать Host заголовок. Как выглядит ваша задержка сейчас? Это должно сказать вам, находится ли проблема на вашем веб-сервере или вне его. Он включает в себя преимущества вашего кэша nginx, но не кэширование из cloudflare.

Если этот бит на вашем сервере быстрый, то вы смотрите на cloudflare и сеть. В противном случае продолжайте смотреть на ваш сервер.

Помимо рассмотрения того, сколько времени занимает запрос с точки зрения клиента, вы также можете изменить формат журнала nginx, чтобы получить больше информации о времени в ваших журналах. Я обычно использую что-то вроде:

log_format  combined  '$remote_addr - $remote_user [$time_local] "$request" '
    '$status $body_bytes_sent "$http_referer" '
    '"$http_user_agent" "$request_time" "$msec"';

Я оставляю эту настройку на постоянной основе для большинства серверов, с которыми я работаю, если позволяют обстоятельства.

Если вы все еще видите задержку, записанную в $request_time поле в ваших журналах, затем top или же atop или подобное может помочь вам определить, тратится ли время в nginx или ожидает какой-то другой процесс.

Когда вы выясните, какой процесс имеет задержку, вы, вероятно, сможете выяснить, что происходит с использованием strace, ltrace иногда так же полезно, а иногда необходимо перейти к полному профилю или трассировке с информацией о времени, используя отладчик, хотя обычно это довольно трудоемкий подход. Определенно начнем с strace,

Я ожидаю, что у вас появятся еще несколько вопросов, но вместо того, чтобы сосредоточиться на деталях всех возможных областей, которые могут вызывать беспокойство, как насчет того, чтобы попробовать вышеизложенное, а затем добавить более подробную информацию о том, что вы узнали?

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