+7 495 008 8452 пн.-пт. 10:00 – 17:00
Если у вас возникли какие либо вопросы которые вы не смогли решить по нашим публикациям самостоятельно,
то ждем ваше обращение в нашей службе тех поддержки.


Выборка и хранение в кеше только нужных данных

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

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


Важные примеры повышения производительности

  1. Часть АПИ-методов может генерировать излишнюю информацию. Лучше сразу ограничить запросы только нужными данными.

    Примеры:

    $rs = CIBlockResult::GetNext(true, false);
    // установка параметра false позволяет ограничить выборку только преобразованными значениями полей.
    $res = CIBlock::GetList(array(), array('TYPE'=>'catalog', 'SITE_ID'=>SITE_ID, 'ACTIVE'=>'Y'), false);
  2. В некоторых случаях метод Fetch работает быстрее, чем GetNext, но он не делает данные безопасными.
  3. Кеширование только нужных данных.

    В самом компоненте нужно ограничить результат работы компонента $arResult только нужными данными.

    Например, компонент должен выводить всего идентификатор элемента и его название, тогда только их и нужно занести в кеш:

    $this->SetResultCacheKeys(array("ID", "NAME"));

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

    foreach ($sAr as $key => $arElement)
    {
    $this->__component->arResult["IDS"][] = $arElement["ID"];
    }
    $this->SetResultCacheKeys(array("IDS"))

    Примечание: Если в SetResultCacheKeys не установлены ключи, то тогда, по умолчанию, будет производиться кеширование всех результатов $arResult.

    Ссылки по теме:


  4. Оптимизация размера кеша.

    Если, например, размер файла кеша превышает 1МБ, то возможно происходит избыточное кеширование, что не есть хорошо. В этом случае следует произвести анализ кешируемых данных. Чем больше размер файла кеша, тем меньше его эффективность.

  5. Ограничение объема запрашиваемой информации.

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

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

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

    Пример:

    Параметр nPageSize=20 массива arNavStartParams позволяет отобразить 20 элементов, но он делает 2 запроса к базе:

    1. "COUNT" - получение кол-ва элементов
    2. "SELECT" - непосредственно выборка данных
    

    в то время как параметр nTopCount=4 того же массива создает сразу 1-н запрос вида:

    SELECT * FROM tbl LIMIT 4;  
    

    Использование nTopCount гораздо эффективнее т.к. он не делает дополнительный запрос на получение записей выборки.

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



Назад в раздел

Подписаться на новые материалы раздела:














CAPTCHA