Компания
110,46
рейтинг
6 мая 2014 в 11:59

Разработка → Быстрое веб-приложение — трепанация сети

Психология — интересная и иногда полезная наука. Многочисленные исследования показывают, что задержка в отображении веб-страницы дольше 300 мс заставляет пользователя отвлечься от веб-ресурса и задуматься: «что за хрень?». Поэтому УСКОРИВ веб-проект до психологически невоспринимаемых значений, можно ПРОСТО удерживать пользователей дольше. И именно поэтому бизнес готов тратиться на скорость: $80М — чтобы уменьшить latenсy всего на 1 мс.



Однако, чтобы ускорить современный веб-проект, придется кровушки пустить и основательно покопаться в этой теме — поэтому базовое знание сетевых протоколов приветствуется. Зная принципы, можно без особых усилий ускорить свою веб-систему на сотни миллисекунд всего за несколько подходов. Ну что, готовы сэкономить сотни миллионов? Наливайте кофе.

Послевкусие


Это очень горячая тема — как удовлетворить пользователя сайта — и юзабилисты скорее всего заставят меня выпить коктейль Молотова, закусить гранатой без чеки и успеть выкрикнуть перед взрывом: «несу ересь». Поэтому хочется зайти с другой стороны. Широко известно, что задержка в отображении страницы больше 0.3 сек — заставляет пользователя заметить это и… «проснуться» от процесса общения с сайтом. А задержка в отображении больше секунды — задуматься на тему: «а что я тут делаю вообще? чего они меня мучают и заставляю ждать?».

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

Кто отвечает за скорость


Ну кто, конечно Вы. Иначе вряд ли бы Вы начали читать пост. Если серьезно, то тут проблема — ибо вопрос скорости делят на 2 слабо связанные и технологически, и социально части: фронтэнд и бэкэнд. И нередко забывают про третью ключевую составляющую — сеть.

Просто HTML


Для начала вспомним, что первые сайты в начале девяностых были… набором статических страниц. И HTML — был простым, понятным и лаконичным: сначала текст, потом текст и ресурсы. Вакханалия началась с динамической генерацией веб-страниц и распространением java, perl и в настоящее время — это уже плеяда технологий, в числе которых php.
Чтобы снизить влияние этой гонки на жизнеспособность сети — вдогонку принимают HTTP/1.0 в 1996, а через 3 года — HTTP/1.1 в 1999. В последнем, наконец, договорились — что не нужно гонять TCP handshakes с ~2/3 скорости света (в оптоволокне) туда-суда для каждого запроса, устанавливая новое соединение, а правильнее открыть TCP-соединение один раз и работать через него.

Бэкэнд


Приложение

Тут мало что изменилось за последние 40 лет. Ну может «пародию» на реляционную теорию добавили под названием NoSQL — которая дает как плюсы, так и минусы. Хотя, как показывает практика — пользы бизнесу от нее вроде больше (но и бессонных ночей с поиском ответа на вопрос: «кто лишил данные целостности и под каким предлогом» — стало скорее больше).
  1. Приложение и/или веб-сервер (php, java, perl, python, ruby и т.п.) — принимает запрос клиента
  2. Приложение обращается к БД и получает данные
  3. Приложение формирует html
  4. Приложение и/или веб-сервер — отдает данные клиенту

Тут все понятно с точки зрения обеспечения скорости:
  • оптимальный код приложения, без зацикливаний на секунды
  • оптимальные данные в БД, индексация, денормализация
  • кэширование выборки из БД


Больше не будем говорить про разгон «приложения» — про это написали много книг и статей и все довольно линейно и просто.
Главное одно — чтобы приложение было прозрачно и можно было померить скорость прохождения запроса через разные компоненты приложения. Если этого нет — дальше можно не читать, не поможет.
Как этого добиться? Пути известны:
  • Стандартное логирование запросов (nginx, apache, php-fpm)
  • Логирование медленных запросов БД (опция в mysql)
  • Инструменты фиксации узких мест при прохождении запроса. Для php это xhprof, pinba.
  • Встроенные инструменты внутри веб-приложения, например отдельный модуль трассировки.

Если логов у вас много и вы запутываетесь в них — агрегируйте данные, смотрите процентили и распределение. Просто и прямолинейно. Обнаружили запрос более 0.3 секунды — начинайте разбор полетов и так до победного конца.

Веб-сервер

Движемся наружу. Веб-сервер. Тут тоже мало что сильно поменялось, но может только что костылизация — через установку обратного прокси-веб-сервера перед веб-сервером (fascgi-сервером). Да, это конечно помогает:
  1. держать значительно больше открытых соединений с клиентами (за счет?.. да, другой архитектуры кэширующего прокси — для nginx это использование мультиплексирования сокетов небольшим числом процессов и низкого объема памяти для одного соединения)
  2. более эффективно отдавать статические ресурсы напрямую с дисков, не фильтруя через код приложения

