# Flowable deployed as Spring boot service in Docker Container - Performance issues

**URL:** <https://forum.flowable.org/t/flowable-deployed-as-spring-boot-service-in-docker-container-performance-issues/3481>\
**Category:** Flowable Engine\
**Created:** [February 21, 2019, 4:44pm UTC](https://forum.flowable.org/t/flowable-deployed-as-spring-boot-service-in-docker-container-performance-issues/3481 "2019-02-21T16:44:55Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![akeiker](https://avatars.discourse-cdn.com/v4/letter/a/cc9497/32.png) [@akeiker](https://forum.flowable.org/u/akeiker)\
**Post date:** [February 21, 2019, 4:44pm UTC](https://forum.flowable.org/t/flowable-deployed-as-spring-boot-service-in-docker-container-performance-issues/3481/1 "2019-02-21T16:44:55Z")

</div>

We are having some performance problems when it relates to querying for tasks and including process variables. Right now its about 40 seconds to pull 1K/2K worth of tasks. I can post more info about those timings. If we don’t include the process variables it is milliseconds. I am trying to find a way to solve this issue.

Based on digging into the performance issue, is Flowable fit to be deployed in a docker container? Are there any suggestions on what we can do to alleviate this issue. We have a few use cases that are getting hit by perfomance which make the product almost unusable for us:

1. Getting all tasks a user is eligible to claim (pulling process variables in this query)
2. Doing searches based on a process variable for the appropriate tasks

---

<div class="post-metadata">

**Author:** ![filiphr](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/filiphr/32/315_2.png) [@filiphr](https://forum.flowable.org/u/filiphr)\
**Post date:** [February 22, 2019, 8:01am UTC](https://forum.flowable.org/t/flowable-deployed-as-spring-boot-service-in-docker-container-performance-issues/3481/2 "2019-02-22T08:01:08Z")

</div>

Hey @akeiker,

Is the performance problem not an issue when not using Docker? From what you explained I don’t see how docker can be the cause of this.

In general when including process variables into queries it can take some time.

Can you please tell us which database you are using?

Cheers,  
Filip

---

<div class="post-metadata">

**Author:** ![akeiker](https://avatars.discourse-cdn.com/v4/letter/a/cc9497/32.png) [@akeiker](https://forum.flowable.org/u/akeiker)\
**Post date:** [February 22, 2019, 6:53pm UTC](https://forum.flowable.org/t/flowable-deployed-as-spring-boot-service-in-docker-container-performance-issues/3481/3 "2019-02-22T18:53:43Z")

</div>

I didn’t think Docker would be the issue either. I just wanted to confirm that using docker was an ok thing to do with flowable and we weren’t doing a pattern that it is not supposed to be used for.

Also this is what we are using for a database: Mysql version: 5.7.21 t2.medium aurora database

I am also going to try doing some Native queries to see if this helps. I also notice we are trying to get process variables along with task variables and there might be some potential to split this up?

TaskQuery query = taskService.createTaskQuery().includeProcessVariables()  
.includeTaskLocalVariables().orderByTaskCreateTime().asc();

I just thought I would check with the community to see if there are solutions that have worked for others, etc. Or things we should possibly try? I have a couple I am going to try: Get timings, compare this with Native Queries, try possibly splitting up the query above. These are the first ones I have thought of so far.

---

<div class="post-metadata">

**Author:** ![akeiker](https://avatars.discourse-cdn.com/v4/letter/a/cc9497/32.png) [@akeiker](https://forum.flowable.org/u/akeiker)\
**Post date:** [March 11, 2019, 10:15pm UTC](https://forum.flowable.org/t/flowable-deployed-as-spring-boot-service-in-docker-container-performance-issues/3481/4 "2019-03-11T22:15:41Z")

</div>

After digging into this more, I logged this issue: [https://github.com/flowable/flowable-engine/issues/1656](https://github.com/flowable/flowable-engine/issues/1656)

Passing in offset = 0. maxResults = 5,000

taskService.createTaskQuery().includeProcessVariables()  
.includeTaskVariables().orderByTaskCreateTime().asc().taskCandidateGroupIn(profiles).listPage(offset, count)

The API call above creates this query which is vary inefficient. Why not do a union if Process Variables and Task Variables are both included? Also why does it limit to 20K rows? This seems like a bug. This will never render 5,000 tasks at this point if you have say 20 variables for each task. This would likely only return 1,000 tasks in this scenario.

Right now I got around the performance issue by querying process variables and task variables separately. I still see the 20K limit a huge bug though.

select RES.\*, VAR.ID\_ as VAR\_ID\_, VAR.NAME\_ as VAR\_NAME\_, VAR.TYPE\_ as VAR\_TYPE\_, VAR.REV\_ as VAR\_REV\_, VAR.PROC\_INST\_ID\_ as VAR\_PROC\_INST\_ID\_, VAR.EXECUTION\_ID\_ as VAR\_EXECUTION\_ID\_, VAR.TASK\_ID\_ as VAR\_TASK\_ID\_, VAR.BYTEARRAY\_ID\_ as VAR\_BYTEARRAY\_ID\_, VAR.DOUBLE\_ as VAR\_DOUBLE\_, VAR.TEXT\_ as VAR\_TEXT\_, VAR.TEXT2\_ as VAR\_TEXT2\_, VAR.LONG\_ as VAR\_LONG\_ from ACT\_RU\_TASK RES left outer join ACT\_RU\_VARIABLE VAR ON RES.ID\_ = VAR.TASK\_ID\_ or RES.PROC\_INST\_ID\_ = VAR.EXECUTION\_ID\_ WHERE RES.ASSIGNEE\_ is null and exists(select LINK.ID\_ from ACT\_RU\_IDENTITYLINK LINK where LINK.TYPE\_ = ‘candidate’ and LINK.TASK\_ID\_ = RES.ID\_ and ( LINK.GROUP\_ID\_ IN ( “processor” ) ) ) order by RES.CREATE\_TIME\_ asc LIMIT 20000 OFFSET 0;

Why not a union for seperating out Process vs Task Variables???

select RES. _, VAR.ID\_ as VAR\_ID\_, VAR.NAME\_ as VAR\_NAME\_, VAR.TYPE\_ as VAR\_TYPE\_, VAR.REV\_ as VAR\_REV\_, VAR.PROC\_INST\_ID\_ as VAR\_PROC\_INST\_ID\_, VAR.EXECUTION\_ID\_ as VAR\_EXECUTION\_ID\_, VAR.TASK\_ID\_ as VAR\_TASK\_ID\_, VAR.BYTEARRAY\_ID\_ as VAR\_BYTEARRAY\_ID\_, VAR.DOUBLE\_ as VAR\_DOUBLE\_, VAR.TEXT\_ as VAR\_TEXT\_, VAR.TEXT2\_ as VAR\_TEXT2\_, VAR.LONG\_ as VAR\_LONG\_ from ACT\_RU\_TASK RES left outer join ACT\_RU\_VARIABLE VAR ON RES.PROC\_INST\_ID\_ = VAR.EXECUTION\_ID\_ and VAR.TASK\_ID\_ is null WHERE RES.ASSIGNEE\_ is null and exists(select LINK.ID\_ from ACT\_RU\_IDENTITYLINK LINK where LINK.TYPE\_ = ‘candidate’ and LINK.TASK\_ID\_ = RES.ID\_ and ( LINK.GROUP\_ID\_ IN ( “processor” ) ) )  
union  
select RES._ , VAR.ID\_ as VAR\_ID\_, VAR.NAME\_ as VAR\_NAME\_, VAR.TYPE\_ as VAR\_TYPE\_, VAR.REV\_ as VAR\_REV\_, VAR.PROC\_INST\_ID\_ as VAR\_PROC\_INST\_ID\_, VAR.EXECUTION\_ID\_ as VAR\_EXECUTION\_ID\_, VAR.TASK\_ID\_ as VAR\_TASK\_ID\_, VAR.BYTEARRAY\_ID\_ as VAR\_BYTEARRAY\_ID\_, VAR.DOUBLE\_ as VAR\_DOUBLE\_, VAR.TEXT\_ as VAR\_TEXT\_, VAR.TEXT2\_ as VAR\_TEXT2\_, VAR.LONG\_ as VAR\_LONG\_ from ACT\_RU\_TASK RES left outer join ACT\_RU\_VARIABLE VAR ON RES.ID\_ = VAR.TASK\_ID\_ WHERE RES.ASSIGNEE\_ is null and exists(select LINK.ID\_ from ACT\_RU\_IDENTITYLINK LINK where LINK.TYPE\_ = ‘candidate’ and LINK.TASK\_ID\_ = RES.ID\_ and ( LINK.GROUP\_ID\_ IN ( “processor” ) ) ) Order by CREATE\_TIME\_ asc;
