'504 - Тайм-аут шлюза' при индексировании элементов в поиске Episerver

При индексировании элементов иногда происходит сбой, и он дает

The remote server returned an error: (504) Gateway Timeout. [The remote server returned an error: (504) Gateway Timeout.]

Логика индексирования здесь, как показано ниже,

var client = EPiServer.Find.Framework.SearchClient.Instance;
List<ItemModel> items = getItems(); // Get more than 1000 items
List<ItemModel> tempItems = new List<ItemModel>();

//Index 50 items at a time
foreach(var item in items)
{
    tempItems.Add(item);
    if (tempItems.Count == 50)
    {
        client.Index(tempItems);
        tempItems.Clear();
    }
}

Что заставляет это происходить?

Примечание. Вышеупомянутая ItemModel - это настраиваемая модель, в которой не реализованы интерфейсы (например, IContent ). И items - это список ItemModel объектов.

Дополнительная информация:
EPiServer.Find.Framework версии 13.0.1
EPiServer.CMS.Core версии 11.9.2


person Senura Dissanayake    schedule 29.11.2018    source источник
comment
Мы тоже это испытали. Это происходит с индексами разработки или производства? В любом случае, в некоторых случаях нам приходилось переключаться на индексы в другом кластере.   -  person Ted Nyberg    schedule 29.11.2018
comment
Это происходит в производственных индексах. И это может произойти и в индексе развития.   -  person Senura Dissanayake    schedule 29.11.2018
comment
Вам, вероятно, лучше отправить запрос в службу поддержки Episerver по этому поводу.   -  person Ted Nyberg    schedule 30.11.2018
comment
Производительность Episerver Find оставляет желать лучшего (у нашей компании есть несколько проектов, связанных с Find). Случайные тайм-ауты для него вполне нормальны. Если они вызывают у вас проблемы, я обращаюсь в службу поддержки Episerver, как советовал Тед.   -  person bursson    schedule 13.12.2018


Ответы (1)


Я всегда считал SearchClient немного схематичным при манипулировании данными в Find, насколько я понял (но я должен это проверить) SearchClient подчиняется ограничению запросов Episerver Find и при увеличении операции в циклах, как правило, время ожидания истекает.

Вместо этого используйте ContentIndexer, т.е.

// Use this or injected parameter
var loader = ServiceLocator.Current.GetInstance<IContentLoader>();

// Remove all children or not
var cascade = true;

ContentReference entryPoint = ...where you want to start

// Get all indexable languages from Find
Languages languages = SearchClient.Instance.Settings.Languages;

// Remove all current instances of all languages below the selected content node
//languages.ForEach(x => ContentIndexer.Instance.RemoveFromIndex(entryPoint, cascade.Checked, x.FieldSuffix));

foreach (var lang in languages)
{
    if (cascade)
    {
        var descendents = loader.GetDescendents(entryPoint);

        foreach (ContentReference descendent in descendents)
        {
            ContentIndexer.Instance.RemoveFromIndex(descendent, false, lang.FieldSuffix);
        }
    }

    // Try delete the entrypoint
    var entryTest = loader.Get<IContent>(entryPoint, new CultureInfo(lang.FieldSuffix));
    if (entryTest != null)
    {
        var delRes = ContentIndexer.Instance.Delete(entryTest);
    }
}

Насколько я понял, это самый надежный способ удалить что-то из индекса.

person Eric Herlitz    schedule 30.11.2018
comment
@Erik, Мы используем кастомную модель (в данном случае ItemModel) для объекта индексации. который не реализуется IContent. В таком случае это ContentIndexer полезно? - person Senura Dissanayake; 30.11.2018
comment
Я предполагаю, что ItemModel - это настраиваемый объект? - person Eric Herlitz; 30.11.2018
comment
да. И items имеет Список ItemModel объектов. - person Senura Dissanayake; 30.11.2018
comment
Обновите свой вопрос, поскольку это касается настраиваемых объектов, не наследуемых от IContent. В любом случае, в этом случае вам необходимо ограничить количество запросов в соответствии с объемом лицензии на поиск, чтобы не перегружать SearchClient. - person Eric Herlitz; 30.11.2018
comment
Я обновил (добавил информацию в виде примечания). И спасибо за ваше мнение по этому поводу :) - person Senura Dissanayake; 30.11.2018