Но вопрос остался — почему apache сразу не стали делать «правильно» и иногда приходится ставить веб-серверы паровозиком.

Постоянные соединения

Установление TCP-соединения занимает 1 RTT. Распечатайте диаграмку и повесьте перед собой. Ключ к пониманию появления тормозов — тут.

Эта величина довольно тесно коррелирует с расположением вашего пользователя относительно веб-сервера (да, есть скорость света, есть скорость распространения света в материале, есть маршрутизация) и может занимать (особенно с учетом провайдера последней мили) — десятки и сотни миллисекунд, что конечно много. И беда, если это установление соединения происходит для каждого запроса, что было распространено в HTTP/1.0.



Ради этого по большому счету и затевался HTTP 1.1 и в этом направлении развивается и HTTP 2.0 (в лице spdy). IETF с Google в настоящее время пытаются сделать все, чтобы выжать из текущей архитектуры сети максимум — не ломая ее. А это можно сделать… ну да, максимально эффективно используя TCP-соединения, используя их полосу пропускания как можно плотнее через мультиплексирование, восстановление после потерь пакетов и др.



Поэтому обязательно проверьте использование постоянных соединений на веб-серверах и в приложении.

TLS

Без TLS, который изначально зародился в недрах Netscape Communications как SSL — в современном мире никуда. И хотя, говорят, Последняя «дырочка» в этом протоколе заставила многих поседеть значительно раньше срока — альтернативы практически нет.
Но не все почему-то помнят, что TLS ухудшает «послевкусие» — добавляя 1-2 RTT дополнительно к 1 RTT соединению через TCP. В nginx вообще по умолчанию кэш сессий TLS — выключен — что добавляет лишний RTT.



Поэтому проследите, чтобы TLS-сессии в обязательном порядке кэшировались — и так мы сэкономим еще 1 RTT (а один RTT все-таки останется, к сожалению, как плата за безопасность).

Про бэкэнд, наверное, все. Дальше будет сложнее, но интереснее.

Сеть. Расстояние и пропускная способность сети


Часто можно услышать — у нас 50МБит/с, 100МБит/с, 4G даст еще больше… Но редко можно увидеть понимание, что для типичного веб-приложения пропускная способность не особо важна (если только файлы не качать) — гораздо важнее lantency, т.к. делается много небольших запросов по разным соединениям и TCP-окно просто не успевает раскачаться.
И разумеется, чем дальше клиент от веб-сервера, тем дольше. Но бывает что нельзя иначе или трудно. Именно поэтому придумали:
  1. CDN
  2. Динамическое проксирование (CDN-наоборот). Когда в регионе ставится например nginx, открывающий постоянные коннекты на веб-сервер и терминирующий ssl. Понятно зачем? Именно — в разы ускоряется установление соединений от клиента с веб-прокси (хэндшейки начинают летать), а дальше используется прогретое TCP-соединение.

Что еще можно сделать… увеличить TCP’s initial congestion window — да, это нередко помогает, т.к. веб-страничка отдается одним набором пакетов без подтверждения. Попробуйте.



Включите отладчик браузера, посмотрите время загрузки веб-страницы и подумайте о latency и способах ее уменьшения.

Пропускная способность

Помните, что TCP-окошко соединения должно разогнаться сначала. Если веб-страница загружается меньше секунды — окошко может не успеть увеличиться. Средняя пропускная способность сети в мире — немного превышает 3 МБит\с. Вывод — передавайте через одно установленное соединение как можно больше, «разогрев» его.



Помочь тут может конечно мультиплексирование HTTP-ресурсов внутри одного TCP-соединения: передача нескольких ресурсов вперемешку как в запросе, так и ответе. И даже эту технику включили в стандарт, но недоописали и в итоге она не взлетела (в chrome ее не так давно вообще убрали). Поэтому тут можно пока попробовать spdy, ждать HTTP 2.0 или использовать таки pipelining — но не из браузера, а из приложения напрямую.



Шардинг доменов

А как же очень популярная техника шардинга доменов — когда браузер/приложение преодолевает ограничение в >=6 соединений на домен, открывая еще по >=6 и более соединений на фиктивные домены: img1.mysite.ru, img2.mysite.ru…? Тут весело, т.к. с точки зрения HTTP/1.1 — это вас вероятнее всего ускорит, а с точки зрения HTTP/2.0 — это антипаттерн, т.к. мультиплексирование HTTP-трафика через TCP-соединение может обеспечить лучшую пропускную способность.
Так что пока — шардим домены и ждем HTTP/2.0 чтобы этого больше не делать. И конечно — лучше измерить конкретно для вашего веб-приложения и сделать обоснованный выбор.

Фронтэнд


