Последние сообщения блогов

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

Как же на практике проходит оптимизация?

Есть несколько направлений, в которых идет работа:
* оптимизация кода
* оптимизация запросов, числа запросов, цены запросов, объемов передаваемых данных
* оптимизация архитектуры
* уменьшение объемов исполняемого и компилируемого кода
* поиск новых решений

Как я уже говорил, одна из задач по оптимизации заключалась в том, чтобы оптимизировать работу базовой версии продукта Старт. Про оптимизацию по SQL запросам я уже писал в первых постах. Результаты отличные. Стоит рассказать немного, как идет оптимизация кода.

Мы используем один из лучших профилировщиков для PHP xdebug

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



Функции оптимизируются до тех пор, пока не оказываются "внизу" топа.



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

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

Объем компилируемого кода и время компиляции кода так же является важным направлением оптимизации. В PHP5 появилась возможность загрузки кода только при первом факте использования ( __autoload )

Autoload позволяет подгружать только те файлы модуля, которые нужны для работы. Например, если пользователь открыл каталог товаров, то подключаются модули каталога и магазина. При этом подавляющее большинство функционала этих модулей в данном случае не нужно. Но при обычном подключении в PHP4 весь функционал подгружается и обрабатывается.

Если использовать Autoload, то никакие скрипты не подгружаются до первого использования их функционала. А так как в каталоге товаров нужен грубо говоря только класс корзины и (может быть) заказа, то остальные скрипты просто тихо лежат на диске.

Преимущества очевидны в данном случае, но только нужно соблюдать совместимость версий PHP4 и PHP5, а лучше даже единство кода.

В частности, такая методика впервые будет использована в ближайшем обновлении модулей Интернет-магазина и Торгового каталога. При тестировании выяснилось, что на каждом отдельном хите выйгрыш не просматривается, так как машина свободна. Но при максимальном нагрузочном тестировании эффективность Autoload составила порядка 20% по памяти и производительности. Что очень даже ощутимо для нагруженных проектов и виртуального хостинга.

Еще одна хорошая новость.

В ближайшее время появится новый класс кэширования (построенный, конечно, на стандартных классах кэширования), который эмулирует кэш баз данных LRU (Least Recently Used) http://en.wikipedia.org/wiki/Cache_algorithms

Цель появления такого КЭШа такова: некоторые данные могут иметь теоретически неограниченно большой размер, поэтому их полное кэширование не представляется возможным. Но в реальной жизни и на реальном сайте эти данные могут быть весьма ограничены и/или какие-то из этих данных будут более востребованы, чем остальные. Причем некоторые данные очень часто запрашивается на сайте.

Мы посчитали, что имеет смысл как-то кэшировать эти данные. Но так, чтобы кэш не оказался многомегабайтной длины (что очевидно не только не убыстрит, но и даже затормозит работу). LRU кэш является управляемым и имеет управляемый размер (настраивается для каждого кэшируемого объекта).

Если происходит запрос к кэшируемому объекту, то объект сначала проверяется в КЭШе. Если там уже есть необходимые данные, то они передвигаются в начало КЭШа и возвращаются без запросов и вычислений. Если данных в КЭШе нет, то они выбираются (и вычисляются) и добавляются в начало КЭШа. Если при этом КЭШ перерос ограничения по длине, то последний элемент из него вытесняется.

Таким образом кэш ограничен по размеру на случай очень большого числа данных в базе. Если данных окажется реально немного, то они будут полностью кэшированы. Если данных много, но одни из них запрашиваются чаше других, то высока вероятность, что часто запрашиваемые данные будут постоянно жить в КЭШе (так как из КЭШа при переполнении удаляются те данные, которые дольше всего не запрашивались).

Первоначально этот тип кэширования будет применен к некоторым объектам в каталоге. Например, к скидкам.

Но для данных, которых заведомо мало, лучше использовать управляемый кэш. В частности, в новом модуле валют вообще не будет возникать запросов к базе данных при использовании большинства функций. Управляемый кэш сейчас будет применяться и в инфоблоках для обработки наиболее частных операций.

Опять же в качестве примера, успешно оптимизирован модуль опросов. Кэшированы группы опросов, права доступа, сайты. Оптимизирован повторный вызов функций. Использование модуля существенно оптимизировано.

