Опять Кэш

[glibs]

Цитата:

Сообщение от Владимир Максимов

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

Вы заблуждаетесь. Для "Found" кешировнаие будет работать всякий раз, когда в коде вызывается

InventTable::find(...)

А точнее, когда запись выбирается по первичному ключу.

Если код работает на сервере приложений, то в таком случае будет лишнее обращение на сервер БД. Номенклатура там скорее всего будет тоже в кеше, поэтому потери производительности вы можете не ощутить визуально. Впрочем, если запускается долгоиграющая периодическая процедура (типа закрытия склада), в которой может очень-очень много раз вызываться InventTable::find(...) подразумевая, что кеширование включено, производительность может просесть заметно. Не говоря уже о лишнем трафике (Аксапта имеет привычку выбирать все поля в записи).

Если же код будет выполняться на клиенте (display методы, если по-хорошему), то потеря производительности при отключении кеширования будет заметна даже невооруженным глазом.

Когда я был помоложе, то тоже увлекался отключением кеширования. Но все-таки пришел к тому, что не стоит.

Вот вам джоб.

static void glibs(Args _args)
{
    InventTable             inventTable;
    Counter                 i;
    TimeOfDay               startTime,
                            endTime;
    ;

    startTime = timenow();
    for (i = 1; i <= 10000; i++)
    {
        inventTable = InventTable::find("Test");
    }
    endTime = timenow();

    info (strfmt("%1", endTime - startTime));

}

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

У меня разница приблизительно на порядок получилась.

[Владимир Максимов]

glibs

Я же говорю, нет однозначного ответа. Зависит от конкретной ситуации и надо смотреть "по месту" что выгоднее: возможная потеря производительности или актуальность данных.

Для нас критичным оказалась именно актуальность данных. Почему? Это уже отдельный вопрос.

По сути, единственное место, где реально ощутима потеря производительности - это display-методы.

Коды циклических процедур все-таки не настолько "тупые", чтобы многократно делать поиск внутри цикла. А если настолько, то на этот случай и нужны программисты, чтобы это исправить

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

Насчет закрытия склада - не понял. Где там многократное обращение к одной и той же записи InventTable? Там же единственный цикл именно по InventTable, а потом выбранная запись передается как параметр. Нет повторного InventTable::find()