Привет, сегодня поговорим про сетевая оптимизация веб-сайта, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое
сетевая оптимизация веб-сайта, dns time, connect time, ttfb, ttlb , настоятельно рекомендую прочитать все из категории Высоконагруженные проекты.Паралельные вычисления. Суперкомпьютеры. Распределенные системы.
Оптимизация современного сайта состоит из многих различных аспектов. Все они носят ключевые значения для Вашего бизнеса. Что бы назвать сайт оптимизированным, он должен отвечать следующим требованиям:
- – отвечать клиентским запросам как можно быстрее
- – быть правильно сконструированным и простым в использовании
- – иметь возможность быть использованным людьми с различными физическими недостатками
- – иметь возможность быть использованным независимо от потребительского браузера
- – быть легко находимым современными поисковыми машинами
Первый пункт из этих аспектов «отвечать клиентским запросам как можно быстрее», пожалуй, наиболее комплексный и трудно достижимый. Это означает, что если пользователь хочет загрузить данную страницу, или отправить некую форму, запрашиваемая страница должна быть как можно быстрее загружена в его браузер.
Быстрая загрузка страницы зависит как от оптимизации клиентского кода HTML / CSS / JavaScript, так и от работы сервера.
Основным подходом к такой оптимизации является уменьшение сетевой работы на странице. Это означает, что должны быть уменьшены запросы от клиента к серверу. Снижение запросов означает, что мы должны сократить количество изображений. Сокращение изображений может быть достигнуто при комбинировании в CSS Sprite . Сокращение скриптов и CSS файлов. Для каждого скрипта и CSS файла браузер делает обращение к серверу. Если файл имеет кэшированную версию на клиентской машине, то кэшированная версия будет использована, если нет никаких изменений в файле на сервере. Одним из удачных решений уменьшения количества скриптов и CSS-файлов является их объединение. Для удобства обслуживания, большинство программистов предпочитают использовать более одного скрипта и CSS файла. Для их объединения может быть использована программа, которая объединяет их прежде чем они будут загружены на сервер. Таким образом, в конечном итоге, получается один скрипт и один файл CSS, которые могут быть запрошены сервером.
Несмотря на эти оптимизации, браузер все-же делает определенное число HTTP запросов к серверу. Для оптимизации этих запросов, должна быть произведена полная диагностика. Диагностика и правильный расчет — ключ к оптимизации. Ключ к выявлению и решению проблемы.
Диагностика одного HTTP запроса состоит из следующих компонентов:
DNS time
Это время, за которое система DNS транслирует домен к IP-адресу. Прежде чем клиент будет связан с сервером, необходимо сначала транслировать доменное имя к IP-адресу сервера.
Большие сайты используют более одного домена для своего содержания. Браузеры имеют ограничение по количеству открытых соединений. Кроме того, имеется ограничение на одновременные подключения к одному домену . Использование более одного домена может увеличить скорость загрузки сайта, но это, в свою очередь увеличивает количество DNS трансляций.
Когда клиент хочет транслировать данный домен к IP, происходят следующие действия:
Для примера мы будем использовать example.com
Делается запрос к локальному nameserver. Так как клиент обращается первый раз к example.com, локальный сервер не знает о нем. Так же, не знает IP nameserver-а домена. Поэтому он обращается к некоторым из главных серверов.
Делается запрос на один из основных серверов для принятия TLD nameserver-а. В случае с example.com это сервер для .com.
Запрашивается TLD сервер для nameserver-а example.com.
Nameserver example.com возвращает локальный nameserver IP-адрес, к которому указывает домен.
Локальный nameserver дает клиенту IP-адрес домена.
При последующих запросах к example.com в общем случае не будут производиться вышеописаные действия, а будет возвращаться IP-адрес домена из кэша на локальном nameserver-e.
Время кэширования зависит от TTL (Time-To-Live) домена, описанного в его конфигурации. Высокие значения TTL, например 86400 сек (24ч.), лучше с точки зрения того, что заявка на обновление записи будет производиться реже. Но это приводит и к некоторым неудобствам, например когда нужно быстро поменять IP у домена.
Connect time
После того, когда будет транслировано доменное имя к IP-адресу сервера, клиент пытается подключиться к этому серверу. Об этом говорит сайт https://intellect.icu . Время, необходимое для подключения, называется connection time. Такое время в основном зависит от скорости Интернета клиента и сервера. Потеря пакетов на маршруте может значительно замедлить время соединения.
Клиент не всегда открывает новую TCP сессию по каждому запросу. HTTP/1.1 поддерживает постоянные сессии (persistent connections), что означает, что возможно использование одной сессии для более чем одного запроса. Это значительно ускоряет время для получения результатов с сервера, так как нет Handshaking между клиентом и сервером. Все современные браузеры поддерживают постоянные TCP сессии.
Схема постоянных сессий:
HTTP/1.1 кроме постоянных сессий добавляет и HTTP Pipelining . Через HTTP Pipelining возможна отправка несколько запросов в одной TCP сессии, не дожидаясь их результатов.
Схема HTTP Pipelining.
Для использования HTTP Pipelining необходимо, чтобы и клиент, и сервер его поддерживали. В современных, популярных браузерах только Опера поддерживает его по умолчанию. В других, или вы должны его разрешить, или он не поддерживается.
В мобильных браузерах все по-другому. И Opera Mobile, и Opera Mini, и браузер для Android используют HTTP Pipelining по умолчанию.
Желательно, чтобы сервер был сконфигурирован для поддержки Persistent Connections и HTTP Pipelining. Это может значительно уменьшить время загрузки ваших страниц.
Redirection time
HTTP-протокол позволяет серверу перенаправить клиента на другой адрес. Это, в свою очередь, ведет к новым запросам и, следовательно, к увеличению времени для получения информации, запрошенной клиентом.
Рекомендуется по возможности избегать циклов с перенаправлениями. Это, безусловно, уменьшит время загрузки страниц. Используйте перенаправление только тогда, когда нет другого решения проблемы.
Time To First Byte (TTFB)
После того как клиент отправляет HTTP-запросы к серверу, последний обрабатывает его и возвращает ответ. Получение первого TCP пакета с сервера в качестве ответа – является именно получение первого байта.
Чем выше значение TTFB, тем медленнее обработка ресурсов сервером. Например, когда вы запрашиваете динамическую страницу с расширением .php. Прежде чем будет получен ответ от этой страницы, ее обрабатывает PHP интерпретатор, есть и высокая вероятность общения этой страницы с базой данных, и только после этого возвращает ответ клиенту. Это означает, что TTFB на такой странице будет более высоким чем на простой .html странице.
Когда нам известно TTFB, то мы знаем, сколько времени требуется серверу для обработки данной страницы. Таким образом мы можем предпринимать различные программные оптимизации на сервере. Уменьшение TTFB имеет решающее значение как для производительности серверов, так и для загрузки страницы.
Time To Last Byte (TTLB)
После того как клиент получает все заголовки и когда последний пакет прибывает, то он получает последний байта ответа.
Если нам известны значения TTLB и TTFB, то мы можем определить время, необходимое серверу для отправки всего содержимого ресурса клиента. TTLB в отличие от TTFB пропорциональна размеру ресурса. Однако, когда TTLB слишком велик, проблема заключается или в железе сервера, или в скорости Интернета.
Это можно подтвердить с помощью вкладки сети Chrome:
Пример TTFB:
Есть много программ, которые могут инспектировать ваш сайт таким образом, чтобы вы получали время каждого запроса и каждого компонента. Например Firebug, NET таб.
Если вы хотите профессионального решения, которое может обеспечить Вам круглосуточную статистику Вашего сайта, Вы можете воспользоваться услугами WebSitePulse.
Воспользовавшись услугами WebSitePulse, можно получить подробную статистику для Вашего сайта на основе 24-часового мониторинга. Подробные графики различных компонентов загрузки Вашего сайта позволят Вам проанализировать, когда и с каким отклонением Ваш сайт имеет проблемы с загрузкой, связано ли это с медленным соединением, или с нагрузками на сервер. Эта статистика предоставит Вам широкий обзор производительности Ваших сайтов, работающих в различных частях света.
Проблема 10k 10 тысяч соединений
C10k (англ. C10k; 10k connections — проблема 10 тысяч соединений) — условное название задачи конфигурирования и обслуживания высокопроизводительного сервера, способного обслуживать порядка 10 тыс. соединений одновременно. Формально аппаратное обеспечение современных компьютеров имеет должную производительность для выполнения задачи, однако неэффективные алгоритмы могут приводить к возникновению «заторов».
Возникло в 1999 году в рамках задачи обслуживания популярного в то время публичного FTP-сервера Simtel , его администратор Ден Кегель обратил внимание, что обслуживающий узел на гигабитном канале по аппаратным показателям должен был бы справляться с нагрузкой в 10 тыс. соединений, но программное обеспечение этого не позволяло.
Ряд известных веб-серверов особо подчеркивает решение задачи C10k, среди таковых Nginx, Lighttpd, Cherokee HTTP Server, Tornado, Node.js, Yaws. Для обхода проблемы используются различные техники: пулирование потоков выполнения (вместо выделения на каждое соединение отдельного потока), применение легковесных процессов, поддержка функций соединений средствами исключительно пользовательского пространства (с минимизацией системных вызовов для обхода ограничений ядра операционной системы).
По состоянию на середину 2010-х годов серверный аппаратный узел среднего уровня способен обрабатывать до 10 млн соединений, в связи с чем появились требования к программному обеспечению обеспечивать соответствующий уровень производительности по количеству одновременных подключений, обозначаемые как C10M.
'
Проблема 10 миллионов соединений C10M
Несколько дней назад Роберт Грэм начал работу над серией статей C10M и планирует закончить работу в июле этого года.
Сегодня (2013 г.) за 1200 долларов вы купите компьютер с 8 ядрами, 64 гигабайтами оперативной памяти, 10-гигабитным Ethernet и твердотельным накопителем. Такие системы должны быть способны обрабатывать:
- 10 миллионов одновременных подключений
- 10 гигабит в секунду
- 10 миллионов пакетов в секунду
- задержку
10 микросекунд
- джиттер 10 микросекунд - 1 миллион подключений в секунду
Такие системы уже существуют. Мы называем их «аппаратными средствами» или «устройствами». Но в последние годы устройства превратились в просто программное обеспечение, работающее на компьютерах общего назначения. Разорвите сетевое устройство, и вы можете найти внутри персональный компьютер. Пределы масштабируемости ограничиваются не нашим оборудованием, а программным обеспечением, в частности, операционной системой.
Есть три основные проблемы.
Первая проблема заключается в том, что для данных не существует «быстрого пути». Это конфликт между «многопользовательским» дизайном и «одноцелевым» дизайном. Первичная служба (например, веб-сервер) не может получить приоритет в системе, оставив все остальное (например, консоль SSH) в качестве второстепенного приоритета.
Вторая проблема - многоядерная масштабируемость. Старый код написан в соответствии с принципами «многопоточности» или «многозадачности», когда несколько задач должны совместно использовать один процессор. Новый код должен быть написан с использованием разных принципов, когда одна задача должна быть разделена между несколькими процессорами. Это требует переосмысления с нуля, например, синхронизации, которая никогда не заставляет поток останавливаться и ждать.
Третья проблема - это память. За последние 15 лет размер основной памяти увеличился в тысячу раз, и теперь стало практичным получить 128 гигабайт в дешевом настольном компьютере. Тем не менее, кеши L1 и L2 остались того же размера, а кеши L3 (или последнего уровня) увеличились только в 10 раз. Это означает, что в масштабе каждый указатель является промахом в кэше. Чтобы исправить это, код должен уделять внимание вопросам кеширования и разбиения на страницы.
Решение всех этих проблем состоит в том, чтобы разделить машину на две части: часть «управления» и часть «данных». Раздел данных захватывает нужные сетевые карты и заменяет драйверы на те, которые обходят ядро. Раздел данных захватывает все ядра ЦП, которые ему нужны, и удаляет их из планировщика операционной системы, поэтому никакие другие задачи не будут выполняться на них. Раздел данных занимает большую часть оперативной памяти и управляет ею самостоятельно.
Десять лет назад инженеры взялись за то, что они назвали «проблемой c10k»: заставить серверы обрабатывать 10 тысяч одновременных подключений. Вывод заключался в том, чтобы исправить ядра и писать приложения в асинхронном режиме. Сегодня с C10M мы начинаем с асинхронного кода, но вместо улучшенных ядер мы полностью перемещаем наш код из ядра.
В 2007 году в Швейцарии при поддержке Microsoft Research началась разработка экспериментальной многопроцессорной операционной системы Barrelfish, которая некоторые возможности, такие как CAS2 как раз использует. Она еще далека до момента даже минимального использования, тем не менее доступны исходники под лицензией MIT.
Вау!! 😲 Ты еще не читал? Это зря!
Надеюсь, эта статья об увлекательном мире сетевая оптимизация веб-сайта, была вам интересна и не так сложна для восприятия как могло показаться.
Желаю вам бесконечной удачи в ваших начинаниях,
будьте свободными от ограничений восприятия и позвольте себе делать больше активности в изученном направлени . Надеюсь, что теперь ты понял что такое сетевая оптимизация веб-сайта, dns time, connect time, ttfb, ttlb
и для чего все это нужно, а если не понял, или есть замечания,
то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории
Высоконагруженные проекты.Паралельные вычисления. Суперкомпьютеры. Распределенные системы
Комментарии
Оставить комментарий
Высоконагруженные проекты.Паралельные вычисления. Суперкомпьютеры. Распределенные системы
Термины: Высоконагруженные проекты.Паралельные вычисления. Суперкомпьютеры. Распределенные системы