Оптимизированные модули, безусловно, отражаются на скорости работы публичных компонент и административных разделов сайта.

Ожидаем в ближайшее время обновление по Интернет-магазину, торговому каталогу, опросам, техподдержке, инфоблокам, главному модулю, форумам...

Продолжается работа над новым интерфейсам.

В новой версии 5.0 мы полностью сменили концепцию и добились прекрасных результатов в работе с информацией. Этому посвящен отдельный раздел на сайте: http://www.bitrixsoft.ru/sitemanager/usability.php
И отдельный учебный курс:
http://www.bitrixsoft.ru/learning/course/index.php?COURSE_ID=1

Но работы продолжаются. И сегодня мы расскажем об изменениях, которые произойдут в публичной административной панели с выпуском обновления главного модуля 5.1.3.

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

Для удобства работы с административной панелью появилась возможность зафиксировать ее положение на экране. В этом режиме панель всегда видна в верхней области экрана. (Все примеры даны в середине экрана, чтобы показать позиционирование панели)







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



Безусловно, параметры компонент можно будет править и в визуальном редакторе. Но теперь, чтобы только изменить параметры компоненты не потребуется открывать визуальный редактор. Это так же позволит управлять компонентами, которые размещены в шаблоне дизайна.

Изменения в интерфейсе еще будут, следите за новостями

В режиме бета-версии стали доступны обновления еще под трем модулям: информационные блоки, форум, управление структурой сайта (визуальный редактор).

Форум:

Новые его возможности можно было всю эту неделю видеть на нашем сайте. Это, конечно же, приватные сообщения и "антимат" (хотя с этим на нашем сайте и раньше проблем не возникало), ну и многое другое. Чтобы все заработало в полную силу, необходимо либо использовать наши стандартные компоненты, либо модифицировать кастомизированные.

Полный список изменений:
- Добавлена новая возможность отправлять личные сообщения зарегистрированным посетителям форума. Работа с сообщениями осуществляется на странице "Личные сообщения", где можно написать, прочитать, удалить письмо в корзину или сохранить его в одной из настраиваемых папок. При получении нового личного сообщения, пользователю приходит уведомление по E-Mail. Для персональных сообщений в настройках модуля форума можно установить лимит по максимальному количеству личных сообщений в ящике
- Добавлен механизм фильтрации нецензурных слов. Фильтр основан на работе словаря нецензурных слов и словаря транслитерации (правил всевозможного написания сивмолов). Также есть возможность поиска и замены нецензурных слов на основе регулярных выражений. При установке будут добавлены русский и английский словари, чтобы включить фильтр необходимо установить соответствующий флажок в настройках модуля форума
- Добавлена возможность предпросмотра сообщения перед отправкой
- Новая страница для просмотра последних тем на всех форумах
- Новая страница списка пользователей форума. Для каждого пользователя выводится сводная информация по темам, сообщениям, даты регистрации и последнего посещения
- Новая страница списка всех тем и всех сообщений пользователя
- Добавлена возможность модератору переносить темы текущего форума на другой форум, где он не является модератором
- В списках тем и форумов модераторам показывается количество непроверенных сообщений
- Новая административная страница "управление темами" - для возможности управления темами из административного интерфейса
- Внесены косметические изменения в страницу профиля пользователя
- Появилась возможность подписки на текущую тему при создании сообщения

Модуль Управления структурой:

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

Полный список изменений:
- Добавлена функция проверки орфографии с возможностью использования орфографии клиентского Microsoft Word (только для IE) и(или) серверного Pspell
- Добавлена возможность редактирования таблиц (добавление/удаление строк, столбцов, ячеек) при помощи контекстного меню
- Новая кнопка на панели инструментов "Выделить все"
- Новый диалог вставки специальных символов
- Добавлена возможность включать/отключать автоперенос строк в режиме редактирования исходного кода (только для IE)
- Увеличена скорость работы кнопок панели инструментов в Internet Explorer
- Устранены утечки памяти, что, в результате, повысило общую производительность и стабильность работы визуального редактора
- Устранена ошибка аварийного завершения работы Internet Explorer при выполнении некоторых операций с контекстным меню и выпадающими списками в интерфейсе
- Устранена ошибка изменения атрибутов src у изображений и href у ссылок с относительных на абсолютные при их перетаскивании и работе с буфером обмена
- Устранена ошибка замены специальных символов (html-сущностей) их HTML эквивалентами при переключении между режимами html и исходного кода
- Устранена ошибка отсутствия реакции списка стилей в панели свойств при их изменении