Про известные вещи типа скорости рендеринга веб-страницы и размера изображений и JavaScript, порядка загрузки ресурсов и т.п. — писать не интересно. Тема избита и убита. Если кратко и неточно — кэшируйте ресурсы на стороне веб-браузера, но… с головой. Кэшировать 10МБ js-файл и парсить его внутри браузера на каждой веб-странице — понимаем к чему приведет. Включаем отладчик браузера, наливаем кофе и к исходу дня — тренды налицо. Набрасываем план и реализуем. Просто и прозрачно.
Гораздо более острые подводные камни могут скрываться за достаточно новыми и бурно развивающимися сетевыми возможностями веб-браузера. О них и поговорим:
  1. XMLHttpRequest
  2. Long Polling
  3. Server-Sent Events
  4. Web Sockets


Браузер — как операционная система

Изначально браузер воспринимался как клиентское приложение для отображения HTML-разметки. Но с каждым годом происходило превращение его в центр управления плеядой технологий — в итоге HTTP-сервер и веб-приложение за ним теперь воспринимается лишь как вспомогательный компонентик внутри браузера. Интересный технологический сдвиг акцентов.
Более того, с появлением встроенной в браузер «телестудии» WebRTC и средств сетевого взаимодействия браузера с внешним миром — вопрос обеспечения производительности плавно переместился от серверной инфраструктуры к браузеру. Если эта внутренняя кухня у клиента будет тормозить — про php на веб-сервере или join в БД никто и не вспомнит.

Разберем на запчасти этот непрозрачный монолит.

XMLHttpRequest

Это всем известный AJAX — способность браузера обращаться к внешним ресурсам по HTTP. С появлением CORS — начался совершенный «беспредел». Теперь чтобы определить причину торможения, нужно лазать по всем ресурсам и смотреть логи везде.
Если серьезно, технология несомненно взорвала возможности браузера, превратив его в мощную платформу динамического рендеринга информации. Писать о ней нет смысла, тема многим известна. Однако опишу ограничения:
  1. опять отсутствие мультиплексирования нескольких «каналов» заставляет неэффективно и не полностью использовать пропускную способность TCP-соединения
  2. нет адекватной поддержки streaming (открыл соединение и висишь, ждешь), т.е. остается дергать сервер и смотреть что он ответил




Тем не менее, технология очень популярна и сделать ее прозрачной с точки зрения мониторинга скорости — несложно.

Long Polling

Как сделать веб-чат? Да, нужно как-то передавать со стороны сервера в браузер информацию об изменениях. Напрямую через HTTP — нельзя, не умеет. Только: запрос и ответ. Вот в лоб люди и решили: сделать запрос и ждать ответ, секунду, 30 секунд, минуту. Если что нибудь пришло — отдать в ответ и разорвать соединение.

Да, куча антипаттернов, костылей — но технология очень широко распространена и работает всегда. Но, т.к. Вы отвечаете за скорость — знайте, нагрузка на серверы при таком подходе — очень высока, и может сопоставляться с нагрузкой от основной посещаемости веб-проекта. А если обновления от сервера к браузерам распространяются часто — то может основную нагрузку превышать в разы!
Что делать-то?

Server-Sent Events

Тут открывается TCP-соединение с веб-сервером, не закрывается и в него сервер пишет разную инфу в UTF-8. Нельзя правда бинарные данные передавать оптимально без предварительного Base64 (+33% увеличение в размере), но как канал управления в одну сторону — превосходное решение. Правда в IE — не поддерживается (см. пункт выше, который везде работает).




Плюсы технологии в том, что она:
  1. очень проста
  2. не нужно после получения сообщения заново переоткрывать соединение с сервером


Web Sockets

Для системного администратора это даже не зверь, а скорее ночной некроморф. «Хитрым» способом через HTTP 1.1 Upgrade браузер меняет «тип» HTTP соединения и оно остается открытым.




Затем по соединению в ОБЕ (!) стороны можно начать передавать данные, оформленные в сообщения (frames). Сообщения бывают не только с информацией, но и контрольные, в т.ч. типа «PING», «PONG». Первое впечатление — снова изобрели велосипед, снова TCP на базе TCP.
С точки зрения разработчика — конечно это удобно, появляется дуплексный канал между браузером и веб-приложением на сервере. Хочешь streaming, хочешь messages. Но:
  1. не поддерживается html-кэширование, т.к. работаем через бинарный framing-протокол
  2. не поддерживается сжатие, его нужно реализовать самостоятельно
  3. жутки глюки и задержки при работе без TLS — из-за устаревших прокси серверов
  4. нет мультиплексирования, в результате чего каждое bandwidth каждого соединения используется неэффективно
  5. на сервере появляется много висящих и делающих что-то «гадкое с базой данных» прямых TCP-соединений от браузеров




