Automation Server > Automation Server requirements > Performance and optimization

Overview

Automation Server executes your processes and delivers them to the desktops and mobiles of every business user.

For introductory information about Automation Server, refer to Automation Server.

The information presented here provides a quick reference, regarding database growth estimation according to a Bizagi project's specifics.

The following case study presents results based on a specific scenario; such exercise applies for on-premises Bizagi projects.

System characteristics

The specifications of the system used for this reference are:

•Bizagi version: 11.1.X or higher.

•SQL Server.

Scenario specification

The process used the test is the Purchase Process as available and downloadable from Bizagi's Process Xchange.

Process and case scenario

The diagram of this process is shown in the following image.

se_01

As it can be evidenced in the image, the Purchase Request process contains two sub-processes: Quotations and Purchase Order.

For a complete picture of the process from start to end, it is necessary to take a look at the following sub-processes diagrams.

The Quotations sub-process:

se_02

The Purchase Order sub-process:

se_03

The path taken as sample for this process, goes from the Start event to the End event without passing through loops or alternative sequence flows.

The same path is executed over and over by each of the multiple cases.

Such path consists of the execution of the following 8 tasks in this particular order:

•Create Purchase Request.

•Authorize Request.

•Notify approval.

•Quotations > Request Quotations.

•Quotations > Select Supplier.

•Purchase Orders > Create Purchase Order.

•Purchase Orders > Send Purchase Order to Supplier.

•Purchase Orders > Generate Order and sent to ERP.

The following image illustrates the path taken for this example, as viewed from the process level (Purchase Request):

se_05

The execution flow of the Purchase Order sub-process can be evidenced in the following image:

se_06

Data model specification

The data model of Purchase Request is depicted in the image below.

Information is written into attributes of Master entities only (those 4 shown in a blue color in its header).

As mentioned above, not all attributes shown are assigned with new values (either through an insert or an update). Those marked with a red dot are used in this case scenario.

The following table indicates the list of attributes that are considered by the cases' path, and to which entity they belong:

Entity (Master type)	Attribute	Attribute type
Products Requested for Purchase	Description	String
	Quantity	Integer
	Units	Integer
	Unit Price	Currency
	Total Price	Currency
	Purchase Request	Reference to another entity (Integer)
Purchase Approval	Approval date	Date
	Approved	Boolean
	Approval user	Reference to another entity (Integer)
	Purchase Request	Reference to another entity (Integer)
Purchase Order	Order date	Date
	Order number	Integer
	Payment term	Reference to another entity (Integer)
	Payment option	Reference to another entity (Integer)
	ERP Purchase Order Number	Integer
Purchase Request	Requested by	Reference to another entity (Integer)
	Request date	Date
	Purchase Justification	String
	Requires approval for Products/Services	Boolean
	Delivery Address	String
	Required delivery date	String
	Request state	Reference to another entity (Integer)
	Request state observation	String
	Purchase Observations	String
	City	Reference to another entity (Integer)
	Cost center	Reference to another entity (Integer)
Quotation	Quotation Cost	Currency
	Delivery date	Date
	Discount	Currency
	Unit Price	Currency
	Total Price	Currency
	Use only selected quotations	Boolean
	Quality Score	Integer
	Selected	Boolean
	Supplier	Reference to another entity (Integer)
	Purchase Request	Reference to another entity (Integer)

For all business attributes above, information was recorded only once, except for those in the Quotation entity.

For the Quotation entity, given that it was designed as a collection for this data model, two records were added.

This means that the total number of writes into business attributes can be calculated as:

6 attributes from Products Requested for Purchase + 4 attributes from Purchase Approval + 5 attributes from Purchase Order + 11 attributes from Purchase Request + 10 attributes from Quotation twice (one per row of the table).

These adds up to a total of 41 writes into business attributes.

File attachments are not considered by the exercise presented here.

By default, Bizagi stores file attachments in a file server of yours

Results

The following table displays database growth results after executing the case certain amount of times.

Number of executed cases	Data .mdf file size (KB)	Log .ldf file size (KB)	Total database storage size (KB)
0	32000	22144	54144
10000	474368	164672	639040
100000	4193536	199296	4392832

For additional reference, note that a completely blank Bizagi project, has:

•Total database storage size: 19648 KB.

•Data file size: 9472 KB.

•Log file size: 10176 KB.

In other words, an empty project (with no data model, no processes and no information on its database) occupies 19648 KB or 19.2 MB.

Consider that you may choose to partition the Bizagi database in a way that different tables are stored in different files (.mdf, .ldf). This choice is left up to the DBA's consideration and it will not affect this analysis, given that what is suggested in these cases, is to simply separate parameter entities from master entities.

The following chart represents the data .mdf file size according to the amount of cases:

DBGrowth_mdf

The following chart represents the data .ldf file size according to the amount of cases:

DBGrowth_log

The following chart represents the total database storage size according to the amount of cases:

DBGrowth_total

Average file size per case

Based on the results presented above, in average, each case having the characteristics of this particular exercise, occupies:

•Total database storage size: 52.3 KB.

•Data file size: 42.92 KB.

•Log file size: 8.01 KB.

Calculations were made by: first gathering the size occupied for each amount of cases, while first subtracting that initial size of the process model (when there were zero cases); and then dividing that resulting size between the amount of cases.

Database growth estimation

Database growth estimation