Ускоряем 1С: модули с повторным использованием возвращаемых значений

Программирование - Практика программирования

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

В чем проблема

Часто нам приходится по ходу исполнения программы получать значения, которые хранятся в базе данных и не меняются годами. Яркий пример - значения констант. Отчасти, можно причислить сюда же поиск элемента справочника или узла плана обмена по коду, получение значений реквизитов объектов по ссылке.

Не думая, "на лету" такие задачи решаются конструкциями вида:

Если ДатаДокумента > Константы.ДатаНачалаПримененияПостановления1137.Получить() Тогда

В результате, каждый раз когда выполняется этот код - происходит "дерганье" базы данных.

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

  1. Цикл выполнения кода может быть неявным (например, групповое перепроведение документов)
  2. Получить строгий набор данных (не больше и не меньше), которые потребуются позже, иногда затруднительно или вовсе невозможно.
  3. Кэшированные значения требуется использовать в разных вызовах/формах

Модуль с повторным использованием возвращаемых значений

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

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

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

Узел1 = НашМодуль.ПолучитьУзелОбменаСБухгалтерией("0001");
Узел2 = НашМодуль.ПолучитьУзелОбменаСБухгалтерией("0002");

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

Значения кэшируются отдельно для каждого сеанса на клиенте или сервере (в зависимости от того клиентский или серверный модуль). Т.е. если есть особенности настройки прав доступа или другой зависимости полученного значения от текущего пользователя - все отработает корректно.

Чего делать нельзя

Есть одно ограничение. В качестве параметров функций можно указывать только простые типы. Неопределено, Null, Булево, Дата, Строка, Число, Ссылка. Никаких структур, таблиц значений, объектов и т.п. Если вы попытаетесь передать в качестве параметра, например, структуру - все отработает, но о повторном использовании полученного значения можете забыть.

Возвращаемое значение при этом может быть любого типа.

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

Баг или фича от 1С

Интересное свойство есть у повторно используемых значений. Баг это или фича непонятно, но знать о нем не помешет. Если выполнить код следующего характера:

ЗначениеСтруктура1 = НашМодуль.ПолучитьСтруктуруЗначенийРеквизитов(СсылкаНаОбъект);

ЗначениеСтруктура1.Наименование = "Новое наименование";

ЗначениеСтруктура2 = НашМодуль.ПолучитьСтруктуруЗначенийРеквизитов(СсылкаНаОбъект);

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

Что делать при изменении закэшированных данных

Есть всего лишь один "легитимный" метод обработать ситуацию с изменением закэшированного значения в базе данных. Это метод ОбновитьПовторноИспользуемыеЗначения(). Будут сброшены значения всех функций по всем параметрам всех модулей. Обновить по конкретным значениям параметров / функциям / модулям нельзя.

Соответственно, из-за такого волюнтаристского подхода, пользоваться этой функцией необходимо крайне осмотрительно: вся система после его использования какое-то время будет работать существенно медленнее.

Посягаем на святое: пишем запрос в цикле

Кроме очевидных вариантов использования функций с повторным использованием возвращаемых значений, есть немало интересных, универсальных, нестандартных подходов, среди которых:

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

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

  1. Количество различных значений входящих параметров, которые встретятся внутри цикла небольшое и подавляющее большинство сочетаний с высокой долей вероятности было получено ранее в этом сеансе.
  2. Заранее получить строгий набор сочетаний значений входящих параметров, которые встретятся в цикле затруднительно, а получение значений для всех возможных сочетаний значений входящих параметров приведет к считыванию большого объема данных из БД

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

См. также

Комментарии
1. в п (panvartan) 04.09.17 17:26 Сейчас в теме
Используем утечки памяти по назначению
2. kolya_tlt kolya_tlt (kolya_tlt) 11 04.09.17 17:55 Сейчас в теме
Имеет смысл кэшировать данные, полученные из базы данных, внешних источников данных или путем сложных (ресурсоемких) вычислений. Причем в ряде случаев, даже значения, полученные из базы данных, не стоит кэшировать, если выгода от их кэширования – неочевидна.

https://its.1c.ru/db/v8std#content:-2145782923:hdoc
3. Арман Бегов (Dream_kz) 04.09.17 18:41 Сейчас в теме
Баг это или фича непонятно, но знать о нем не помешет


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

