К контенту

Djapian: версия 2.2.1 - хотфиксы

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

Для проверки я решил найти или на худой конец намайнить какой-то большой массив данных и его проиндексировать. Подумав, решил что что-то типа википедии будет в самый раз. Быстро нашел xml дамп русской википедии и попробовал его залить в базу, а потом проиндекcировать. Для оперативности ограничился числом в 150К статей.

При тестировании действительно выяснилось, что с включенными транзакциями индекс обновляется очень медленно - примерно 0.5 док/сек. Причем виноваты не сами транзакции, а то что при каждом комите происходил flush базы. Отключив flush, производительность индексирования выросла в разы - до 15-20 док/сек, что уже очень не плохой показатель.

В итоге в хотфикс релизе я добавил возможность управлять транзакциями (по умолчанию они выключены) и сбросом кеша в базу через опции команды index - --transaction и --flush:

  • --transaction - включает использование транзакций
  • --flush - включает сброс файлового кеша при обновлении каждого документа

Ещё изменил политику работы с большим числом объектов в очереди индексирования. Теперь они обрабатываются постранично и не сжирают кучу виртуальной памяти из-за нерадивых client-side курсоров БД. Это тоже могло приводить к активному свопингу и ухудшению производительности.

Djapian стал ещё производительнее и лучше:-)

Комментарии 6

  1. bw написал:

    Можешь объяснить что дают и когда использовать --transaction и --flush?

    ..bw

    Оставлен 06 Май 2009 в 02:27
  2. Александр Кошелев написал:

    --transaction - включает использование транзакций

    --flush - включает сброс файлового кеша при обновлении каждого документа

    Пост тоже обновил.

    Оставлен 06 Май 2009 в 18:48
  3. scey написал:

    Вопрос не совсем в тему поста. Djapian отрабатывает связи "много-ко-многим"? Пробую привязать таблицу, ошибок при индексации нет, но ничего не находится. Таблицы связаны через промежуточную, в модели прописано <имя> = ManyToManyField(<модель>, through=<промежуточная таблица>), в полях класса индексации стоит <имя>.name Заранее спасибо.

    Оставлен 12 Май 2009 в 14:19
  4. Александр Кошелев написал:

    На данный момент M2M обрабатывается просто - объекты сериализуются в строку и сохраняются. Обработки полей зависимых моделей нет. Поэтому в вашем случае в индекс ничего не попадает.

    Я завел тикет на этот use-case. Подпишитесь на него, я думаю в ближайшем времени реализую.

    Оставлен 12 Май 2009 в 20:53
  5. Данила написал:

    Александр, а я правильно понимаю, что manage.py index запускает индексацию всех моделей?

    А нельзя ли как-то по одиночке их запускать?

    Бывают контент, который нужно индексировать часто, а бывает - который не нужно.

    Было бы здорово разделять.

    PS. openid на яндекс у меня не сработал :(

    Оставлен 25 Май 2009 в 18:03
  6. Александр Кошелев написал:

    Александр, а я правильно понимаю, что manage.py index запускает индексацию всех моделей?

    Эта команда обновляет индекс - добавляя, изменяя или удаляя документы с момента последнего запуска. Djapian отслеживает изменения в нужных моделях сам и на основе этого принимает решение что делать. Индекс у Xapian'а инкрементальный поэтому это легко делать.

    А нельзя ли как-то по одиночке их запускать?

    Бывают контент, который нужно индексировать часто, а бывает - который не нужно.

    Было бы здорово разделять.

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

    PS. openid на яндекс у меня не сработал :(

    Изучу.

    Оставлен 25 Май 2009 в 18:17

Оставьте комментарий