Change Tracking allows you to troubleshoot and debug issues, find information about specific objects, and revert an object to a specific state. However, Change Tracking affects the system performance. In some situations, the performance consequences of Change Tracking can be significant.
This section describes how to improve the system performance.
When to Enable or Disable Change Tracking for a Project
In some situations, enabling or disabling Change Tracking on a project causes significant performance consequences. The CloudBees CD/RO system performance becomes slower as the server writes to the database the records for all the tracked objects in the project.
To determine when to use Change Tracking on a project, do the following:
-
Export the project using this command:
ectool export <project_name> --relocateable 0 --withAcls 1 – withNotifiers 1 -
Evaluate the results.
-
The size of the results file gives you a good estimate of how big the project is:
-
If the file size is in the hundreds of MB, the project is large.
-
If the file size is in the tens of MB or less, the project is small.
-
-
(Optional) Write a script to parse the results and determine these statistics:
-
Total number of objects that can be tracked in the project.
Use this value to determine the project size (for example, small, medium, or large), which is used to determine how long it would take to enable, disable, copy, import, or delete a project on which Change Tracking is enabled.
-
The total size (in XML format) of the entities in the project that can be tracked by Change Tracking.
This gives a rough estimate of how much the database usage will immediately grow when Change Tracking is enabled for the project.
-
The rate at which tracked entities are modified in the project.
Look at the most recent last-modification dates of entities owned by the project for a pattern where certain entities are modified on a regular basis.
If there are objects that appear to be being modified frequently, the script can also parse out their path and the user name they were last modified by.
-
-
Next Steps:
-
If the project is small, and its contents are not frequently changed by an automated process, you can safely enable Change Tracking for it.
-
If the project is large, and if you frequently export, import, or copy it, and if the performance of these operations is very important to you, enabling Change Tracking for it may be problematic (see Estimating Process for a possible workaround).
-
If significant parts of the contents of the project are frequently updated by an automated process, enabling Change Tracking for the project will consume significantly more database space, and tracking the changes performed by the automated process is unlikely to be of much value, so enabling Change Tracking for the project is inadvisable.
Splitting Tracked Objects Into Separate Projects
If you export the project, evaluate the results, and determine that enabling or disabling Change Tracking on the project will significantly affect the performance of the CloudBees CD/RO system, one way to improve the system performance is to split the project into separate projects based how the objects are modified.
For example, if you parse the results and find that there are two types of entities in your current project:
-
Objects that are manually modified over time by real users.
These objects represent real changes in project and are modified as procedures, jobs, and applications or microservices are run.
-
Objects that are frequently updated at regular intervals by an automated process using metaprogramming.
These objects are automatically generated and updated on a regular basis. The project file should have a large list of modifications to tracked objects.
Then you should split the objects into separate projects.
-
Put the objects that are manually modified by real users in one project and enable Change Tracking on this project.
-
Put the objects that are updated by an automated process in a different project and disable Change Tracking on it.