Статья хорошая, но не раскрыты собственно сами модули, отличия при хранении на время вызова и на время сеанса, время хранения значений на сервере на время сеанса (около 6 минут), а так же то, что это не панацея, и допустим от получения булевых констант таким образом, выигрыша будет мало.
mytg; Yashazz; vovan_victory; JohnyDeath; Sergant666; DimaP; ivant; alexch8; +8 Ответить
5. Анатолий Бритько (headMade) 134 04.09.17 20:39 Сейчас в теме
(3)в чем будет принципиальное отличие при чтении и кешировании значений булевых констант?
6. nicolas eliseev (nicxxx) 167 04.09.17 21:26 Сейчас в теме
(5)Очевидно же, что чтение будет обращаться к таблице констант в базе, а использование кэша заменяет обращение к базе обращением к памяти, что несколько быстрее, раз в 100 примерно.
9. Александр (chea06) 130 05.09.17 09:56 Сейчас в теме
(6)не факт
"Причем в ряде случаев, даже значения, полученные из базы данных, не стоит кэшировать, если выгода от их кэширования – неочевидна. Например, не стоит кэшировать константы (объект метаданных) примитивных типов, поскольку часто они привносят лишь незначительную долю от общего времени выполнения ресурсоемкой операции" ©
10. Арман Бегов (Dream_kz) 05.09.17 10:49 Сейчас в теме
(5) Принципиальных отличий не будет, но как сказал я ранее, и дали ссылку в (9) эффекта будет мало.
4. Александр Анисков (vandalsvq) 790 04.09.17 18:57 Сейчас в теме
Это не баг, скорее все таки фича. На прошлой партнерке 1С рассказывали, объекты возвращаются по ссылке, т.е. не копия структуры, массива и т.д., а ссылка на область памяти по сути (косвенно можно сделать такие выводы также из статьи про системы диагностики из "зазеркалья" тынц).

Так что, не рекомендуют так обновлять - что ж поделать, не будем. Ну если только совсем чуть-чуть, ну самую капелюшечку )))))
7. Игорь Дайнеко (Dnki) 05.09.17 07:49 Сейчас в теме
Про механизм знаю, но пользуюсь.
* Первая причина: неудобно 1С сделала признак - на весть модуль. Нужно было бы сделать директиву к функции, аналогично "export". По-моему, сам бог велел ввести такое свойство, явно написанное программистом, а не легко устанавливаемая/ снимаемая птичка. Я поясню: написал я модуль "РаботаСЧемТО". В нем собраны ф-ии по одной теме. Из них только одна нужна с кэшированием. Ясно дело, можно разбить, но краше от этого программа не будет.

* Механизм очень уж неявный. Я не знаю, когда сбросится кэш. Самому дать команду сброса - сбрасывается все. Короче, все что не написано программистом, вызывает сомнение в работе, особенно в след. релизах. Когда мне понадобилось, я сам написал. Например, кэш курсов валют сбрасываю в начале формирования отчета. Некоторые данные, часто используемые, но практически не меняемые, читаются в глобальный объект только при запуске.

* В задаче повторных значений лучше бы 1С решило для меня такую задачу: по анлогии с "С" иметь параметр объявления переменных Static. Такие переменные, являясь переменными процедуры, сохраняются в памяти между вызовами процедуры.Вот это был бы классный кэш!
sergelemon; Yashazz; mixsture; shard; PowerBoy; mrDSide; +6 Ответить
20. Александр Соколов (mefalcon) 13 06.09.17 10:04 Сейчас в теме
(7)>>Я поясню: написал я модуль "РаботаСЧемТО". В нем собраны ф-ии по одной теме. Из них только одна нужна с кэшированием. Ясно дело, можно разбить, но краше от этого программа >>не будет.

Именно так 1С делает в типовых решениях, добавляя в конец имени модуля, отражающую предметную область использования, суффикс "ПовтИсп"
https://stimul.kiev.ua/materialy.htm?a=pravila_sozdaniya_obshchikh_moduley
21. Сан Саныч (herfis) 179 06.09.17 10:35 Сейчас в теме
(20) Более того - это зафиксировано в стайл-гайде 1С по именованию общих модулей.
В принципе - не такое это уж и неудобство. Ну, то что нужно отдельный модуль для этого. Даже в чем-то лучше, чем на уровне сигнатуры функции это указывать, как в (7) предлагали. Да, модуля плодятся, но в клиент-сервере их и так плодить приходится. А лучше тем, что прямо по вызову функции видно, что она кэшируемая. В клиент-сервере если боль-менее развесистую подсистему делаешь, то начинается
Клиент, КлиентСервер, Сервер, ВызовСервера, КлиентПовтИсп, СерверПовтИсп - шесть модулей как с куста.
А могут еще быть ПолныеПрава и Глобальный (но за глобальные надо расстреливать, я считаю).
8. Sergey Andreev (starik-2005) 1161 05.09.17 09:47 Сейчас в теме
"Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам" (с) Шекспир.

