Мы использовали Drools как часть решения, чтобы действовать как своего рода фильтр в очень интенсивном приложении обработки, возможно, до 100 правил на 500 000 + рабочих объектов памяти. оказывается, что он очень медленный. у кого-нибудь еще есть опыт использования Drools в приложении обработки пакетного типа?
Я не работал с последней версией Drools (в прошлый раз, когда я использовал ее примерно год назад), но тогда наши тесты с высокой нагрузкой доказали, что она очень медленная. Огромное разочарование после того, как он основал большую часть нашей архитектуры.
По крайней мере, что-то хорошее, что я помню о слюнях, заключается в том, что их команда разработчиков была доступна в IRC и очень полезна, вы можете попробовать, они ведь эксперты: irc.codehaus.org #drools
Вид зависит от ваших правил. Объекты 500K разумны, учитывая достаточную память (он должен заполнять сеть RETE в памяти, поэтому использование памяти несколько из 500K объектов - т.е. пространство для объектов + пространство для структуры сети, индексы и т.д. ) - возможно, вы подкачки на диск, который будет очень медленным.
Конечно, если у вас есть правила, которые соответствуют комбинациям одного и того же типа, это может вызвать взрыв комбинаций, который, даже если у вас есть 1 правило, будет действительно очень медленным. Если бы у вас была больше информации о анализе, который вы делаете, это, вероятно, поможет с возможными решениями.
Я использовал Drools с работоспособной памятью, содержащей более 1 миллиона фактов. При некоторой настройке как ваших правил, так и базовой JVM производительность может быть неплохой после нескольких минут для первоначального запуска. Дайте мне знать, если вы хотите получить более подробную информацию.
Я просто изучаю слюни самостоятельно, так что, может быть, я чего-то не хватает, но почему вся партия из пятисот тысяч объектов добавлена в рабочую память сразу? Единственная причина, по которой я могу думать, это то, что есть правила, которые срабатывают только тогда, когда связаны два или более элемента в пакете.
Если это не так, то, возможно, вы могли бы использовать сеанс без состояния и одновременно утверждать один объект. Я предполагаю, что в этом случае правила будут работать в 500k раз быстрее.
Даже если это так, все ли ваши правила требуют доступа ко всем 500k-объектам? Не могли бы вы ускорить процесс, применяя правила по каждому пункту за раз, а затем на втором этапе обработки применяете правила уровня партии, используя другую базу правил и рабочую память? Это не изменило бы объем данных, но сеть RETE была бы меньше, потому что простые правила были бы удалены.
Альтернативный подход состоял бы в том, чтобы попытаться идентифицировать связанные группы объектов и утвердить объекты в группах во время второй фазы, дополнительно уменьшив объем данных в рабочей памяти, а также разделив сеть RETE.
Drools на самом деле не предназначен для работы на огромном количестве объектов. Он оптимизирован для выполнения сложных правил для нескольких объектов.
Инициализация рабочей памяти для каждого дополнительного объекта слишком медленная, и стратегии кэширования предназначены для работы на каждый рабочий объект памяти.
Мы также смотрели на слюни, но для нас количество объектов невелико, так что это не проблема. Я помню, что читал, что есть альтернативные версии того же алгоритма, которые учитывают использование памяти в большей степени, и оптимизированы для скорости, все еще основываясь на одном и том же алгоритме. Не уверен, что кто-либо из них превратил его в настоящую полезную библиотеку.
Использовать сеанс без сохранения состояния и добавлять объекты по одному за раз?
У меня были проблемы с ошибками OutOfMemory после разбора нескольких тысяч объектов. Настройка другого оптимизатора по умолчанию решила проблему.
OptimizerFactory.setDefaultOptimizer(OptimizerFactory.SAFE_REFLECTIVE);
этот оптимизатор также может быть установлен с помощью параметра -Dmvel2.disable.jit = TRUE