Chapter 13. Performance 303
/SM590000For IBM i, depending on your retrieval patterns and system hardware configuration, it 
might be advantageous to not store a duplicate set of documents in the Content Manager 
OnDemand cache when you use ASM because ASM might already be using disk space. If 
the application group uses ASM, caches the data, and specifies the migration of data at 
load time, two copies of the data are stored during the load. One copy is stored in cache, 
and one copy is stored in the ASMREQUEST directory. 
To avoid storing a duplicate set of documents in cache for non-AFP data, change Cache 
Data to No on the Storage Management tab of your application group definition. To avoid 
storing a duplicate set of documents in cache for AFP data, you might change Document 
Data to No Cache but leave Resource Data in cache for faster retrieval.
/SM590000For IBM i, every user that loads data must have a home directory. If users do not have a 
home directory, the temporary files are stored in the root directory of the integrated file 
system (IFS).
/SM590000If the data source is on a remote system, you can load the data into Content Manager 
OnDemand on the remote system and directly store the export data to the specified 
Content Manager OnDemand library and object server. 
Or, if the data source is on a remote system, you also can upload the data to the specified 
Content Manager OnDemand server through FTP and then load the data on the selected 
Content Manager OnDemand system.
/SM590000For Multiplatforms and z/OS, all file systems must be dedicated file systems that are 
mounted on their own mount points.
/SM590000For z/OS, when you load PDF reports (by using the PDF Indexer), placing the input report 
in the HFS or zFS causes the load to run nearly 50 times faster that compared to the input 
report that is placed in a VSAM file.
13.2.3  Load testing
The goal of load testing is to verify that, under stressful system conditions, the required 
amount of data can be loaded into the Content Manager OnDemand system within a time 
window.
A general approach to load testing a system is described:
/SM590000Parallel loads: Run a single load and measure the load throughput. If the throughput does 
not meet the requirements, run two loads in parallel and measure the throughput. While 
the loads are run, collect system statistics to determine the system resources that are 
being used and any potential bottlenecks. Tune or acquire additional system resources as 
needed. Progressively increase the number of parallel loads until the required throughput 
is met.
/SM590000Data types and exits: A different data type, and whether an exit is started during the load 
process, affects the load throughput. Test samples of the different types that represent the 
general loads.
Note: For most users, a single load process meets the ingestion throughput 
requirements.