К чему это я? А к тому, что иногда (и даже часто) некоторые моменты при кешировании объектов таким способом могу привести к непредсказуемым последствиям. В частности, от длины "ключа" может зависеть жизнеспособность кешированного объекта при последующем его обновлении. Т.е. типа получаете объект тОбъект = ОбщМодПовтИсп.ПолучитьОбъект("ХХХУУУZZZ"), а он вам так раз....
11. Сан Саныч (herfis) 179 05.09.17 10:57 Сейчас в теме
Хоть и РТФМ, но плюсанул. Может, кому-то статья поможет начать использовать эту функциональность.
Сам использую достаточно широко - в ряде случаев помогает одновременно и упростить код и повысить его эффективность.
Единственный совет - хорошо подумайте, точно ли кэшируемая информация является условно-постоянной (является ли критичным доступ к обновленным в течение сеанса данным).
12. Антон Локтионов (Anton64) 144 05.09.17 13:18 Сейчас в теме
Ссылку нельзя передавать параметром?
13. Сан Саныч (herfis) 179 05.09.17 13:29 Сейчас в теме
14. Сергей Старых (tormozit) 4488 05.09.17 13:32 Сейчас в теме
Неплохо бы еще не только про "на время сеанса" но и про 20 минутное время жизни значений в кэше упомянуть. Эта особенность на некоторые способы использования влияет сильно.
16. Сан Саныч (herfis) 179 05.09.17 14:07 Сейчас в теме
(14) Кэш, как и обещано, живет до конца сеанса. Через 20 минут без использования он просто на диск откочует. И "неожиданности" тут возникнут только с мутабельными значениями, которые невозможно корректно сериализовать. То есть проблемы возникнут, если пытаться использовать кэш как хранилище глобальных серверных переменных произвольного типа. Но да - эту особенность упомянуть стоит однозначно.
Можно, например, инициализированный COM-объект так держать в памяти сервера. В большинстве случаев ничего страшного, если он пересоздастся после долгого неиспользования. Я по-дефолту так с сервера всякие сторонние соединения поднимаю. Если же пытаться так хранить мутабельные промежуточные результаты, которые терять нельзя, то придется обеспечить их "дергание", чтобы они не потерялись при попытке сериализации. Но это уже совсем изощренные костыли, которых стоит избегать. Лучше оставаться в рамках stateless-модели сервера, пусть и с некоторой потерей эффективности.
17. Сергей Старых (tormozit) 4488 05.09.17 15:11 Сейчас в теме
(16)
Кэш, как и обещано, живет до конца сеанса.

Ошибаешься. Тут уже привели ссылку на ИТС. Почитай https://its.1c.ru/db/v8std#content:-2145782923:hdoc
18. Сан Саныч (herfis) 179 05.09.17 15:27 Сейчас в теме
(17) Смущает примечание "раздел обновлен". Сдается мне, ранее на ИТС я читал совсем другое.
19. Сан Саныч (herfis) 179 05.09.17 15:35 Сейчас в теме
(17) Хотя и в руководстве разработчика на ИТС тоже самое написано...
Не хотелось бы принимать во внимание свой маразм, но видимо придется :)
35. Uladzimir - (nvv1970) 07.09.17 22:02 Сейчас в теме
(17) Перечитал это еще раз (процитирую)
Закэшированное значение будет удалено из кэша через 20 минут после вычисления или через 6 минут после последнего использования (в зависимости от того, что наступит раньше*). Кроме этого значение будет удалено при нехватке оперативной памяти в рабочем процессе сервера, при перезапуске рабочего процесса и при переключении клиента на другой рабочий процесс. Поэтому если никто "не успел" воспользоваться данными из кэша, то этот ресурс был потрачен зря.
* Примечание: конкретные цифры могут варьироваться в зависимости от используемой версии платформы 1С:Предприятие.

На какой-то из недавних версий платформы пытался это поведение протестировать. Ставишь точку в повторяемом модуле. Провалился в модуль - кэш очистился, нет - еще жив.
Любопытно, что четких временных границ для "последнего использования" не оказалось. Как-то хаотично очистка кэша срабатывала: могло и по 10, и по 20 минут не очищаться при полном бездействии. Но то что очистка происходит - это факт. И это прекрасно )) С содроганием вспоминаю кэш в глобальной переменной.

