PresenceBPM - Improving Performance

The timing of tasks is very important. If a queued task has no schedule in it then it will run repeatedly around every minute, 24 hours a day.

Ask yourself how often a task really needs to run.

Don't schedule all tasks to run at the same time as they will collectively hog system resources.

 

For lots of scheduled tasks that do need to run around the same time put these into a single task remembering to use an error handler .

For each task clear the data tables and variables, this will save system thread and memory resources.

When using Microsoft SQL Server, you will need to create a custom query to facilitate connection pooling.


This is just a small query on a small table to let Presence know whether the connection for that resource still exists or whether it needs to create a new one.

If there is a certain task that you need to optimise then you can enable Tasks Statistics in the task properties.

Once the task has ran a few times, you can view the statistics for this task from Task Statisitics from the Task Menu.

This will help you to identify and locate bottlenecks.


If you just want to read a file or contents of a simple url use the read text file  instead of the Object Monitor  .

SQL  as opposed to append columns .

So the select would be:-

    'Select  FIRSTNAME || SURNAME as FULLNAME from app.tasks range=1-10'

As seen in this statement it is possible to limit the data returned with the range keyword.

What Presence does in this instance is internally produce the full dataset and then chop it down to the range you've specified.

Because of this it would be actually quicker to limit the data in the first place by modifying the SQL, than to use the range feature.

You should also think about how you iterate over the data set.

Let's say you're building up a string based on a dataset and split the data up for each row  , setting a variable for the current row.

It's better to append each row variable to a file  in the split, rather than add the variable row to a task variable and then write that variable to a file at the end.

That is to say that the following task will experience an exponential increase in the time it takes to run as the data table gets bigger.

This is due to the ${totalreport} variable getting bigger each time.



It is the ${totalreport} variable that is slowing the task down, exponentially so as it gets bigger and bigger.

This is because each time the variable is written to, it is actually creating a new one (of a larger and larger size each time).



Whereas the following task, does the same thing, but much more efficiently as it appends the row variable directly to the file.



Because of this it has no need to append the ${row} variable to the ${totalreport} variable.