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

    Психология — интересная и иногда полезная наука. Многочисленные исследования показывают, что задержка в отображении веб-страницы дольше 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 мая. Всем удачи и успехов в нелегком деле обеспечения производительности веб-проектов!
    1С-Битрикс 66,76
    Компания
    Поделиться публикацией
    Комментарии 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
                            Если решились на описание технологий\систем, ускоряющих ресурс, то упустили некоторые вещи, а именно кеширование — тут нам помогут и значительно упростят жизнь манифесты, 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
                                        Спасибо вам за развернутые ответы и статью! Радует что не на «отойдите от меня» написали.

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

                                Самое читаемое