Я выполнил обновление Sitecore с 8.1 до 9.0 Update 2. Я вижу, что есть проблема с кешем предварительной выборки.
В старой версии кеш предварительной выборки webdb будет достигать 6 ГБ, но в обновленной версии он не превышает 1,5 ГБ.
Экземпляр Sitecore 8.1
Обновленный экземпляр Sitecore 9.0
Были вложены огромные средства в перепроектирование архитектуры кэширования, я расскажу о нескольких вещах, которые были изменены:
1) Изменение правил игры — Sitecore.Interning.config, позволяющее повторно использовать повторяющиеся неизменяемые объекты (такие как строки, идентификаторы) — мы храним гораздо меньше дублирующихся объектов в памяти прямо из коробки. Вы можете увидеть разницу, отключив интернирование в вышеупомянутой конфигурации.
2) Внедрить интерфейс Sitecore.Caching.Interfaces.ISizeTrackable, который должен помочь сущностям лучше узнать свой размер - это очень верно для PreferechData; он даже даст вам разные размеры для настройки 32/64-битного пула приложений (поскольку размер указателя отличается).
3) Внедрить интерфейс Sitecore.Common.ITrimExcess, который позволяет сжимать коллекцию при добавлении большей части данных (внутренне опирается на TrimExcess() API для List или HashList).
Подводя итог, можно сказать, что для основных частей платформы ожидаются гораздо меньшие цифры, поскольку они были тщательно обработаны :)
Вы сравнивали, сколько памяти на самом деле потребляет процесс w3wp? Похоже, у вас одинаковое количество элементов в кеше. Из того, что я вижу на ваших снимках экрана, кеш работает, как и ожидалось, в обоих сценариях.
Размер кэша каждого объекта оценивается посредством ICacheable.GetDataLength() реализации каждого кэшируемого объекта. Это значение не всегда точное, а иногда и довольно далекое. По крайней мере, в предыдущих версиях Sitecore вы могли подсчитать сумму всего столбца размера кэша и получить общую сумму, которая намного превышает размер вашего w3wp процесса.
Если я правильно помню, Sitecore изменил способ оценки размеров объектов по умолчанию. Вы, вероятно, видите эффект этого.
