Многие разработчики партнеров захотели на выходных заняться уже подготовкой своих компонент и интеграцией со Smarty. Только должен напомнить, что в API компонент 2.0 возможны незначительные изменения, так как релиз предварительный.
Документация по компонентам 2.0 опубликована на сайте: http://www.bitrixsoft.ru/download/components2.zip В поставке есть несколько примеров. Визуальная поддержка вторым компонентам еще не реализована и будет выпущена в начале следующего года.
Добавлены давно ожидаемые свойства: * html/текст (с визуальным редактором) * путь к файлу (с диалогом выбора файла) * привязка к пользователю Планируется к выпуску еще несколько свойств, но уже в новом году.
Производительность только модуля статистики улучшена почти в два раза!
Модуль значительно переработан внутри. Очень сильно улучшена работа агентов по чистке. Раньше именно на этом происходили проблемы с очисткой данных. Значительно ускорен сбор данных по всем отчетам и значительно снята зависимость времени исполнения от объемов данных. Заметно уменьшено число запросов и каждый запрос проверен самым тщательным образом, оптимизирован и согласован с индексами. Так же реализована поддержка PHP 5 (поддержка autoload) для модуля статистики.
Обратите внимание, добавлен новый параметр "Индексные страницы разделов", позволяющий избежать дублирования страниц в отчетах (например, / и /index.php) Этот параметр не будет заполнен у вас после установки обновление. Мы у себя на сайте прописали index.php, index.html
При работе с модулем ваше внимание будет обязательно обращено на необходимость создания индексов. Это долгая процедура и может занять несколько минут или даже десятков минут, если у вас очень много данных! Все запросы будут вам представлены в текстовом виде и вы можете при необходимости выполнить их не через продукт, а через SQL запросы к MySQL, Oracle, MSSQL. Создание индексов обязательно для обеспечения производительности, но выполнить запросы во время обновления было нереально.
Исправлен ряд ошибок в работе статистики. В частности, исправлена ошибка, о которой писали в закрытом форуме с PHP функцией crc32 для 64-х битных платформ.
Вышло обновление форумов 5.1.5, которое в основном улучшает интерфейс и корректирует небольшие ошибки.
Ну что, можно сказать, что новая версия 5.1 перешла из состояния бета-версии в релиз. Клиенты устанавливают, больших проблем пока не замечено. Идет сборка нового дистрибутива. Готовится официальный тест по нагрузочному тестированию.
Выпуском 5.1 мы завершили первый этап оптимизации, впереди еще ждет статистика, поиск и ряд других интересных идей...
Как я уже сказал, мы планируем провести масштабное нагрузочное тестирование. Но в рамках работы мы сами проводили тесты, о которых можно немного рассказать.
Начиная с версии 5.1.4 главного модуля, появились расширенные инструменты для отладки производительности компонент и всего сайта в целом.
Все уже знают параметры для страницы:
show_page_exec_time=Y - Выводит общее время исполнения страницы
show_include_exec_time=Y - выводит время исполнения каждой из компонент. В новой версии ядра еще выводится время формирования меню.
Появился еще один интересный параметр: show_sql_stat=Y
Этот параметр работает в корреляции с вышеперечисленными параметрами и выводит число SQL запросов, общее время исполнения SQL запросов и позволяет проанализировать сами запросы, как на всю страницу, так и на отдельно взятый компонент или меню.
Пример:
На этом рисунке представлена статистика SQL запросов для компоненты новостей на нашей главной странице. Выводится она 2 запросами. Общее время работы компоненты составляет 0.067 с. Время SQL запросов 0.0211 с или 31.49% от времени работы компоненты (%помогает выявлять ресурсоемкий PHP код или тяжелые запросы). Возле каждого запроса указывается, сколько раз аналогичные запросы повторялись с вариацией параметров. В статистике перечисляется, откуда вызван запрос и с какими параметрами.
Следующий пример со страницы блога. Запросов уже 5 штук. Но они потребляют меньше 7% от времени компоненты, которое составляет 0.0206 с. Важно, что само по себе число запросов не играет решающей роли, важнее время выполнения запросов.
Практика использования инструментария позволит: * быстро выявлять больные участки сайта * находить ошибки программирования, в которых компонент генерирует очень много запросов или мало, но медленных запросов (поддержкой были выявлены случаи, когда модифицированный партнером компонент вместо 3 наших запросов генерировал больше 4 тысяч и убивал сервер наповал) * выявлять особенности и недостатки конфигурации SQL сервера или отдельных таблиц (бывали случаи, когда обычный запрос на отдельном проекте работаел в сотни раз медленнее. Причина был в MySQL и лечилось все оптимизацией проблемной таблицы) * помочь партнерам указать нам на неоптимальные компоненты или проблемные участки, чтобы переработать их и улучшить производительность (чего греха таить, ряд компонент уже переписаны нами для нового дистрибутива, а некоторые находятся в работе)
Мы планируем и дальше развивать инструментарий отладки. Уже есть понимание, в каком направлении и как это лучше представить отладку в интерфейсе панелей, чтобы не вводить параметры руками.
Готовится к выпуску ряд завершающих обновлений по продукту в плане подготовки к выпуску 5.1.
Готовы и частично опубликованы следующие обновления: Главный модуль, Информационные блоки, Форум, Рекламы, Торговый каталог, Интернет-Магазин, Обучение, Опросы, Валюты. На очереди - Техподдержка, Управление структурой и визуальный редактор.
До релиза 5.1 осталось уже недолго.
Про функциональные изменения в модулях смотрите в истории версий: http://www.bitrixsoft.ru/sitemanager/versions.php эта страница ведется автоматически и представляет описания после появления обновления в системе SiteUpdate.
В своем сообщении я остановлюсь именно на вопросах производительности продукта.
Главный модуль 5.1.4:
В главном модуле переработаны целый ряд методов и функции. Код стал еще более оптимизированным для больших нагрузок и виртуальный хостинг.
В дополнение к имеющимся механизмам управляемого КЭШа добавился механизм кэширования графических файлов из библиотеки изображений (таблица b_file).
Рекомендуется включать этот механизм на виртуальных хостинга для уменьшения числа SQL запросов к удаленной или медленно базе данных. На выделенных машинах этот тип кэширования заметного результата может не дать. Рационально использовать такой кэш, если число файлов не очень большое (не больше 10 тысяч) или на странице выводиться одновременно много элементов.
Для этого типа информации использована интересная методика кэширования с разделением хранилища на секции. Это позволяет уменьшить число файлов и сделать кэш эффективней. Причем данные кэшируются с опережением, что даже при включении позволяет уменьшить число запросов. Но отметим, что по умолчанию этот механизм выключен, так как нет пока возможности определять динамически число файлов в b_files во время работы, а проектов с большим числом файлов возможно создание объемного кэша. Но мы рекомендуем попробовать включить кэширование на виртуальном хостинге и индивидуально для свое проекта определить применимость данного инструмента.
Добавлена поддержка управляемого кэша для типов информационных блоков и значений свойств типа "список". Константы CACHED_b_iblock_type и CACHED_b_iblock_property_enum соответственно.
По умолчанию кэширование включено и значения следующие: define("CACHED_b_iblock_type", 3600); define("CACHED_b_iblock_property_enum", 3600);
В функциях работы со списками элементов в массив возвращаемых полей элементов добавлено поле PROPERTY_*. Используется только в Инфоблоках+ и только при отсутствии группировки списка. Использование этого поля позволяет избежать дополнительных запросов к БД при вызове метода _CIBElement::GetProperties.
Также если в массиве возвращаемых полей элементов встречаются поля DETAIL_PAGE_URL, SECTION_PAGE_URL и LIST_PAGE_URL, то в случае отсутствия группировки список полей автоматически расширяется полями необходимыми для макроподстановок элементов пути.
Существенно оптимизированы некоторые компоненты.
Модуль рекламы 5.1.0:
Учитывая, что на странице реклама вызывается многократно, модуль рекламы был заметно оптимизирован.
Оптимизирован сбор статистики. При большом числе баннеров теперь выполняется только один набор запросов по сохранению данных, вместо отдельного набора ранее для каждого баннера.
В настройках модуля добавлена возможность отключить ограничения контрактов при показе баннеров. Если вы не используете контракты, включите эту опцию, это упростит запросы и исключит запросы на запись ненужных вам данных;
В параметрах баннера добавилась опция "Фиксировать число показов баннера". У баннеров, для которых подсчет количества показов не имеет принципиального смысла, рекомендуется отключить данную опцию; Это исключит запросы на запись статистики в базу данных.
Использован Autoload, значит для PHP5 есть предпочтения.
Интернет-Магазин и Торговый Каталог 5.1.Х:
В обоих модулях реализована поддержка Autoload что позволяет получит заметный выигрыш при использовании PHP5.
Оптимизированы компоненты магазина.
Оптимизирован и сделан более универсальным компонент показа цен данного товара. Для показа цен рекомендуется пользоваться компонентом "Цены товара" (price.php).
Оптимизирована функция выборки скидок и другие наиболее используемые методы модуля.
Рекомендуется пользоваться следующими методами: CCatalogGroup::GetListEx - для выборки типов цен с / без фильтра по группам пользователей, которые могут видеть (покупать) по ценам данного типа CCatalogGroup::GetGroupsPerms - для выборки кодов типов цен, которые может видеть и / или покупать член данных групп пользователей (метод использует кеширование) CCatalogGroup::GetListArray - для выборки массива всех типов цен (метод использует кеширование) CPrice::GetListEx - для выборки цен товара с / без фильтра по типу цены и группам пользователей, которые могут видеть (покупать) данный тип цены CCatalogDiscount::GetDiscount - для выборки скидок на данный товар (метод использует кеширование) CCatalogProduct::CountPriceWithDiscount - вычисление реальной цены по цене из каталога и результату метода выборки скидок (не пораждает запросов к базе)
В модуле включена поддержка функционала autoload. Так что не забывайте что PHP5 уже предпочтительнее.
По умолчанию кэширование включено. Ключи управления КЭШем:
* если определена константа CURRENCY_SKIP_CACHE и установлена в True, то валюты кэшироваться не будут * если определена константа CATALOG_STACK_DISCOUNT_LENGTH и установлена в целое число, то она определяет длину LRU кэша скидок (По умолчанию 100). * если определена константа CATALOG_STACK_ELEMENT_LENGTH и установлена в целое число, то она определяет длину LRU кеша групп, в которых находится товар (По умолчанию 200) * если определена константа CATALOG_SKIP_CACHE и установлена в True, то каталог кэшироваться не будет
В завершении про этот модуль пример использования LRU КЭШа.
Класс CStackCacheManager. Объект stackCacheManager создается автоматически. Можно установить длину кеша методом SetLength(entity, length), где entity - некий код сущности (например, catalog_discount для скидок), а length - длина. Можно проверить существование записи для данной сущности методом Exist(entity, key), где entity - некий код сущности, а key - код записи. Если запись с кодом key у сущности entity существует, то ее можно получить методом Get(entity, key). При этом запись в кеше перемещается на первое место. Если записи нет, то ее можно добавить методом Set(entity, key, value). При этом запись ставится в кеше на первое место, а последняя запись убирается, если кеш перерос свою длину. Методом Clear(entity) можно очистить все записи данной сущности.
Пример:
Нам нужно получить значение для ключа "zzz" сущности "my_entity"
$GLOBALS["stackCacheManager"]->SetLength("my_entity", 50); if ($GLOBALS["stackCacheManager"]->Exist("my_entity", "zzz")) { $arResult = $GLOBALS["stackCacheManager"]->Get("my_entity", "zzz"); } else { // Вычисляем $arResult, запрашиваем базу и все такое $GLOBALS["stackCacheManager"]->Set("my_entity", "zzz", $arResult); }
Опросы 5.1.0:
В управляемый кэш добавлены группы опросов, права доступа и привязка групп к сайтам. Время кэширования (в секундах) можно изменить с помощью константы VOTE_CACHE_TIME. По умолчанию время кэширования равно 1 часу. Для отключения управляемого кэша следует установить константу VOTE_CACHE_TIME в значение false;
Оптимизиран метод подключения модуля на странице; Оптимизирован повторный вызов функций;
В общем, стало заметно быстрее.
По мере готовности буду публиковать дополнительные материалы
Когда вся компания занимается оптимизацией, все начинают оптимально думать И это касается каждого разработчика и каждого модуля.
Как же на практике проходит оптимизация?
Есть несколько направлений, в которых идет работа: * оптимизация кода * оптимизация запросов, числа запросов, цены запросов, объемов передаваемых данных * оптимизация архитектуры * уменьшение объемов исполняемого и компилируемого кода * поиск новых решений
Как я уже говорил, одна из задач по оптимизации заключалась в том, чтобы оптимизировать работу базовой версии продукта Старт. Про оптимизацию по 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.1.3, модуля Управления структурой и Информационных блоков.
В это обновление вошли изменения интерфейса указанные в предыдущем моем посте (пока не вошло управление компонентами).
В главном модуле и модуле информационных блоков был проведен полный анализ кода и все «узкие» места были переписаны и оптимизированы, в результате чего скорость исполнения PHP кода была увеличена примерно на 20% (тест для главной страницы редакции «Старт» прекомпилированной версии).
Вот полный список изменений:
Главный модуль:
- Новая административная панель. Позволяет работать с сайтом в трех специализированных режимах: Публичный раздел, Панель управления и Режим редактирования сайта. - Оптимизирован код модуля. Увеличена производительность критических и часто используемых функций. - Исправлена ошибка экспорта шаблонов с папки, содержащей в пути пробелы. - Исправлена ошибка обработки папок с именем "0" ("ноль"). - Незначительные изменения
Управление структурой:
- Добавлена возможность переименования файлов и каталогов, а также управления доступом посредством контекстного меню на странице "Файлы и папки" - Исправлена ошибка некорректной обработки имен каталогов с символом "+" - Исправлена ошибка неправильного определения сайта при работе с несколькими сайтами Изменения в визуальном HTML редакторе: - Добавлена функция перехвата вставки текста из MS Word с возможностью его предварительной очистки. - Изменен диалог "Вставить из Word". Добавлена возможность установить уровень очистки от различных тегов. - Увеличено быстродействие, скорость реакции на различные события. - Вставка тега параграфа ("p") при нажатии кнопки Enter в Internet Explorer заменена на вставку тега переноса строки ("br"). - Исправлена ошибка сохранения данных при наличии на странице более двух визуальных редакторов - Исправлена ошибка, связанная с перекрытием одного редактора другим(некорректная установка Z-Index) в Mozilla Firefox при работе с двумя редакторами на странице - Исправлена ошибка сохранения аттрибута src у тегов "IMG" при его изменении через диалоговое окно вставки рисунка.
Информационные блоки: - Исправлена ошибка изменения элемента информационного блока при увеличении счетчика показов. - Исправлен формат представления значений числовых не множественных свойств в Инфоблоках+. - Улучшение производительности.
Этим сообщением мне бы хотелось начать серию публикаций посвященных вопросам оптимизации продукта. Возможно, что ряд следующих публикаций будет подготовлен моими коллегами, так как потребуется давать более дельные советы и рекомендации разработчикам.
Без сомнения, в жизни любого продукта есть этапы развития. Сначала мы максимум внимания уделяли функциональности. Следующим шагом была безопасность. Потом интерфейсы и юзабилити. Не значит, что эти этапы пройдены и работы в этих направлениях не будут вестись. Скорее наоборот, работы ведутся еще активнее. Просто в каждом из этих направлений достигнуты заметные результаты.
Как вы видите, мы закрывали наиболее значимые проблемы для наших клиентов.
На сегодняшний момент мы считаем, что наиболее актуальная для наших клиентов проблемы - это производительность продукта. И именно этому вопросу будут посвящены значительные усилия в развитии ближайшего времени.
Производительность - это очень многогранная проблема. В производительности участвует парсинг кода 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 определить следующие константы:
Такой вариант работы теоретически может пригодиться для крупных проектов на выделенных машинах.
Как я уже сказал, очистка и обновление КЭШа будет происходит автоматически при изменении данных. Естественно, что изменение будет выполняться только в случае, когда такое изменение происходит с использованием 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
Дальше на очереди, инфоблоки+ (выпуск уже скоро), реклама, статистика, поиск и другие модули...