Как отслеживать производительность Web Sockets? Очень хороший вопрос, оставленный специально на закуску. Со стороны клиента — сниффер пакетов WireShark, со стороны сервера и с включенным TLS — мы решаем задачу через патчинг модулей для nginx, но видимо есть более простое решение.

Главное понимать, как Web Sockets устроены изнутри, а Вы уже это знаете и контроль за скоростью — будет обеспечен.
Так что же лучше: XMLHttpRequest, Long Polling, Server-Sent Events или Web Sockets? Успех — в грамотном сочетании этих технологий. Например, можно управлять приложением через WebSockets, а загружать ресурсы с использованием встроенного кэширования через AJAX.

Что теперь делать?


Научиться измерять и реагировать на превышение заданных значений. Обрабатывайте логи веб-приложения, разбирайтесь с медленными запросами в них. Скорость на стороне клиента тоже стало возможным мерить благодаря Navigation timing API — мы собираем данные по производительности в браузерах, отправляем их средствами JavaScript в облако, агрегируем в pinba и реагируем на отклонения. Очень полезное API, пользуйтесь обязательно.



В результате вы найдете себя в окружении системы мониторинга типа nagiоs, с десятком-другим автоматических тестов, на которых видно, что со скоростью работы вашей веб-системы все в порядке. А в случае срабатываний — команда собирается и принимается решение. Кейсы могут быть, например, такими:
  • Медленный запрос в БД. Решение — оптимизация запроса, денормализация в случае крайней необходимости.
  • Медленная отработка кода приложения. Решение — оптимизация алгоритма, кэширование.
  • Медленная передача тела страницы по сети. Решение (в порядке увеличения стоимости) — увеличиваем tcp initial cwnd, ставим динамический прокси рядом с клиентом, переносим серверы поближе
  • Медленная отдача статических ресурсов клиентам. Решение — CDN.
  • Блокировка в ожидании соединения с серверами в браузере. Решение — шардинг доменов.
  • Long Polling создает нагрузку на серверы, большую чем хиты клиентов. Решение — Server-Sent Events, Web Sockets.
  • Тормозят, неустойчиво работают Web Sockets. Решение — TLS для них (wss).

и т.д.

Итоги


Мы прошлись по основным компонентам современного веб-приложения. Узнали о трендах HTTP 2.0, контрольных точках, которые важно понимать и научиться измерять для обеспечения скорости ответа веб-приложения по возможности ниже 0.3 сек. Заглянули в суть современных сетевых технологий, использующихся в браузерах, обозначили их достоинства и узкие места.

Поняли, что понимать работу сети, ее скорость, latency и пропускную способность — важно. И что пропускная способность важна далеко не всегда.

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

Можно попытаться решить задачу обработки запроса клиента за «0.3 сек» по-разному. Главное — определить метрики, автоматически собирать их и действовать в случае их превышения — докапываться к каждом конкретном случае до корня. В нашем продукте мы решили задачу обеспечения максимально низкой latency благодаря комплексной технологии кэширования, объединяющую технологии статического и динамического сайта

В заключение, приглашаем посетить нашу технологическую конференцию, которая пройдет уже скоро, 23 мая. Всем удачи и успехов в нелегком деле обеспечения производительности веб-проектов!
Автор: @AlexSerbul
1С-Битрикс
рейтинг 110,46

