1. Возможность загрузки и хранения файлового кеша наборов Ресайзера в облачные хранилища.
Теперь все генерируемые модулем ресайзы картинок можно загружать в облачные хранилища для уменьшения нагрузки на ваш хостинг, а также экономии места на хостинге. Для того, чтобы переместить файловый кеш Ресайзера в облачное хранилище, необходимо зарегистрировать аккаунт в одном из таких хранилищ, которые поддерживаются платформой 1С-Битрикс, настроить подключение к своему облачному хранилищу в административной части вашего сайта и задать необходимые правила для отбора файлов в облачное хранилище.
Для того, чтобы кеш Ресайзера загружался в облако, в правилах облачного хранилища необходимо указать модуль "yenisite.resizer2".
Желательно не указывать модуль iblock - если исходные изображения будут выгружены в облако, тогда Ресайзеру придется каждый раз скачивать каждую картинку из облака при необходимости создать уменьшенную копию или копию с водяным знаком. Это может сказаться негативно на времени выполнения первых хитов, когда Ресайзер еще не создал свой кеш.
Возможность отправки картинок модулем приносит нам следующие выигрыши:
мы выигрываем в размере дискового пространства на сервере.
При большой номенклатуре товаров на сайте, особенно если у товаров полные и объемные галереи фотографий, то кеш ресайзенных картинок может занимать заметное количество дискового пространства. При этом не на всех тарифах у хостеров есть возможность опционального расширения доступного дискового пространства. А если даже и есть обычно это достаточно дорого или входит в более дорогой пакет услуг, которые зачастую и не нужны. Подключая облачное хранилище мы избавляемся от проблем расширения дискового пространства на хостинге
также мы выигрываем в скорости загрузки контента посетителями сайтов.
Во-первых потому, что в общем случае канал до дата-центров с облачными хранилищами достаточно хороший и бывают ситуации, что он лучше чем до сервера непосредственно с сайтом. И во-вторых (и это более значимый момент), что спецификация HTTP/1.1 советует, чтобы браузеры параллельно загружали ограниченное число компонентов веб-страницы с одного хоста. У разных браузеров это число отличается, но в среднем это не более 10 одновременных соединений. Это значит, что если при открытии страницы браузеру нужно скачать 100 файлов с фотографиями, то делать он будет это последовательно. Начнет скачивать первые 10 картинок и пока они загружаются остальные ожидают своей очереди. Сюда относятся не только картинки товаров, но и я вся статика с сайта (JS, CSS, шрифты, все прочие изображения использующиеся на сайте). Если же загрузить изображения в облачное хранилище, то загрузка будет происходить параллельно уже как минимум с 2 хостов, что увеличивает общую скорость загрузки страницы примерно в 2 раза.
Мы на наших демонстрационных сайтах использовали хранилище Google Cloud Storage, куда и загрузили ресайзенные изображения с сайта. На типовой детальной странице товара, загрузка файлов в облачное хранилище дало нам от 0.5 - 1сек во времени загрузки страницы в браузере
Страница товара при использовании облачного хранилища
Страница товара без использования облачного хранилища
Как Вы видите количество и объем загружаемых данных на этих страницах одинаков, однако на первой странице изображения скачиваются из облачного хранилища, а на второй непосредственно с сервера, где расположен сайт.
Все замеры производились с эмуляцией самого первого захода посетителя на сайт (CTRL+F5 в браузере - при этом все ресурсы страницы НЕ берутся из кеша браузера, а скачиваются заново). Естественно реальное время отображение страницы клиенту значительно быстрее указанного времени. Это время "засекается по последнему" - пока абсолютно все ресурсы страницы не будут загружены.
Но ко всем указанным Выше прелестям хотелось бы добавить и ложку дегтя. По-умолчанию в заголовках у всех загружаемые в Google Cloud Storage файлов стоит "Cache-Control:public, max-age=3600". Это значит, что в браузере такие файлы будут кешироваться всего на 1 час (подробнее о заголовке Cache-Control можно прочитать в следующей статье). И при заходе на ту же страницу всего через 1 час данные файлы будут повторно проверяться, а не изменились ли они на сервере, что сказывается на скорости работы.
Также данные заголовок влияет на показатели теста Google PageSpeed Insights.
Это конечно достаточно забавная ситуация, когда один инструмент Google ругается на другой свой же инструмент. Разрешить данную ситуацию можно 2 способами:
чтобы при загрузке новых файлов в облачное хранилище у них устанавливался заголовок Cache-control: max-age с бОльшим значением. К сожалению здесь мы упираемся в ограничения в платформе 1С-Битрикс, в которой нельзя устаналивать данный заголовок для загружаемых в облачное хранилище файлов. Запрос на доработку данного момента мы уже отправили, сотрудниками Битрикса он принят с категорией "Пожелания". Будем надеяться данное пожелание будет реализовано быстрее, нежели большая часть вопросов попадающая в категорию "Пожелания". Призываю заинтересованных поддержать нас в данном вопросе и показать Битриксу, что это критически важный момент в работе функционала "Облачные хранилища"
также можно самостоятельно сменить данный заголовок для уже загруженных в облако файлов. Для этого достаточно выполнить следующую команду в консоли сервиса
, где max-age=259200 - указание времени кеширования файлов в секунах, 259200 секунд = 3 дня upload-local/resizer2/* - путь до обрабатываемых файлов. upload-local - это название директории в хранилище для Вашего сайта. resizer2/* - это означает, что необходимо обработать все файлы находящиеся в поддиректории resizer2
Неудобство данного подхода в том, что необходимо периодически выполнять данную команду, ведь в хранилище постепенно будут добавляться новые файлы.
2. Реорганизация хранения файлового кеша Ресайзера.
Из-за того, что раньше весь файловый кеш Ресайзера хранился в одной директории жесткого диска, при очень большом количестве изображений могло наблюдаться падение производительности файловой системы при работе с файлами в этой директории. Новая структура хранения кеша Ресайзера позволит избежать падения производительности файловой системы. К сожалению, старый кеш невозможно автоматически привести к новой структуре, и он никуда не исчезнет, поскольку ссылки на изображения могут быть закешированы во многих местах сайта. Рекомендуем удалить старый кеш Ресайзера вручную и сбросить кеш всех компонентов, чтобы перевести весь сайт на использование новой структуры кеша Ресайзера.
3. Сохранение изображений JPG в формате прогрессивного JPEG.
Все большие и средние фотографии JPG (больше 150х150 пикселей) теперь сохраняются в прогрессивном формате. Прогрессивные jpeg большого размера при том же качестве изображения статистически чаще весят меньше, чем обычные jpeg закодированные в формате baseline. И при этом такие изображения отрисовываются браузерами в несколько раз быстрее. Мы можем наглядно посмотреть, как именно браузеры отрисовывают картинки jpeg этих двух форматов с помощью двух анимированных GIF.
Baseline:
Progressive:
Поскольку это лишь анимированные GIF, то они не передают на 100% внешний вид самих jpeg, но по ним можно понять основной принцип отрисовки таких изображений. Подробнее ознакомиться с преимуществами прогрессивного jpeg можно в следующих двух статьях: на русском языке - https://habrahabr.ru/post/165645/ (2013 год) и на английском языке - https://www.besthostnews.com/how-progr...r-website/ (2016 год)
4. Вставка готовых URL изображений на статичные страницы сайта вместо ссылки на скрипт генерации.
В визуальном редакторе Битрикса есть кнопка Ресайзера для вставки маленькой картинки-превью нужного размера в любом месте страницы со ссылкой на большую картинку. Раньше URL для маленькой и большой картинки вел на PHP-скрипт, который занимался генерацией и выдачей этих изображений. Теперь же изображения генерируются в момент отправки формы и на страницу сразу попадают ссылки на готовые картинки. Данное нововведение скорее улучшает не производительность сайта, а на его SEO ориентированность. Ведь раньше вместо конкретных картинок вставлялся путь на PHP файл, который уже в свою очередь и генерировать изображение для посетителя. И в этом случае поисковики не могли корректно проиндексировать такие картинки.
Имейте ввиду, что в этом случае картинки не смогут обновиться автоматически при изменении настроек водяного знака или размера набора, и вам придется вставлять их повторно.
Кроме того: В этой версии мы переработали, переформатировали, почистили и оптимизировали большую часть API модуля. Исправлены и оптимизированы алгоритмы ресайза и наложения водяных знаков. Улучшено использование кеширования и тегирования кеша в методах API модуля. Уменьшен объем исполняемых файлов и общий вес дистрибутива за счет удаления устаревшего и избыточного кода и файлов. Все методы API задокументированы комментариями в формате PHPDoc.
Вторая часть статьи посвящена переходу всех наших типовых решений на PHP7
Мы перевели все наши демонстрационные сайты на использование PHP версии 7. В данной версии PHP помимо ряда других улучшений (о них можно прочитать например в следующей статье) значительно улучшена производительность.
Проведенные замеры выглядят многообещающе — тесты, выполненные на реальных приложениях показывают, что PHP 7 в среднем вдвое быстрее PHP 5.6, а также использует на 50% меньше памяти вовремя обработки запросов.
В среднем переход с PHP5.6 на PHP7 дает прирост скорости в среднем в 2 раза. Продемонстрируем это на собственных замерах.
PHP5.6 - в среднем время генерации детальной страницы товара на сервере составляет 0.35сек
PHP7 - стоит только сменить версию PHP на сервере и та же страница на сервере уже генерируется в среднем за 0.18сек, а иногда и быстрее
Покажем, что же происходит с панелью производительности:
PHP5.6
PHP7
Мы видим, что общая оценка также возросла примерно в 2 раза.
Хотелось бы отметить, что мы специально не делали никаких "синтетических" тестов. Конечно можно было бы получить более высокие и красивые цифры на выделенных и VIP тарифах хостинга. Однако все произведенные выше тесты мы специально сделали на наших демонстрационных сайтах, которые работают на самом обычном shared-хостинге менее чем за 1000руб в месяц. При этом только у нас на данном хостинге работает порядка 30 сайтов, не говоря уже про соседей по shared-серверу.
С удовольствием выслушаем все Ваши замечания, пожелания, предложения по статье.
Mikhail Kryachek, как и написано в статье, обычный shared хостинг менее чем за 1000руб/месяц. Данный показатель как раз таки отображает количество операций процессора в секунду (CPU). И за счет оптимизации многих команд в php7, теперь тот же процессор успевает выполнить их значительно больше. А на сколько изменяется скорость CPU у Вас при смене php5 -> php7? Если у вас другие цифры, поделитесь, думаю всем будет интересно.
На шаредхостинге не совсем корректно, конечно, тестить такие вещи. Там все показатели плавают в зависимости от нагрузки на соседей по "коммуналке" же. Давайте уже на выделенном сервере тестить
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».