The blog posts regarding DMN performance indicate that two actions were taken to increase performance of DMN when it is run inside a full Camunda instance (e.g. a standard WildFly package). One of them was turning off history. The other was turning off the Repository.
How do you “turn off” the Repository?
What are the consequences of doing with respect to how DMN will respond through the REST API?
What effects will this have on deployment? Can you still push DMN tables directly into the Camunda instance as before and have all Camunda instances sharing the same database use them immediately or would you need to deploy them to each separate Camunda server?
What I want is the fastest possible DMN performance and retain the easy deployment mechanism offered by a full Camunda instance.
Thanks.
Hi @mppfor_manu,
first of all, there is no simple “turn off” for the repository because it’s an essential part of the Camunda process engine.
However, if you evaluate the decision by id then the engine uses the cached definition. But if you evaluate the decision by key then the engine must lookup at the database - as mentioned in the blog post.
So in order to have the best evaluation performance while using the Rest Api, you should evaluate the decision by id. If this is not an option for you, you can also provide your own implementation of the DeploymentCache.
Does this answer your question?
Best regards,
Philipp
1 Like
We’ve just defaulted to using a separate Camunda instance with history turned off. The blog on DMN performance, while technically accurate, does not represent a realistic use case for most. If you have to perform “open heart” surgery on a Camunda instance to turn off the repository (versus a simple change to turn off history), you should have noted that.
But yes, I think the question is answered.