Советы по оптимизации при переносе данных в Sitecore CMS

В настоящее время я столкнулся с задачей импорта около 200 тыс. элементов из пользовательской реализации CMS в Sitecore. Я создал простую страницу импорта, которая подключается к внешней базе данных SQL с помощью Entity Framework, и создал все необходимые шаблоны данных.

Во время тестового импорта около 5 тыс. элементов я понял, что мне нужно найти способ сделать импорт намного быстрее, поэтому я решил найти некоторую информацию об оптимизации Sitecore для этой цели. Я пришел к выводу, что конкретной информации не так много, поэтому я хотел бы поделиться тем, что нашел, и дать возможность другим внести свой вклад в дальнейшую оптимизацию. Моя цель — создать некий режим обслуживания для Sitecore, который можно было бы использовать при импорте больших объемов данных.

Самая полезная информация, которую я нашел, была в блоге Марка Кэссиди http://intothecore.cassidy.dk/2009/04/migrating-data-into-sitecore.html. Внизу этого поста он дает несколько советов, когда вы запускаете импорт.

  • При переносе больших объемов данных попробуйте отключить как можно больше обработчиков событий Sitecore и всего, что вам сойдет с рук.
  • Используйте BulkUpdateContext()
  • Не забывайте свой целевой язык
  • Если можете, сделайте поля общими и неверсированными. Это должно помочь ускорить выполнение миграции.

Первое, что я заметил в этом списке, был класс BulkUpdateContext, поскольку я никогда о нем не слышал. Я быстро понял, почему поиск на форуме SND и в документации в формате PDF не дал результатов. Так что представьте мое удивление, когда я действительно протестировал его и обнаружил, что он улучшает создание/удаление элементов как минимум в десять раз!

Следующим, на что я обратил внимание, был первый пункт, где он в основном предлагает создать версию веб-конфигурации, в которой есть только самое необходимое для выполнения импорта. Пока что я удалил все события, связанные с созданием, сохранением и удалением элементов и версий. Я также удалил механизм истории и объявления системного индекса из элемента основной базы данных в веб-конфигурации, а также любые пользовательские события, расписания и конфигурации поиска. Я ожидаю, что есть много других вещей, которые я мог бы удалить/отключить, чтобы повысить производительность. Трубопроводы? Расписания?

Какие у вас есть советы по оптимизации?


sitecore sitecore6
person Christian Hagelid    schedule 22.03.2011    source источник

Ответы (2)


arrow_upward
16
arrow_downward

Между прочим, имя BulkUpdateContext() вводит в заблуждение, так как оно действительно повышает скорость создания элемента, а не скорость обновления элемента. Но, как вы также указываете, это значительно повышает скорость импорта :-)

С тех пор, как я написал этот пост, я добавил несколько новых вещей в свои обычные процедуры при выполнении импорта.

  • Регулярно сжимайте свои базы данных. Они имеют тенденцию расти большими и громоздкими. Сделать это; сначала перейдите в Панель управления Sitecore -> База данных и выберите «Очистить базу данных». После этого выполните обычную ShrinkDB на вашем SQL-сервере.
  • Отключите индексы, особенно при импорте в «основную» базу данных. Для справки см. http://intothecore.cassidy.dk/2010/09/disabling-lucene-indexes.html
  • Однако старайтесь не импортировать в «мастер». Обычно вы обнаружите, что импорт в «веб» происходит намного быстрее, в основном потому, что эта база данных (по умолчанию) не подключена к HistoryManager или другим гаджетам.

И если вы действительно любите приключения, есть вещь, которую вы могли бы могть попробовать, что я сам подумывал попробовать, но так и не дошел до этого. Они могут работать, но я не могу гарантировать, что они будут :-)

  • Попробуйте удалить все ваши типы полей из App_Config/FieldTypes.config. Теория здесь заключается в том, что это должно по существу отключить всю специальную обработку Sitecore содержимого этих полей (например, обновление базы данных ссылок и т. д.). Вам нужно будет вручную запустить перестроение базы данных LinkDatabase после завершения импорта, но это относительно небольшая цена.

Надеюсь, что это помогает немного :-)

person Mark Cassidy    schedule 22.03.2011
comment
Хороший вопрос, хороший ответ, очень полезная информация :). Спасибо! - person Younes; 22.03.2011
comment
Импортировать в сеть? тогда что произойдет в следующий раз, когда он нажмет кнопку "Опубликовать"...? - person Bryan; 24.03.2011
comment
@Bryan Я думаю, что он имеет в виду импорт в веб-базу данных при тестировании импорта, а затем запускает его на главной базе данных, когда он вас устраивает. - person Christian Hagelid; 25.03.2011
comment
Почему ShrinkDB? Если диск не является для вас проблемой, вы просто настраиваете себя на некоторые дорогостоящие операции по увеличению файлов. - person Samantha Branham; 09.04.2016

arrow_upward
1
arrow_downward

Я предполагаю, что вы уже столкнулись с этим, но размещение кода внутри блока SecurityDisabler() также может ускорить процесс.

Я бы гораздо больше беспокоился о том, как Sitecore работает с таким большим объемом данных ... если вы делаете импорт только один раз, кого волнует, сколько времени займет этот процесс. Это будет регулярным явлением?

person Bryan    schedule 24.03.2011
comment
Да, он уже запущен внутри блока SecurityDisabler. Производительность Sitecore определенно меня беспокоит, но очень раннее тестирование показывает, что она справится с этим. Импорт предназначен только для однократной миграции со старой CMS, но я буду запускать его несколько раз, когда буду настраивать шаблоны. - person Christian Hagelid; 25.03.2011
comment
200 000 элементов на самом деле не представляют проблемы для установки Sitecore, если соблюдаются основные правила. По возможности не более 100 листьев на ветке и так далее. Но даже так; если исходная CMS основана на чем-то, что затруднило бы глубокое ветвление, добавление индекса lucene поверх всего этого позволило бы Sitecore удобно перемещаться по структуре; просто избегайте глубоких выражений Sitecore Query для импортированного контента и старайтесь держаться подальше от XSLT - person Mark Cassidy; 25.03.2011