Performance of data archiving can be adjusted to a particular system. These adjustments can be made in OutBoard under "Settings". For more information on each of these particular settings and how to best adjust them, please see the section Settings. Regarding OutBoard performance, several considerations have to be taken into account.

Database vs. Application server
Data stored in Outboard is compressed in the online database, which means much less data volume is processed on the database level. For example with a compression ratio of 1:10, a data volume of 1GB would use only 100 MB on the database. Therefore database server is much less used when using OutBoard.
However the complexity cannot disappear; it is shifted on the application server side, where CPUs have to process the data (decompress, filter, aggregate). Since typically SAP BW systems have bottlenecks on database size, OutBoard can also help to load-balance the resource usage between application servers and database servers.

Memory
For data decompression, filtering, and aggregation, OutBoard is using the main memory on the application server as a temporary storage area. Usually in reporting only a small amount of rows is required as output (i.e. maximum several thousands of rows) and therefore one work process requires only as much memory as two times the biggest data object within a request. To keep the memory requirements low, data objects shouldn't have more than 100 000 entries (this amount varies based on table width, memory available, and the number of parallel work processes used for reporting). Memory requirements are valid also for OutBoarding and Un-OutBoarding since data is processed 1:1. The situation is different for loading the data from OutBoard via DTPs, where complex aggregations can take place. To keep the memory requirements as low as possible, semantic groups in the DAP definition should be used. These InfoObjects should be also part of the target InfoProvider.

Work processes
Reporting as well as data loading can be processed in parallel. However, the type of work process (WP) used is different:

Reporting uses dialog WPs
Data loading background WPs.

Make sure that there are enough WPs available. Otherwise, the reporting may be actually slower than if processed not in parallel. The loading can even run into a deadlock, where the main job is waiting for parallel jobs, but they cannot be started because there are no free background work processes available.

Browser not supported