Спектакль слюни

У меня проблема с производительностью Drools на разных машинах. Я сделал очень простой тест JMH Benchmark:

package ge.magticom.rules.benchmark;
import ge.magticom.rules.benchmark.Subscriber
rule "bali.free.smsparty"
    activation-group "main"
    salience 4492
    when
        $subs:Subscriber(chargingProfileID == 2)

    then
    $subs.setResult(15);
end

rule "bali.free.smsparty5"
    activation-group "main"
    salience 4492
    when
        $subs:Subscriber(chargingProfileID == 3)

    then
    $subs.setResult(14);
end
    @Benchmark
    public Subscriber send() throws Exception {
        Subscriber subscriber = new Subscriber();
        subscriber.setChargingProfileID(5);
        StatelessKieSession session = ruleBase.newStatelessKieSession();
        ArrayList<Object> objs = new ArrayList<Object>();
        objs.add(subscriber);
        session.execute(objs);
        return subscriber;
    }

На компьютере для домашней разработки NAME=Ubuntu VERSION=20.04.2 LTS (Focal Fossa)

(ЦП Intel(R) Core(TM) i7-8700 с тактовой частотой 3,20 ГГц, 12 потоков) 64 ГБ памяти с JDK 11 и очень высокая производительность: с 7 потоками выполняется почти 2 млн операций в секунду (без сохранения состояния)

Benchmark             Mode  Cnt        Score        Error  Units
RulesBenchmark.send  thrpt    5  2154292.750 ± 149405.498  ops/s

Но на тестовом сервере, который представляет собой процессор Intel (R) Xeon (R) Gold 6258R @ 2,70 ГГц со 112 потоками и 1 ТБ ОЗУ, у меня половина производительности (даже увеличение потоков) ИМЯ = Oracle Linux Server ВЕРСИЯ = 8.4

Benchmark             Mode  Cnt        Score        Error  Units
RulesBenchmark.send  thrpt    5  1084939.195 ± 107897.663  ops/s

Пытаюсь протестировать нашу биллинговую систему с java 11 и Drolls 7.54.0.Final. Наша система была основана на Jrockit realtime 1.6 и drools версии 4.0.3. Мы переносим систему с Sun Solaris SPARK на базовую систему Intel.

Выполняя те же правила с Jrockit 1.6, я столкнулся с проблемой производительности в домашней и предварительной среде: тест домашнего теста:

Benchmark             Mode  Cnt       Score      Error  Units
RulesBenchmark.send  thrpt   20  692054.563 ± 3507.519  ops/s

Предварительный тест:

Benchmark                   Mode  Cnt        Score       Error  Units
RulesBenchmark.send        thrpt   20   382283.288 ±  6405.953  ops/s

Как видите, это почти половина выполнения очень простых правил.

Но для реальных правил, таких как наша система онлайн-тарификации, это даже плохая производительность:

В домашних условиях я получил

Benchmark                     Mode  Cnt    Score    Error  Units
WorkerBenchmark.send         thrpt    5  152.846 ± 87.076  ops/s

это означает, что 1 сообщение содержит почти 100 итераций, поэтому в 00:01:49 тест обработал 16287 сеансов с 430590 событиями вызовов правил. вызов одного правила в среднем составляет около 2,33 миллисекунды, что не очень хорошо, но и не так плохо, как на этапе подготовки.

На тестовом сервере

Benchmark                     Mode  Cnt   Score   Error  Units
WorkerBenchmark.send         thrpt    5  35.013 ± 9.565  ops/s

в 00:01:54 я получил только 3723 сеанса, которые содержат всего 98571 событие вызовов правил. Каждый вызов в среднем составляет 10,7299 msc.

Во время выполнения всех этих тестов на тестовой системе ничего не работало. Но в домашних условиях много средств разработки, запускал тесты от Intellij IDEA.

Можете ли вы предложить что-нибудь, что может вызвать такую ​​​​разницу в производительности. Я пробовал разные версии Java и поставщиков. Эти результаты основаны на oracle-jdk-11.0.8.

Вот параметры ядра Preproduction сервера:


 fs.file-max = 6815744
 kernel.sem = 2250 32000 100 128
 kernel.shmmni = 4096
 kernel.shmall = 1073741824
 kernel.shmmax = 4398046511104
 net.core.rmem_default = 262144
 net.core.rmem_max = 4194304
 net.core.wmem_default = 262144
 net.core.wmem_max = 1048576
 net.ipv4.conf.all.rp_filter = 2
 net.ipv4.conf.default.rp_filter = 2
 fs.aio-max-nr = 1048576
 net.ipv4.ip_local_port_range = 9000 65500

person Dimitri Gamkrelidze    schedule 05.06.2021    source источник
comment
Вы тестируете с одинаковыми входными данными в одинаковом порядке на всех своих тестовых системах?   -  person Roddy of the Frozen Peas    schedule 05.06.2021
comment
Я не понимаю, что быстрее, Drools 4 или Drools 7.54.0.Final? не могли бы вы уточнить?   -  person Luca Molteni    schedule 10.06.2021


Ответы (2)


Это просто очень дикая догадка, поскольку у меня определенно недостаточно информации, но настроены ли две среды, использующие одни и те же сборщики мусора, одинаково? Может быть, вы используете ParallelGC (который, по моему опыту, лучше подходит для чистой пропускной способности при измерении) с одной стороны и G1 с другой?

person Mario Fusco    schedule 10.06.2021

Спасибо за ответ.

Я использовал несколько конфигураций GC, ни одна из них не была ParallelGC. Я думаю, что ГК не проблема. Я использовал ZGC в окончательных тестах, и время паузы GC не превышает 5 мс (тестировалось также с java 16, и время паузы ниже 100 микросекунд). :

@Fork(value = 2, jvmArgs = {"--illegal-access=permit", "-Xms10G", "-XX:+UnlockDiagnosticVMOptions", "-XX:+DebugNonSafepoints",
    "-Xmx10G","-XX:+UnlockExperimentalVMOptions", "-XX:ConcGCThreads=5", "-XX:ParallelGCThreads=10", "-XX:+UseZGC", "-XX:+UsePerfData", "-XX:MaxMetaspaceSize=10G", "-XX:MetaspaceSize=256M"}

Java-версия

    java version "11.0.8" 2020-07-14 LTS
    Java(TM) SE Runtime Environment 18.9 (build 11.0.8+10-LTS)
    Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.8+10-LTS, mixed mode)

Вот график Flame, созданный с помощью AsyncProfilers FlameGraph с домашнего ПК

Это с сервера

Как видите, в домашней среде Java-процесс использует 95% всего времени, а на сервере только 65%. разница во времени также очевидна:

RulesBenchmark.send                       thrpt    5  1612318.098 ± 64712.672   ops/s

RulesBenchmark.send                       thrpt    5  775498.081 ± 72237.890   ops/s

person Dimitri Gamkrelidze    schedule 14.06.2021

comment
Я имею в виду, вы просите предложить что-нибудь, что может вызвать такую ​​​​разницу в производительности. И это может быть буквально что угодно, начиная от плохо написанного программного обеспечения и заканчивая низкоуровневой аппаратной проблемой, такой как троттлинг процессора. - person apangin; 03.07.2021