ПС: еще не раскрыта тема и приведены примеры "кэша на вызов". Такой вид почти не используется. А между тем тоже стоит о нем помнить. Хватает специфических сложных алгоритмов, когда такой кэш незаменим.
15. xReason (xReason) 05.09.17 13:39 Сейчас в теме
Можно возвращать данные с типом ФиксированнаяСтруктура, ФиксированныйМассив и т.д.
Тогда фича от 1С в виде изменяемого значения не будет работать
32. Павел Одинцов (Darklight) 07.09.17 09:23 Сейчас в теме
(15)Возвращать-то можно любое значение. Но, принимать как параметр.... в повторно используемую функцию можно значение типа "Структура". Но НЕЛЬЗЯ типа "ФиксированнаяСтруктура" - вот такой идиотизм. Конечно преобразования "Структура" <-> "ФиксированнаяСтруктура" делается легко - но для повторного использования важна идентичность входных параметров - а тут она теряется!
Поэтому, лично я предпочитаю вот так (привожу в упрощённом виде) создавать структуры - когда нужна их идентичность (ну и не изменять их потом):

//Размещено в модуле повторного использования
функция Структура(ПараметрыСтр, п1=null,п2=null,...здесь ещё 96 таких параметра...,п99=null,п100=null)
    возврат Новый Структура( ПараметрыСтр, п1,п2,...здесь ещё 96 таких параметра...,п99,п100);
КонецФункции


Такой подход "гарантирует", что где-то 20 минут структура будет идентична, и её "без опаски" можно дальше передавать как входной параметры в другие повторно используемые функции.
Конечно, есть и другие варианты достичь идентичности.
22. Николай Нагачевский (bruho) 06.09.17 15:02 Сейчас в теме
Для того, чтоб "сбросить" значения в методе с повторным использованием использую необязательный параметр, в который передаю УИ. Но подходит только для тех случаев, когда явно указываешь вызов с заполненным необязательным параметром.

Функция МетодСПовторнымИспользованием(ОбновитьЗначение = Неопределено) Экспорт 
	
	Время = ТекущаяДата();
	
	Возврат Время;
КонецФункции

//Время вернет из первого обращения к методу
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = Строка(МетодСПовторнымИспользованием());
Сообщение.Сообщить();


//Время вернет текущее
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = Строка(МетодСПовторнымИспользованием(Строка(новый УникальныйИдентификатор)));
Сообщение.Сообщить();



Показать
23. г. Казань Рустем Гумеров (Rustig) 830 06.09.17 15:11 Сейчас в теме
(0) я суть статьи не понял. рабочие примеры есть для понимания?

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

Столкнулся в УТ 10.3 с такой проблемой - в УТ 10.3 появился механизм ПравилаВыборочнойРегистрацииОбъектов (константа),

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

Я переименовал в документе ПКО реквизит Основание (Тип Строка), потому что он некорректно заполняется при заполнении на основании другого документа (стандартный параметр Основание процедуры ОбработкаЗаполнения()).

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

Я переименовал этот реквизит в ОснованиеСтрока - теперь у меня элементарно не проводится документ, выходит ошибка здесь:

Функция ПолучитьТаблицуРеквизитовРегистрацииШапкиДоИзменения(Объект, СтрокаТаблицыРеквизитовРегистрации)

ТекстЗапроса = "
|ВЫБРАТЬ " + СтрокаТаблицыРеквизитовРегистрации.РеквизитыРегистрации
+ " ИЗ " + СтрокаТаблицыРеквизитовРегистрации.ИмяОбъекта + " КАК ТекущийОбъект
|ГДЕ
| ТекущийОбъект.Ссылка = &Ссылка
|";

Запрос = Новый Запрос;
Запрос.Текст = ТекстЗапроса;
Запрос.УстановитьПараметр("Ссылка", Объект.Ссылка);

Возврат Запрос.Выполнить().Выгрузить();

КонецФункции

, в запрос тащится СтрокаТаблицыРеквизитовРегистрации.РеквизитыРегистрации, который содержит следующие поля:

Организация, ВидОперации, Контрагент, ДоговорКонтрагента, ВалютаДокумента, СуммаДокумента, ПринятоОт, Основание, Приложение, Комментарий, ДокументОснование, СтатьяДвиженияДенежныхСредств, СтавкаНДС, НомерЧекаККМ, ПометкаУдаления, Проведен, Номер, Дата, Ответственный, ОтражатьВБухгалтерскомУчете

То есть таким механизмом разработчики ут 10.3 не позволяют переименовывать типовые реквизиты. Хм, думаю это неправильно.

может я не туда пишу - поправьте - но это своего рода кэширование - хранение информации о жесткой структуре метаданных конфигурации которую как будто теперь нельзя изменять - валятся родные механизмы
24. Гази Кушкунов (gmkushkunov) 06.09.17 15:42 Сейчас в теме
(23) Здравствуйте.