Информационные блоки:

Это, во-первых, новый тип хранения значений свойств элементов - в отдельных таблицах. Данная методика позволяет работать со значениями свойств, не добавляя JOIN-ы для каждого свойства в запросы к БД. Также, при новом типе хранения уменьшается общее количество записей в одной таблице, что также положительно сказывается на скорость выборки. Замечу, то, что этот тип хранения новый, не означает что он во всем лучше старого, просто он лучше при определенных условиях, а именно активной работе со значениями свойств (фильтр, сортировка, выборка). Для схемы "просто выбрать элементы"-"выбрать все его свойства", в общем случае, будет эффективней использовать первую версию. Плюс, новый тип хранения требует изменения компонент для его эффективного использования (стандартные компоненты, оптимизированные под новый тип, выйдут чуть позже). С новым типом пока не работает быстрая загрузка из CommerceML.

Другое заметное нововведение в модуле - возможность создавать пользовательские типы свойств, при помощи обработки события. Документации по этой возможности пока нет, но есть два замечательных примера - реализация типов "дата" и "привязка элементов по внешнему коду". Их реализацию можно увидеть соответственно в файлах prop_datetime.php и prop_xmlid.php, папка /bitrix/modules/iblock/classes/general/. Произвольные типы позволят в дальнейшем создавать такие свойства как: привязка к пользователю, теме форума и т.п.

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

Полный список изменений:

Инфоблоки+. Добавлен новый режим хранения значений свойств элементов информационных блоков в отдельных таблицах для каждого инфоблока. Добавление или изменение новых свойств модифицирует структуру таблицы инфоблока+.
Данный режим позволяет увеличить производительность фильтрации, сортировки и группировки элементов информационных блоков по значениям их свойств, а также увеличивать скорость выборки значений свойств одновременно с полями элемента. Для перевода информационного блока в новый режим необходимо выполнить его конвертацию в административном разделе, а также модифицировать компоненты его показа для более эффективного использования новой версии. Подробнее смотрите в документации.
- Добавлена поддержка пользовательских типов свойств. Для создания своего типа необходимо добавить обработчик события OnIBlockPropertyBuildList.
- На основе возможности создавать пользовательские типы свойств, добавлены два новых типа: Дата/Время и привязка к элементам по внешнему коду.
- Добавлен смешанный вид просмотра элементов и разделов. В этом режиме элементы и разделы информационного блока отображаются в общем списке (как файлы и папки). Новый режим включается в настройках модуля информационных блоков.
- При удалении элемента автоматически удаляются все его связи с другими элементами и группами.
- В параметры информационного блока добавлены два новых поля: "Файл для редактирования элемента, позволяющий модифицировать поля перед сохранением" и "Файл с формой редактирования элемента" - для установки своих скриптов редактирования элемента для каждого инфоблока, а не целиком типа информационных блоков.
- Исправлена ошибка редактирования элемента в списке административного раздела.

В рамках подготовки к версии 5.1 вышло большое обновление Интернет-магазина.
Пока доступно в режиме бета-тестирования.

Появилась аффилиатная система, причем очень масштабная, включает даже многоуровневых аффилиатов (Multi Tier Affiliate Program), появились многоразовые и одноразовые купоны, которых ждали и масса других возможностей.

Торговый каталог:

v5.1.0
# Ускорена работа функции выборки скидок путем предпросчета данных.
Внимание! После установки обновления необходимо сгенерировать данные для предпросчета. Для этого воспользуйтесь кнопкой "Перегенерация" на странице глобальных настроек модуля "Торговый каталог".
# Появились многоразовые и одноразовые купоны.
# Исправлены некоторые ошибки скриптов импорта и экспорта данных.
# Появились новые события модуля catalog:
OnGenerateCoupon - событие на генерацию купона, может использоваться для генерации купонов нестандартного вида;
OnGetDiscountByPrice - на получение скидки по коду цены, может использоваться для подмены стандартного алгоритма вычисления скидки своим;
OnGetDiscountByProduct - на получение скидки по коду товара, может использоваться для подмены стандартного алгоритма вычисления скидки своим.

