A while ago, somebody proclaimed their application was going out of memory sometimes due to Activiti. I don’t need to tell you that this hurt my developer heart. We know our architecture is sound and very resource-friendly. But without hard numbers, anybody can just blurt out that Activiti is a memory hog without us being able counter it.
So I decided to do the sane thing. I measured … and boy, was I surprised with the results!
I cobbled together something which would mimic typical Activiti usage. The code is open and available on
This program does the following:
The processes that are started are randomly chosen from five deployed processes (in the order of the picture below):
I decided to use following parameters for running the test. Note that I did not tried to play around with these settings. It could very well be that a much higher throughput is possible, but I believe that the numbers I chose now are an adequate representation of a company doing a fair amount of business process management.
Again, I didn’t check what the limit of these numbers was. It could very well be you can start 500 processes per second. But the point here is memory usage.
Also, I’m using a standard MySQL installation (just installed, nothing tweaked) as database.
To make it a but interesting, I decided to start low and build up from there. So I ran the benchmark using 32 MB of heap space:
java -jar -Xms32M -Xmx32M -XX:+UseG1GC activiti-memory-usage.jar
Note that i’m using the new G1 garbage collector which is supposed to be doing good in cases where memory usage is more than 50% of the max heap. I also attached the Yourkit profiler to get an insight into the memory usage. I let the benchmark run for 30 minutes. When I came back, following statistics were shown:
So to my surprise 32 MB was enough to finish the benchmark! And using it during 30 minutes allowed to finish 3157 process instances and complete 12802 tasks! And even more, the profiler showed me that it wasn’t even using all of the available memory (see first chart)!
You can also see that when the garbage collector passes by, only 13MB is being used:
And the CPU was really boring himself during the benchmark: It never really goes above 10% usage.
Also, there was quite a bit of garbage collecting going on (28 seconds on 30 minutes), which is expectable:
The first test learned us 32 is more than enough to run this ‘BPM platform’. And like I said, I believe that the load isn’t that different from a typical company using a BPM solution. But how low can we go?
So I reran my tests using less memory. I quickly learned that when throwing less than 32 MB of RAM at it, I couldn’t complete the benchmark with the Yourkit profiler attached. Probably the profiler agent also steals some memory. So I ran the benchmarks using less memory:
java -jar -XmsXXXM -XmxXXXM -XX:+UseG1GC activiti-memory-usage.jar
I tried 24 MB. Success!
I went down to 16 MB. Success!
I went down to 14 MB. Dang! Out of heap space. But no worries: the exception occurred when the BPMN diagram was generated during process deployment. This takes quite a bit of memory, as Java2D is involved and the PNG is built up in memory. So I configured the engine to not generate this diagram (setting ‘createDiagramOnDeploy’ to false). And yes. Success!
I went down to 12 MB. Success!
And 12 MB of Ram was the lowest I could go. With less memory you get ‘out of heap space’ exception quickly. The statistics for the 12 MB run are actually quite similar to the 32 MB version.
Let me rephrase that: A measly Twelve Megabytes of RAM memory!! Twelve!!
Activiti (or at least my approximation of a typical Activiti load) needs 12 MB of memory to run. Probably even less, cause the fifty user threads also take up some memory here. To put this in perspective:
Edit 5 feb 2013: See comments below. Andreas has succeeded in running it on 9MB!
Of course, in a ‘real’ application, you’d also need a web container, servlets, REST layer, etc. Also, I didn’t touch the permgen settings. But it is equal for all Java programs. The point remains the same: Activiti is REALLY memory friendly! And we learned earlier that Activiti is also really fast.
So why even bother looking at the competition?
Cool! I can go as low as 9MB:
java -jar -Xms9M -Xmx9M -XX:+UseG1GC activiti-memory-usage.jar
but then I get a couple of ActivitiOptimisticLockingException on the way. Changed the pom to use version 5.11 and the latest postgres jdbc driver available at maven.alfresco.comWow, nice!
ActivitiOptimisticLockingException are not an issue. In fact, they are anticipated with that little memory. The task completion thread is written in a way that it simply catches the optimistic locking exception and retries a bit later.
But 9MB ! That’s freaking awesome! What machine (more specifically: which operating system) did you test it on? Which JDK?
It also might be the postgres driver is more resource friendly.
Thanks for sharing this!
[…] can read in his post, he has a setup of 50 Activiti Process Engines in the same JVM. And, while Activiti uses very little memory, he was interested if it could be brought down. More specifically, after profiling, he found that […]