По поводу жесткой структуры не совсем понятно, раз вы переименовали стандартный реквизит значит структура нежесткая, просто надо переписать код где идет обращение к этому реквизиту. Мне кажется Вы сами никогда не программировали в связке СУБД. Если Вы создали в СУБД таблицу а в ней поля, назвали их как то и написали программу, в которой идет обращение к этой таблице и ее полям (т.е. к их именам), протестировали и дали заказчику полностью рабочую программу, а заказчик в свою очередь переименовал стандартные поля в Вашей таблице не исправляя кода программы, где идет обращение к переименованным полям и обнаруживает, что программа перестала работать (выдает ошибки и т.д.) и начинает Вам жаловаться, что Вы не правильно составили программу, как Вы на это посмотрите?

P.S. на самом деле Вы не в ту тему пишите.
sergelemon; Rustig; +2 Ответить
25. г. Казань Рустем Гумеров (Rustig) 830 06.09.17 16:40 Сейчас в теме
(24) я понял вас: пугает что этот список реквизитов засунули в константу с типом Хранилище.

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

в нашем случае Глобальный Поиск не нашел Константу в которой спрятан список реквизитов - по сути строка спрятана, саму константу в пользовательском режиме вы тоже не откроете и не увидите - потому тип объекта Хранилище.

ну и кто так кодит?

вердикт - что-то намудрили в УТ с механизмами версий, оттуда проблемы происходят
26. г. Казань Рустем Гумеров (Rustig) 830 06.09.17 16:47 Сейчас в теме
(24) я вот не пойму обсуждаемую здесь тему с кэшированием без примеров - какую конкретную задачу пытается решить автор?
27. Сан Саныч (herfis) 179 06.09.17 17:09 Сейчас в теме
(26) Автор не про конкретную задачу, а про инструмент.
Если хочется живых примеров - откройте список общих модулей любой современной типовой и глядите в модуля, где в конце "ПовтИсп" в названии.
sergelemon; Rustig; +2 Ответить
28. г. Казань Рустем Гумеров (Rustig) 830 06.09.17 17:29 Сейчас в теме
(27) ок, понятно
а зачем так сложно придумали?
столько модулей развели - в чем суть?
29. Сан Саныч (herfis) 179 07.09.17 07:03 Сейчас в теме
(28) Жертвы на алтарь возможности работать через браузер.
30. г. Казань Рустем Гумеров (Rustig) 830 07.09.17 08:07 Сейчас в теме
(29) где-нибудь можно об этом прочитать подробнее?
31. Сан Саныч (herfis) 179 07.09.17 09:05 Сейчас в теме
33. Дмитрий Д (profiprog1c) 151 07.09.17 12:49 Сейчас в теме
Статья полнейшая глупость. Если бы автор реально занимался замерами работы производительности, то он бы знал, что получение константы методом:
Константы.ЛюбаяКонстанта.Получить()
занимает тысячные доли процента, от времени выполнения реального кода.
А уж если и нужно в коде часто использовать данные этой константы, то пишем:
НашаПеременная = Константы.ЛюбаяКонстанта.Получить()
и дальше использ-уем НашаПеременная
Самые затраты операции при работе кода - это запросы и вот там нужно оптимизировать.
34. Uladzimir - (nvv1970) 07.09.17 21:44 Сейчас в теме
(33) Это так, экономия на спичках, непонимание которой, умноженное на тысячи, сотни тысяч обращений к СУБД в сотнях или тысячах сеансов сделают свое черное дело. Конечно СУБД тоже не дура - сама что-то закэширует. Но, гуру подскажут точно, наверняка это генерирует лишние соединения к СУБД, количество которых в какой-то момент тоже может быть критичным.
Мораль такова: если нужно переходить дорогу на зеленый свет - давайте это делать всегда, даже если дорога пустая, а не только когда это кому-то нужно. Если есть инструмент, то, как минимум, им нужно хотя бы уметь пользоваться. А лучше пользоваться всегда и по назначению.
36. Яков Коган (Yashazz) 2127 08.09.17 12:30 Сейчас в теме
Да тема вообще практически не раскрыта. Ни срок жизни этого кэша, ни где он лежит (в сеансовых данных аль ишшо где), ни различия тонкого и толстого, ни различия повт.исп. на сервере и на клиенте... Можно было определить границу эффективности, за которой такое кэширование становится вредным и тормозным; можно было сравнить с параметром сеанса и его поведением; с поведением глобальных переменных модуля приложения, итд... Я уж не говорю о специфических вещах, как-то кэширование значения типа веб-прокси или ком-объект))

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