ARSystem 7.1 – Status History
This article is part of the New in ARS 7.1 series
One of the new options in 7.1 is the option to disable the Status History for forms. This has the advantage that the Status History tables in the database do not need to be updated. Theoretically this could save a lot of time.
Functionality
The Status History of a form can be disabled by going to Form Properties and checking the ‘Disable Status History’ button on the ‘Basic’ tab. This has to be done for each form separate.
Test
To test out this new functionality I built a small application (Download here to test yourself). It has two forms, one with Status History enabled and one disables. Both forms have 1000 records. Separate is a Display Only field with a button and four fields, each recording the time it takes to set the status of all records to Assigned and back to New. The four times it records:
- Changing status of 1000 records with Status History
- Using Active Links
- Using Filters
- Changing status of 1000 records without Status History
- Using Active Links
- Using Filters
The improvements speak pretty much for themself, keeping in mind that the testenvironment is a bit extreme.
Testhardware: VMWare Workstation on Core 2 Due 2.0 Ghz with 2 Gb RAM. VMWare RAM: 1552 Mb
The following times (seconds) are averages over 5 tests:
|
|
Active Link Push Field | Filter Push Field |
| With Status History | 34.2 | 4.8 |
| Without Status History | 32.8 | 3.8 |
As expected the biggest percentual gain is on the server, almost 20% !
SQL
If we look at the SQL that gets generated when updating one record we can see how we get there. this is the SQL that gets generated when updating a ticket in the user tool with Status History enabled:
*/BEGIN TRANSACTION
*/OK
*/UPDATE T1676 SET C7=1,C5=’Demo’,C6=1189331127 WHERE C1 = ‘000000000000001′ AND ((C6 <= 1189331110) OR (C5 = ‘Demo’))
*/OK
*/UPDATE H1676 SET T1=1189331127,U1=’Demo’ WHERE entryId = ‘000000000000001′
*/OK
*/COMMIT TRANSACTION
*/OK
*/SELECT C1,C2,C3,C4,C5,C6,C7,C8,0 FROM T1676 WHERE C1 = ‘000000000000001′
*/OK
*/SELECT entryId,T0,U0,T1,U1,T2,U2,T3,U3,T4,U4 FROM H1676 WHERE entryId = ‘000000000000001′
*/OK
As you can see first we update the ticket table (T1676), then the status history (H1676), after that we retrieve the ticket first, and then again the status history.
The following SQL is without Status History:
*/BEGIN TRANSACTION
*/OK
*/UPDATE T1677 SET C7=1,C5=’Demo’,C6=1189331073 WHERE C1 = ‘000000000000001′ AND ((C6 <= 1189331035) OR (C5 = ‘Demo’))
*/OK
*/COMMIT TRANSACTION
*/OK
*/SELECT C1,C2,C3,C4,C5,C6,C7,C8,0 FROM T1677 WHERE C1 = ‘000000000000001′
*/OK
As you notice, 50% less SQL statements! This is of course only because there is no further workflow on the form, large forms with lots of checking and other workflow (push fields) will not notice too much performance improvement. However this will drastically improve the performance of mass updates through the Atrium Integration Engine (the application formely known as EIE).
Database
When disabling the Status History functionality, all information in the H table is deleted, however the table itself is not removed from the database.
Conclusion
Very neat feature, that on mass updates will improve the perfomance a lot. In normal daily use it is unlikely that users will have a notable performance increase when updating tickets, but of course it will ease up on the load of a database. It would perhaps have been nice to have a general checkbox to disable all Status History on a server.
7.1, arsystem, bmc, new in 7.1, remedy
Recent Comments