Интернет-Магазин:

v5.1.0
# Добавилась возможность организации аффилиатской сети магазина. Комиссия аффилиата может зависеть от количества товаров, проданных за определенный период через аффилиата, либо от суммы стоимостей товаров, проданных за определенный период через аффилиата. Появилась возможность организовать многоуровневое аффилиатство, при котором аффилиат будет получать доход не только от товаров, проданных через него, но и от товаров, проданных через других аффилиатов, которые пришли на сайт благодаря ему. Заработанные деньги могут либо выплачиваться аффилиату, либо заноситься на его внутренний счет в магазине.
# Внимание! Изменена система прав доступа для менеджеров магазина. Если вы использовали прежнюю систему нестандартным образом, убедитесь в работоспособности вашего сайта на тестовой копии перед установкой обновления на рабочую копию.
Система прав стала более гибкой: появилась возможность указать для каждого статуса кто может менять заказ, кто может смотреть заказ, кто может менять статус и т.д.
После установки обновления проверьте в глобальных настройках модуля магазина права групп пользователей на доступ к магазину, права групп пользователей на доступ к заказам разных сайтов, а так же в форме управления статусами права групп пользователей на доступ и изменение заказов в разных статусах.
# Изменилась форма редактирования заказа. Появилась возможность автоматически пересчитывать суммы заказа на основании настроек магазина, разделять заказ на два заказа с пересчетом суммы или без него.
# Появилась возможность добавлять пользовательские скрипты экспорта заказов.
# Скидки по объему заказа теперь имеют период действия.
# Появились новые события модуля sale:
OnOrderListFilter - для дополнительной фильтрации списка заказов в административной части;
OnProductSearchForm и OnBasketItemSave - для изменения параметров элемента заказа при редактировании заказа.
# Появилась возможность блокировать заказ для его обработки (для того, чтобы одним заказом не занимались два менеджера).

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

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

Как вы видите, мы закрывали наиболее значимые проблемы для наших клиентов.

На сегодняшний момент мы считаем, что наиболее актуальная для наших клиентов проблемы - это производительность продукта. И именно этому вопросу будут посвящены значительные усилия в развитии ближайшего времени.

Производительность - это очень многогранная проблема.
В производительности участвует парсинг кода PHP, исполнение кода PHP, запросы к базе данных, конкуретная нагрузка и блокировки в базе данных, объемы передаваемых данных, число запросов к базе, производительность веб-сервера, буферы для страниц для PHP и масса других параметров и характеристик.

Причем, поведение одного и того же кода может принципиально отличаться для выделенного сервера или для виртуального хостинга. За счет чего?

Например, на выделенной машине база данных и запросы к данным кэшированы. Т.е. обычный select * from b_lang таблицы с двумя строчками данных выполняется за 0.000ХХ секунды. Так как данные просто уже в памяти базы данных и не требуется выполнять медленную операцию чтения данных с диска.

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

Аналогичная ситуация с файлами PHP. Мы делаем Include файла PHP. Его нужно прочитать с диска. На выделенной системе этот файл в файловом КЭШе и читается быстро. Как результат, время выполнения скрипта, а в него все включается и парсинг и чтение файла и исполнение, будет минимальным.

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

Причем получается, что чем меньше посещаемость сайта, тем больше проект вытесняется из КЭШа базы данных и файлового КЭШа и тем медленнее работает.

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

В этом сообщении я немного расскажу об обновлении главного модуля 5.1, которое будет выпущено в ближайшее время. Вообще, в ближайшее время планируется много обновлений, но это будет интересно с точки зрения производительности.

Начнем.

1. Оптимизация кода ядра.
Проведена глобальная проверка и оптимизация кода ядра продукта. Фактически, каждый участок кода был перепроверен. Весь продукт многократно исследовался специальными продуктами оптимизации. Каждая функция и системный вызов проверялись. Некоторые функции были оптимизированы или просто переписаны. Исследовалось и оптимизировалось покрытие кода, поведение под нагрузкой и в разных тестовых системах.

