Zeebe Performance Testing Low Numbers

Camunda 8 Topics
1

I have setup a basic camunda with zeebe enabled with embedded gateway using the helm charts with default configs only. I am trying to performance test it but i am not able to process more than 30 P/second.

For my test i am using a jmeter script with JS2R Sampler where i am creating a client deploying the process and starting that process and after that closing the client. I am doing the process deployment and start for 25k times in 15 minutes for which it should be easily able to do so with a rate of 27.77 per second.

Any input would be helpful here.

But this is always giving me errors like this -
SEVERE: ~~~ Previous channel ManagedChannelImpl{logId=315, target=host:26500} was garbage collected without being shut down! ~~~
Make sure to call shutdown()/shutdownNow()
java.lang.RuntimeException: ManagedChannel allocation site
at io.grpc.internal.ManagedChannelOrphanWrapper$ManagedChannelReference.(ManagedChannelOrphanWrapper.java:102)
at io.grpc.internal.ManagedChannelOrphanWrapper.(ManagedChannelOrphanWrapper.java:60)
at io.grpc.internal.ManagedChannelOrphanWrapper.(ManagedChannelOrphanWrapper.java:51)
at io.grpc.internal.ManagedChannelImplBuilder.build(ManagedChannelImplBuilder.java:709)
at io.grpc.ForwardingChannelBuilder2.build(ForwardingChannelBuilder2.java:272)
at io.camunda.zeebe.client.impl.ZeebeClientImpl.buildChannel(ZeebeClientImpl.java:193)
at io.camunda.zeebe.client.impl.ZeebeClientImpl.(ZeebeClientImpl.java:112)
at io.camunda.zeebe.client.impl.ZeebeClientBuilderImpl.build(ZeebeClientBuilderImpl.java:496)
at io.camunda.zeebe.client.ZeebeClientBuilder$build$30.call(Unknown Source)
at Script1.run(Script1.groovy:7)
at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:317)
at org.codehaus.groovy.jsr223.GroovyCompiledScript.eval(GroovyCompiledScript.java:71)
at java.scripting/javax.script.CompiledScript.eval(CompiledScript.java:89)
at org.apache.jmeter.util.JSR223TestElement.processFileOrScript(JSR223TestElement.java:230)
at org.apache.jmeter.protocol.java.sampler.JSR223Sampler.sample(JSR223Sampler.java:72)
at org.apache.jmeter.threads.JMeterThread.doSampling(JMeterThread.java:651)
at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:570)
at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:501)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:268)
at java.base/java.lang.Thread.run(Thread.java:829)

2

Hi,
check mainly zeebe parameters clusterSize, partitionCount, cpuThreads, ioThreads and pod resources requests and limits. Generallz speaking number of leader partitions (see that partitionCount) means number of parallels processing and if you provide enough resources to it by other parameters and real resources then you have the performance you want.
The things I am not sure and asking in other topic is about jvm memory configuration. Whether to let it automatically set based on the resource limits or whether try to do it “manually”.

3

Yeah i have increase broker counts also but still when i run the tests from any machine that machines resources gets exhausted or i get the aboce error that i mentioned or grpc call option error timeout 9 seconds exceeded i am just trying to run 30000 in 15 minutes.

4

Are you really doing the deploy for EACH run of the process? That’s not how it’s meant to be done. That’s a lot of heavy lifting on each process.

Typically, a process is deployed, and then run 25k times. Deployment is a heavy operation, which I could see leading to the low numbers you’re seeing.

3 Likes
5

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.