Running the script can be a highly CPU-intensive process, depending on the volume of data to be imported as time sheets. To accommodate various quantities of data, you can change the
-maxThreadcount argument for the number of threads the script uses. Test and production environments should be configured to help address performance considerations, as described in the following sections.
As part of testing the conversion of data in the
.xml files to time sheets (see Strategy for Testing and Importing the Data), we recommend running the script in a TEST environment against a subset of the actual data files to be imported as time sheets. Some tests should use a subset that is large enough to evaluate the CPU resource demand of the script and to determine an optimal number of threads for the script to use.
Make sure that the database in the TEST environment is correctly configured and sized to accommodate the time sheet data to be imported.
To avoid affecting end user performance when running the script against all of the data to be imported in the production environment, we recommend running the script on a separate physical host in production that does not include nodes with user traffic. For very large volumes of data, we recommend configuring a separate server as a host in the PPM cluster or instance, but with no PPM nodes configured on that host. Only the PPM home directory should be configured on that host, because the script requires its assets and configuration data. When the time sheet import process is completed, this host can be removed.
Make sure that the database in the production environment is correctly configured and sized to accommodate the time sheet data to be imported.