2. Число SQL запросов к базе данных.
Ядром продукта используются справочные таблицы, обычно небольшого размера с редко изменяющимся содержимым. Запросы к таким таблицам выполняются быстро, но только в случае, когда кэш базы данных не "перегружен" и задержки на передачу запроса по каналу и получение данных от SQL сервера невелики. В противном случае целесообразнее использовать файловый кэш.

В версии продукта 5.1 реализован так называемый "управляемый КЭШ".

Управляемый кэш - означает, что при изменении данных, кэш сам чиститься и обновляется. Т.е. кэширование работает прозрачно и незаметно для пользователя.

На статической странице наш продукт выполняет до 24 запросов. В новой версии ядра, не потребуется ни одного SQL запроса, более того, продукт сможет обойтись даже без открытия соединения к базе данных. И что очень важно, будут отсутствовать запросы на блокировку данных таблицы агентов и событий, что увеличит параллельность исполнения.

Файлы кэша создаются в подкаталоге /bitrix/cache/bitrix, т.е. требуются соответствующие права операционной системы на запись в данном каталоге.
По умолчанию в версии 5.1 кэш ядра будет включен. Для его отключения требуется в файле /bitrix/php_interface/dbconn.php определить следующие константы:

define("CACHED_b_lang", false);
define("CACHED_b_option", false);
define("CACHED_b_lang_domain", false);
define("CACHED_b_site_template", false);
define("CACHED_b_event", false);
define("CACHED_b_agent", false);

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

Как я уже сказал, очистка и обновление КЭШа будет происходит автоматически при изменении данных. Естественно, что изменение будет выполняться только в случае, когда такое изменение происходит с использованием API продукта.
Также есть возможность настроить время кэширования.
Например:
define("CACHED_b_option", 3600*24);

По умолчанию кэширование будет выполняться на 1 час. Мы считаем этого достаточным.

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

Для работы такого режима достаточно в файле /bitrix/php_interface/dbconn.php определить следующую константу:

define("DELAY_DB_CONNECT", true);

Тогда подключение к БД будет выполнено при первом запросе через API продукта прозрачно для разработчика.

По умолчанию эта возможность будет выключена т.к. не редка ситуация "прямых"
вызовов функций базы данных из PHP. Но в новом дистрибутиве продукта мы планируем этот режим включить.

3. Оптимизация работы меню.
Следующий важный пункт - оптимизация дисковых операций для разделяемого хостинга. Тесты показали, что кэширование части операций в меню позволит ускорить работу.

В новой версии 5.1 будет по умолчанию включен режим кэширования права доступа и части проверок для меню для неавторизованных пользователей. Учитывая, что большая часть посетителей - это незарегистрированные пользователи, к ним применен специальный алгоритм кэширования. Кэш управляемый и обновляется при редактировании меню или изменении прав доступа к файлам и папкам через административный интерфейс и API. Т.е. обычные пользователи вообще не заметят, что существует какой-то алгоритм кэширования. Если только разработчики правят меню руками, то им потребуется скинуть кэш меню в интерфейсе. Кэш можно будет отключить, определив следующую константу:
define("CACHED_menu", false);

===================

Перечисленные оптимизации по нашим тестам обеспечили на выделенной тестовой машине более чем 40% ускорение. Мы ожидаем, что на виртуальном хостинге ускорение будет еще больше.

Так же отмечу, что в новой версии ядра для параметров show_page_exec_time=Y и show_include_exec_time=Y для админа будет выводиться дополнительная информация по числу SQL запросов и общему времени исполнения запросов на SQL сервере. Это поможет разработчикам быстрее выявлять узкие места в разработке.

Оптимизация через создание файлов КЭШа имеет еще одно большое преимущество для проектов, которые используют прекомпиляторы. Файлы КЭШа являются PHP файлами, отлично прекомпилируются и хранятся в памяти, что дает еще больший прирост производительности.

В завершении этой темы отмечу, что для всех проектов мы рекомендуем PHP прекомпиляторы, это очень существенный ресурс оптимизации PHP приложений.

Ждем обновление 5.1  

Дальше на очереди, инфоблоки+ (выпуск уже скоро), реклама, статистика, поиск и другие модули...