Комментарии (42)

  • +8
    Александр, рассказываете красиво, но упускаете как минимум 1 момент. Пункты «Медленная отдача статических ресурсов клиентам» и «Блокировка в ожидании соединения с серверами в браузере» можно более глобально назвать «Клиентской оптимизацией» и вот тут выяснится, что парочка пунктов упущена.

    Не буду их перечислять — они есть вот тут правила PageSpeed Insights, например.
    Я давно и плотно работаю с «продуктом» о котором идет речь и многое из перечисленного Вами действительно в нем доведено до прекрасного уровня. Многое, но только не «клиентская оптимизация». А в этом месте можно ускорить страницу весьма сильно.

    Собственно к чему я клоню: сейчас продукт, который называет себя «технологической платформой» вставляет слишком много спиц в колеса «клиентской оптимизации». Даже если разработчик на обсуждаемом продукте ооочень захочет сделать все круто — у него не получится, платформа не даст. Вот за это продукту жирный минус!
    • +1
      В статье я постарался рассказать о современных технологиях, позволяющих ускорить отклик веб-приложения и как выжать из них максимум — чтобы всем было интересно и полезно. Относительно продуктов компании — ведется постоянная работа как по серверной, так и клиентской оптимизации (внимательно читаем рекомендации Google, разумеется) — но, как всегда, есть куда расти :-)

      Что есть в продуктах уже сейчас по клиент-сайду:
      — кэширование ресурсов в браузере
      — объединение js/css в несколько больших файлов, согласитесь это очень важно
      — сжатие на стороне сервера
      — оптимизация порядка загрузки js/css
      — CDN и шардинг доменов
      — композитная технология, фишка релиза!

      это не полный список.

      О чем идут дискуссии по клиент-сайду:
      — минификация js/css/html

      По сервер-сайду:
      — управляемое кэширование с настраиваемой грануляцией кэша
      — веб-кластер, позволяющий снизить нагрузку на отдельные ноды и БД — и ускорить таким образом отклик
      — протюненый стек tcp/ip — выйдет в виртуальной машине

      это тоже не полный список, чтобы не утомлять читателей.

      • +4
        Новость о том, что работа в эту сторону ведется радует, ибо из других источников (кроме Вас) только молчание.
        Но не могу не возразить некоторым Вашим доводам.

        1. оптимизация порядка загрузки js/css
        Расскажите что вы имеете ввиду под этим пунктом? Потому как я вижу полную противоположность Вашим словам.
        Самый банальный из примеров — невозможно вынести скрипты (уже объединенные) из head в конец body. Раньше это было только для скриптов главного модуля, теперь похоже для всех кроме скриптов шаблона. А как бы «оптимизация порядка загрузки ресурсов» идет лесом… Именно к этому самая большая из моих претензий.

        2. CDN и шардинг доменов
        CDN — да, шардинг доменов — отсутствует в продукте (при выключенном CDN)

        3. композитная технология, фишка релиза!
        Не работает с объединением CSS. Исправите надеюсь, но факт что сейчас не работает

        Если есть сомнения по поводу любого из моих замечаний — мои контакты в есть профиле
        • 0
          В текущей версии главного модуля есть возможность переносить в конец body подключения js модулей. На Б24 так подключаются js модулей im, pull, timeman.

          Для этого:

          1. в footer.php шаблона добавляется метод $APPLICATION->ShowBodyScripts();

          2. в шаблоне или init.php указывается какие модули идут в body $GLOBALS[«APPLICATION»]->MoveJSToBody('pull');

          3. дополнительно модули в body можно сгруппировать в один файл $GLOBALS[«APPLICATION»]->GroupModuleJS('im','pull');

          • +1
            А как это сделать на D7?
          • 0
            Для своих модулей по аналогии сработает?
            А как быть с компонентами?
            • 0
              Для своих модулей все работает аналогично. С компонентами такого пока нельзя сделать.
              Думаем над расширением АПИ.
            • 0
              Как вариант с компонентами — посмотрите на метод ForumAddDeferredScript, он решает эту задачу в некоторых компонентах форума.
          • 0
            Как всегда не без ложки дегтя: в body нельзя переместить скрипты шаблона и страницы. А я уж обрадовался…
            Николай, будет API для этого?
            • +2
              Подумаем над этим, в принципе резон есть.
      • 0
        А можно глупый вопрос? :)
        Если у меня cdn работает сильно медленнее своего хостинга, это мне так повезло, или картинки слишком большие, или так и должно быть? :)
        • 0
          Весь вопрос это только у вас или у клиентов сайта все наоборот.
          • 0
            А, разобрался, вопрос снимается.
            Я так понимаю, картинка в cdn закачивается при первом обращении, и оно как раз тормозное. При последующем обращении с другого компа к этой картинке она сразу оттуда берется и уже не тормозит.
        • 0
          Совсем не глупый вопрос :-) Суть CDN в том, что картинка отдается оттуда с единого для всех адреса типа: «images.cdn.com», но резолвится это DNS-имя на ближайший к клиенту IP-адрес, раздающий статику. Эти ближайшие сервера должны быть как можно ближе к точкам раздачи трафика, со скоростными каналами. В результате клиент скачает файл или посмотрит видео — максимально комфортно.

          У вас же один сервер хостинга, а сервера CDN понатыканы в датацентры по всей России — самостоятельно поднимать такую инфраструктуру — безумно дорого.
    • +5
      Совершенно согласен. Текущая реализация продукта, к сожалению, не дает разработчикам необходимых средств для клиентской оптимизации.
      Вот, например, фрагмент кода главной страницы сайта продукта:


      Я не призываю отказаться от подхода разработки «коробочных решений». Предоставьте разработчикам возможность гибкого управления процессом формирования страницы — и они будут вам благодарны.
      • +2
        Спасибо, обсудим с коллегами.
        • +2
          Спасибо за понимание.
          Вы же знаете, как это работает — позвольте сообществу участвовать в развитии продукта, и сообщество сделает все само. Пригласите к обсуждению хотя бы Золотых Партнеров и разработчиков крупных проектов. Мы рады будем помочь.
          • +1
            А, что конкретно в приведенном вами примере не устраивает?
            • +3
              Большое количество неминицифированных скриптов и CSS, принудительное подключение служебных скриптов (тот же kernel_main.js) в публичной части даже для неавторизованных пользователей. Последнее, скорее, относится не конкретно к сайту продукта, но к поведению CMS по умолчанию.
              Первая строка метода ShowHead():

              echo '<meta http-equiv="Content-Type" content="text/html; charset='.LANG_CHARSET.'"'.($bXhtmlStyle? ' /':'').'>'."\n";

              Даже на самом сайте продукта используется doctype html. Достаточно <meta charset="">
              Нет никакой возможности влиять на ход выполнения ShowHeadScripts() в контексте подключения служебных скриптов. Поправьте, если я ошибаюсь.
              • 0
                1. Не минифицированные скрипты скорее соглашусь, хотя с учетом их сжатия выигрыш не такой большой

                2. kernal_main.js не будет подключаться если вы не используете системные js на странице. Как вариант у вас может быть включено продление сессии пользователя, которое и подключает main.

                3. «Нет никакой возможности влиять на ход выполнения ShowHeadScripts() в контексте подключения служебных скриптов. » — не совсем понял, что имеете в виду
                • +1
                  1. По поводу минифицирования скриптов ставил эксперимент примерно полгода назад. Был взят тиражный магазин, тесты проводились и на стилях и на скриптах. Результаты получились следующие (усреднено по всем стилям/скриптам на главной странице тиражного магазина):
                  Только gzip — сжатие около 78%.
                  Только минификация — сжатие около 15%.
                  И то и другое — сжатие около 82%.
                  Т.е. при минификации (если вы используете gzip при отдаче статики) получим доп. выигрыш в 5% от исходного объема. Учитывая сколько сил нужно упахать в минификацию — как-то нецелесообразно ее делать.

                  2. Действительно, если поколдовать — можно избавиться от скриптов ядра (модуля main). Правда это пока вы не включите тот самый «композит». В этом случае получите +100-150кб скриптов. Учитывая что почти каждый сайт использует jQuery — хотя бы дайте программистом выбор той библиотеки которая будет отвечать за подмену динамических областей. Но это как я понимаю на грани фантастики
                  • 0
                    Я тоже проверял минификацию, через внутренний самописный модуль для nginx, сжимающий на лету css/ js. Иногда экономия доходила до 20 и больше процентов — при минификции + сжатии. Гугл ее также активно рекомендует делать.
  • +1
    Браво, Александр!
    Прекрасный текст по форме, хотя и уже хорошо известный по сути.

    Спасибо, всегда бы так.

    ps в предпоследнем абзаце лишняя кавычка после слова продукте
    • +1
      Спасибо :-) Я почему-то думал раньше, что достаточно понимать логику работы приложения и БД — чтобы разобраться в узких местах производительности веб-приложения. Оказалось — сильно заблуждался. Мир стал сложнее, технологий стало больше и они стали многограннее — надеюсь статейка сформирует у коллег целостную картину бытия и поможет быстрее искать и уничтожать узкие места производительности.
  • 0
    Спасибо Александр, оптимизации много не бывает, весьма полезно :)
  • +1
    У SPDY есть некоторые проблемы :-) Если соединение плохое, и сегменты теряются то весь твой мультиплексированный поток останавливается :) Поэтому это уже не модно, сейчас можно QUIC (Quick UDP Internet Connections) :-)
    • 0
      Эта проблема, под названием «head line blocking», не только у SPDY, а у TCP в целом. Дело не в моде :-) На базе SPDY идет разработка IETF будущего стандарта сети — HTTP 2.0
      • 0
        То что начали разрабатывать сдантарт HTTP 2.0 на основе SPDY пока не осознали его недостатков — это не значит что он полностью дублирует его реализацию. Пока вы пишете посты про SPDY, Google уже включил на своих серверах поддержку QUIC и утверджает что этот протокол эффективнее SPDY :-)
        • 0
          QUIC работает на базе null-protocol-ного формата UDP. Коллеги просто придумали свою версию TCP, которую нужно пообкатывать лет эдак 20 ;-).

          1) UDP — это потери пакетов, причем немалые, хотя он успешно сейчас применяется в том же WebRTC и VoIP, играх.
          2) UDP — это проблемы на NAT. Достаточно настроить WebRTC, чтобы увидеть, сколько там подводных камней — чтобы состыковать по UDP два браузера через кучу NAT, особенно в мобильных сетях. Выход для WebRTC — это кластер STUN/TURN-relay серверов, иначе в 10-20% никак.

          Но для передачи некритичных данных, думаю, протокол пригодится.
  • +1
    Long pooling?
    Мне всегда казалось, что должно быть long polling
    • 0
      Ой, прошу прощения, конечно. Поправил.
  • +1
    Схема TLS несколько сложнее, чем ты приводишь. Если туда добавить цепочки сертификатов, OCSP и SPDY, а также учесть, что центры сертификации расположены за пределами России, то получится весьма забавная картина.
    • 0
      Да, я немного упростил :-)
  • 0
    Если решились на описание технологий\систем, ускоряющих ресурс, то упустили некоторые вещи, а именно кеширование — тут нам помогут и значительно упростят жизнь манифесты, localStorage, IndexedDB и проч.
    • 0
      Согласен. Но я упонялул про кэширование в браузере, без него да. никуда:
      Про известные вещи типа скорости рендеринга веб-страницы и размера изображений и JavaScript, порядка загрузки ресурсов и т.п. — писать не интересно. Тема избита и убита. Если кратко и неточно — кэшируйте ресурсы на стороне веб-браузера, но… с головой. Кэшировать 10МБ js-файл и парсить его внутри браузера на каждой веб-странице — понимаем к чему приведет. Включаем отладчик браузера, наливаем кофе и к исходу дня — тренды налицо. Набрасываем план и реализуем. Просто и прозрачно.
      • +1
        Я уже после отправки комментария подумал о том, что (а) о кешировании было сказано и (б) если писать о кешировании, то об этом можно написать целую статью, включая серверные технологии (редиска\мемкеш\тарантул или на худоё конец MySQL с таблицами типа memory, всякие CDN и прочее). И поэтому, вполне логично что о нём было сказано так мало. Вы совершенно правы.

        Но время редактирования комментария вышло и поезд ушёл.
  • +2
    Ребята, статья весьма хорошая, но когда Битрикс можно будет нормально размещать не на мейнфреймах с тоннами оперативной памяти и SSD дисками в RAID-10?

    Когда Ваш мониторинг производительности будет показывать НЕ погоду на Марсе? Почему это плохо, ну хотя бы вот поэтому: forum.searchengines.ru/showthread.php?t=787038

    Когда появятся актуальные образы для KVM/OpenVZ виртуализации?

    Почему существующие образы Bitrix основаны на давно устаревшей Fedora 6 и морально устаревшей CentOS 5?

    Когда появится разумная документация, КАК ЗАСТАВИТЬ Битрикс работать на вменяемой скорости с помощью настройки СУЩЕСТВУЮЩЕГО сервера, а не безусловного использования Вашей сборки (в которую инъектировано порядка полусотни правок лишь по известным Вам мотивам)?
    • +1
      Спасибо.

      но когда Битрикс можно будет нормально размещать не на мейнфреймах с тоннами оперативной памяти и SSD дисками в RAID-10?

      У Битрикс есть несколько редакций. Младшие можно размещать на виртуальном хостинге с разумными требованиями. По опыту — довольно часто забывают включить кэширование, делают неоптимальные вызовы АПИ — рождающие неоптимальные запросы в БД — вот и мейнфреймы нужны. Поставить базу на колени можно 3 строками кода же, знаете.

      Ну а старшие редакции по функционалу не уступают SAP — для них мы рекомендуем веб-кластерные технологии, с ними проекты живут, развиваются, не коллапсируют как нередко бывает с самописными монолитами.

      Когда Ваш мониторинг производительности будет показывать НЕ погоду на Марсе?

      Я посмотрел вашу статейку. Тесты синтетические, даже не погода на Марсе, а смещение Доплера в галактике в созвездии Андромеды :-)
      Что измеряете:
      — Время на создание 1000 файлов из PHP
      — MySQL inserts per second
      — Скорость загрузки файлов с Яндекса

      В то время, как типичное веб-приложение:
      — читает с диска (точнее из кэша файловой системы в памяти операционки)
      — нагружает процессор на выполнение байткода PHP
      — делает ВЫБОРКИ из БД

      Т.е. на диск практически не пишет :-)

      Именно поэтому в мониторе производительности мы и замеряем скорость загрузки ядра продукта в секунду — создается близкий сценарий нагрузки.

      Хотя сейчас обсуждаем вопрос встроенного нагрузочного тестирования кейсов типа: выборка из каталога, вставка в каталог — т.е. видите, опять бизнесовые замеры, а не марки и циферки на железках.

      Почему существующие образы Bitrix основаны на давно устаревшей Fedora 6 и морально устаревшей CentOS 5?

      CentOS6 уже года 3 как минимум. Самый последний.

      Когда появится разумная документация, КАК ЗАСТАВИТЬ Битрикс работать на вменяемой скорости с помощью настройки СУЩЕСТВУЮЩЕГО сервера, а не безусловного использования Вашей сборки (в которую инъектировано порядка полусотни правок лишь по известным Вам мотивам)?


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

      Консультируем по нагрузке совершенно бесплатно, пишите в личку — сразу отвечу. Еще лучше — собрать скайп-вебинарчик и порисовать.

      • +1
        К счастью, та статейка с серча совершенно не моя — она была приведена как кейс буздумного и безумного использования теста производительности Битрикса :)

        По поводу странности теста — я абсолюнто серьезно, речь даже идет не про виртуальный хостинг. Клиенты берут у нас сервера для миграции с VPS и на них тест производительности показывает цифры либо аналогичные либо даже меньшие, чем были ранее на заведомо более слабой по памяти/процессору/диску VPS. Причем, мы переносим машины целиком — со всеми настройками и прочим, что исключает внешние факторы.

        Также объективно полезная установка Nginx в дополнение к Apache на Битрикс приводит к падению цифр производительности до очень низких. Тоже самое касается режима запуска PHP как mod_fcgid и Вы вынуждаете пользователей использовать тотально небезопасный режим PHP как модуля веб сервера Apache.

        Число настроек в предсобранном образе честно говоря зашкаливает при полном отсутствии описания что делает какая из них. Настройки MySQL и PHP — это вообще отдельная тему и понять ее почти нереально. Мы на стенде так и не смогли полностью извлечь все настройки для использования на обычном сервере.

        Алсо, мы хотеть — гайд по установке и оптимизации машин на Debian 7+/Ubuntu 12/14+ под Bitrix не внешними скриптами/образами, а просто по инструкции в стиле:
        • Вот такой режим апаче лучше потому что...
        • Лучше использовать вот такой оптимизатор PHP опкода, потому что...
        • Нужно изменить вот эти настройки MySQL, чтобы Битрикс работал быстрее и не показывал отрицательные числа в тесте производительности


        Вот за такие инструкции мы, как поддерживающие несколько тысяч инстансов Bitrix были бы тотально благодарны =)
        • 0
          Мы тут посовещались и подумали, что отличным решением было бы:
          • В тестере проверять конфиуграцию PHP акселератора, а не просто проверять его наличие. Очень многое зависит от его параметров и как раз это Вы не проверяете, а надо бы.
          • В тестере проверять конфигурацию MySQL и опять же сообщать о проблемах и рекомендованых установках

          Либо еще проще — просто рекомендованные файлы конфигурации, которые можно взять и вставать в акселератор/демона.
        • 0
          По поводу странности теста — я абсолюнто серьезно, речь даже идет не про виртуальный хостинг. Клиенты берут у нас сервера для миграции с VPS и на них тест производительности показывает цифры либо аналогичные либо даже меньшие, чем были ранее на заведомо более слабой по памяти/процессору/диску VPS. Причем, мы переносим машины целиком — со всеми настройками и прочим, что исключает внешние факторы.


          Да, тест несовершенен — но он делает то, что делает: «измеряет скорость загрузки ядра в секунду» :-). Если цифры меньше, значит стало хуже для ядра. Конечно стрест-тест АПИ не помешал бы дополнительно.

          Также объективно полезная установка Nginx в дополнение к Apache на Битрикс приводит к падению цифр производительности до очень низких.


          У нас nginx+apache входит в виртуальную машину, без него даже запускаться не рекомендуем.

          Тоже самое касается режима запуска PHP как mod_fcgid и Вы вынуждаете пользователей использовать тотально небезопасный режим PHP как модуля веб сервера Apache.


          На Битрикс24 вовсю используется режим php-fpm, как более быстрый и меньше жрущий памяти. Включение его в виртмашину — обсуждается. Php-fpm — несомненно лучше.

          Число настроек в предсобранном образе честно говоря зашкаливает при полном отсутствии описания что делает какая из них. Настройки MySQL и PHP — это вообще отдельная тему и понять ее почти нереально. Мы на стенде так и не смогли полностью извлечь все настройки для использования на обычном сервере.


          Какие именно, давайте поясню каждую! Сделано как можно проще же, но не проще необходимого (А.Энштейн)

          Алсо, мы хотеть — гайд по установке и оптимизации машин на Debian 7+/Ubuntu 12/14+ под Bitrix не внешними скриптами/образами, а просто по инструкции


          Тут пока проще брать конфиги с виртуалки и адаптировать для дебиана. Дебиан — правильная, авторитетная сборка, никто не спорит.

          В тестере проверять конфиуграцию PHP акселератора, а не просто проверять его наличие.


          Так и делается в админке — мы не только проверяем наличие, но и настройки каждого. Установите продукт и гляньте в админке в инструментах.

          В тестере проверять конфигурацию MySQL и опять же сообщать о проблемах и рекомендованых установках


          Такое есть в продукте — таблица рекомендаций по настройке mysql и анализ текущих параметров, некоторые выделены красным. Там же в админке.

          Либо еще проще — просто рекомендованные файлы конфигурации, которые можно взять и вставать в акселератор/демона.


          Можно брать из вирмашины смело.

          • 0
            Спасибо вам за развернутые ответы и статью! Радует что не на «отойдите от меня» написали.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка