Introduction

DB2 CommonStore for Lotus Domino is a great tool for archiving e-mails or other Notes documents. While in smaller customer environments the default settings are good to achieve sufficient archiving throughput, you should plan to tune CommonStore in medium and large environments.

In this article, we will look at the different aspects of optimizing the archiving throughput when using DB2 CommonStore for Lotus Domino v8.3 (CSLD) with Content Manager v8.3 (CM) as backend repository. The numbers given are taken from Windows® and UNIX® environments and may be different for other platforms and other repository options than Content Manager.

Back to top

Data flow during archiving

Archiving an e-mail (or any other Notes document) from Lotus Domino really means moving a data object, combined with additional attribute information, from Lotus Domino into IBM Content Manager (CM). From a technical perspective, this involves several components and steps as depicted in Figure 1.

The data flow occurs as follows:

1. A CSLD task thread accesses the Domino server via the Notes API and reads the data. Each CSLD task can have one or more threads.
2. The CSLD task stores the data in a temporary file on the CommonStore server and connects to the archpro server (a sub-component of CommonStore) via a TCP/IP port.
3. The archpro server acts as a dispatcher for one ore more CM agents that serve as connectors to CM. The CM agent picks up the data from the temporary data file and stores it in the repository by using the CM Java API.
4. The data is stored as a CM document or resource item in a CM item type.
5. After the archiving, the return code is returned in the opposite direction so that the CSLD task thread can stub or remove the message in Domino.
6. The CM system can also create and maintain a full-text index of the archived objects (optional setting). This is an asynchronous process that extracts the text information from the archived objects to update the full-text index. It needs to retrieve the archived object for this purpose.
7. The CM configuration determines how the e-mail is stored. Typically, it is stored on a hard drive before being migrated to other storage such as tape. CM makes use of Tivoli® Storage Manager (TSM) to store archived objects on devices other than hard disk. It connects to TSM via the TSM API set. This storage migration is an asynchronous process that is often scheduled to run once a day in the evening hours.
8. The TSM server moves the data to a specific hardware device. Each device has its own write/read characteristics.

In the case of CSLD, steps 1-5 are synchronous. This means that the CSLD task cannot start processing a new archiving request (a CSLD job consists of one or more archiving requests) before having finished the previous job. Looking at the above flow, the overall archiving throughput is really dependent on (or consists of) various sub-throughputs:

1. The throughput from Domino into CM (steps 1-5). This can be called the CommonStore throughput.
2. The full-text indexing speed within CM (step 6).
3. The throughput of the migration from CM to TSM (step 7).
4. The write throughput to the physical storage device (step 8).

It is not necessary that all sub-throughputs are the same. Assume that a certain mail volume (in GB) has to be archived per day. Maybe the archiving from Domino into CM is done in 8 hours, the full-text indexing takes 3 hours, and the migration to TSM and storage on tape is finished in 30 minutes. So the first step in optimizing the archive throughput is to determine the likely bottleneck among the four sub-throughputs.

Example 1: In a customer environment, the full-text indexing took much longer than the transfer from Domino into CM. The analysis showed that many objects to be indexed were already stored on tape. Since full-text indexing requires extracting the text information, many object went through a painfully slow retrieval from tape, impacting the speed of full-text indexing. Changing the migration policies from CM to TSM fixed this issue by keeping the objects to be indexed on hard disk.

Example 2: In a customer environment, the Domino servers were distributed on several sites whereas the CSLD, CM and TSM were centrally located. The CommonStore archiving throughput was rather poor compared to the other sub throughputs. The reason was an insufficient bandwidth of the WAN connections to the Domino servers.

This article focuses on optimizing the throughput from Domino into CM that is mainly determined by CommonStore. Optimizations within CM, the underlying DB2, TSM, or the hardware device are beyond the scope of this article.

Back to top

Single archive transaction duration

Optimizing the archiving throughput in CommonStore should start by looking at a single archive transaction before attempting to parallelize them to increase the overall throughput. So how long does it take to archive one single Notes e-mail? Is there a simple answer to this question? If the Domino, CommonStore and CM server are in a central location (LAN connected, 100 Mbits Fast Ethernet or better), each Notes mail should be archived in 0.6-1[s]. This number is based on an average e-mail size of 70-100 KB as we see it in our projects these days. As there is a base overhead per transaction, a smaller average message (10 KB, for instance) will not reduce the transaction duration significantly. A mail of 2MB or larger, however, will take a couple of seconds, for example.

Based on the typical duration of a single transaction mentioned before, a single-threaded CommonStore throughput is typically in the range of 3,600-6,000 mails per hour. If you want to see how your system compares, you should archive 100 or more mails from the same mailbox and check the CSLD job for the duration field. Note that you need to select the property Leave Request in Job database when creating the CSLD job so that the successful job is not automatically removed after archiving.

If you have the CommonStore single-instance-storage (SIS) algorithm activated, make sure that all mails are different and not yet stored in the repository. Otherwise, the numbers will be misleading since duplicates are not archived. Tracing of the CSLD task and archpro should be de-activated. Figure 2 shows the result on the demo system used for this article. 100 documents took 58 seconds, corresponding to a CommonStore throughput of 6,200 mails per hour.

The total time of 0.6-1 [s] is spent on extracting the information from Domino, internal processing and the actual store operation into CM. The latter can best be analyzed by looking at the ai*.log file, generated by the archpro processes (with logging activated). For each transaction (archive, retrieve ...), a line is added. This log can easily be loaded into a spreadsheet for further analysis. Figure 3 shows an example of such an ai*.log file loaded into MS Excel (with some columns hidden).

Column T_ag shows the time in seconds that the CM agent spends for storing the mail in CM. It is usually in the range of 0.2-0.6 [s] for mails sized 70-100 KB. The far right column logs the object size in bytes. If you encounter a significantly higher T_ag value in your system, there are several potential reasons:

• Missing or corrupt database index: If you have the CommonStore SIS algorithm activated, the CM agent checks to see if the hash code of the new document is already present in the repository to avoid duplicates. This check requires that a database index for the attribute CSCDISIS is configured in CM. If not, the check for duplicates will become slower and slower the more documents are already stored in the repository. Note that this is usually not the only attribute with a database index. If users are allowed to search their archived mail, the fields CSLDOrigDB and main search criteria (like the Subject attribute) should also have a database index configured.
• WAN: You may have a slow network between CommonStore and CM server.
• General CM server performance issues: Performance issues can be caused by other load issues or suboptimal system performance.

The ai*.log will show also if slow archiving operation is limited to certain times during the day. In some cases, some periodic maintenance processes (like backup, database reorganization, antivirus scan …) on the Content Manager, CommonStore or Domino server can cause temporary performance degradation.

Back to top

Optimizing CommonStore archiving throughput

While a single-threaded archiving configuration as described before is able to archive in the range of 0.3 to 0.6 GB per hour (or 6-12 GB in a 20-hour day) based on the previous analysis, this might not be enough to provide e-mail archiving to a large user population. To increase the CommonStore archiving throughput, it is recommended to parallelize the archiving threads. All the sub-components depicted in Figure 1 can be configured to run in parallel: there can be several CSLD tasks (each with parallel internal threads), and there can be several archpro instances (each with parallel CM agents).

Adding more CM agents can be done directly in the archpro configuration file archint.ini by setting the keyword CMAGENTS to the desired number of parallel agents. Adding a second archpro instance is straightforward as well. It requires copying the instance01 directory and pasting is as instance02. The archint.ini file of instance02 needs to be modified so that all references to the instance directory reflect the instance02 location.

Moreover, it is necessary to assign a different port number where the new archpro instance listens to requests. It is defined by the keyword ARCHPRO_PORT in archint.ini. Note that you need to have at least two CSLD tasks to leverage a second archpro instance since a CSLD task cannot connect to more than one archpro instance at the same time.

Increasing the number of parallel CSLD tasks and particularly their internal threads, however, is not as straightforward. Instead of setting a parameter in some configuration document, you need to analyze the environment and design the setup so that parallel CSLD task threads are possible. Let us have a closer look at two typical examples.

Example A (mailbox management): The customer has 1,000 mail users on one Domino R7 server. The mail databases are distributed into four data directories, each holding 250 NSF files. The default configuration for CSLD consists of one CSLD job database that is served by one single-threaded CSLD task (connected to one archpro server). The single CSLD task thread services all jobs in a sequential way and connects to one user mailbox after the other to extract the mails.

Example B (compliance and discovery): The customer has one Domino server. For compliance reasons, all e-mails are journaled; that is, before arriving at the user Inbox, a copy of each mail is taken and stored into a journal mailbox (NSF file). There is just one CSLD job database. The single CSLD task thread processes all archive requests for the journal database.

In the above scenarios, if the performance deems insufficient, the first step usually taken is increasing the number of CM agents as explained above. But this will not improve performance at all because of the sequential processing done by the CSLD task! As long as there is just one CSLD task thread active, only one CM agent will be busy. This is why we need to understand how to increase the number of parallel CSLD task threads so that more CM agents can be used by archpro.

As discussed before, the CSLD task services all jobs in a CSLD job database. Let us assume that in example A, there are 1,000 jobs to process, each from a different user database. A single-threaded CSLD task will see all 1,000 jobs and process them sequentially. If we want to have four CSLD task threads (within the same CSLD task), we need to ensure that each thread processes a subset of the 1,000 jobs. On the other hand, two threads should never act on the same job, to avoid data inconsistencies. CommonStore for Lotus Domino addresses this requirement by giving each thread a different view of all jobs so that each thread has its separate list of jobs to be processed. Figure 4 shows how multiple threads within a single CSLD task can be set up.

The first option All databases corresponds to a single-threaded configuration. With the second option Selected Domino servers, it is possible to configure separate threads per Domino server. Assume that you have two Domino servers. Thread 1 sees and processes all jobs related to mailboxes on Domino server one whereas thread 2 services all requests for server 2. For the example scenarios from before, however, this setting will not bring any improvement since there is just one Domino server. Moreover, it is best practice to create one CSLD job database locally on each Domino server, each serviced by a separate CSLD task. For the mentioned two-server configuration, this translates into two single-threaded CSLD tasks, each servicing their related CSLD job database. So the second option is rarely used in real-world system implementations.

The third option, Selected databases or data directories is often the preferred one. It allows configuring separate threads for individual databases or entire directories. In Figure 4, there are 4 threads configured: thread 1 processes all requests related to the test1.nsf database, thread 2 for test2.nsf, and so on. The threads are automatically started by the CSLD task and will run in parallel. If the task is started in a command window, the individual threads become visible as depicted in Figure 5. Note that each CSLD task thread has also its own trace and log files.

What would happen to a job that requests archiving from database test5.nsf? Which thread would pick it up? The answer is: None of the threads is even seeing this job. It would sit there indefinitely with status Waiting to be processed.

Let us revisit the example scenario A from before. One (theoretical) way is to configure a separate thread per mailbox. Having 1,000 threads, however, is not a realistic approach, both from a maintainability perspective, but also with respect to potential Windows multi-threading limitations and memory constraints. The best practice approach is to assign one thread per mail directory. In the example scenario A, there are then four parallel threads: thread 1 services mail directory mail1, thread 2 directory mail2 and so on and so forth.

The 4-threaded task connects to one archpro instance. If there is just one CM agent configured, archpro could become a bottleneck since this one agent would need to serialize the archiving operations requested by the four parallel CSLD task threads. This is why it is recommended to configure four CM agents to ensure that there are four parallel "pipes" from Domino into Content Manager. (If multiple retrieval requests are expected in parallel to archiving, the number of parallel CM agents should be further increased.)

In such a configuration, if two users have their mailboxes in separate mail directories, their archiving requests can be processed in parallel. If they are in the same mail directory, however, their requests will be processed by the same thread in a sequential way. This configuration option allows also a special handling of "VIPs" by adding a special thread for just one mailbox, giving it thus priority treatment for processing. Note, though, that these special mailboxes need to be located in a separate directory. Otherwise, the standard CSLD task thread (running on the data directory) and the special CSLD task thread (running on a single user database) would compete on archiving, with the risk of causing data inconsistencies.

How can this configuration option help in example scenario B? In such an environment, all mails are extracted from just one Notes database (the journal). None of three thread configuration options depicted in Figure 4 will help since it is always the same database on the same Domino server where mails are archived from. The outcome is always a single-threaded CSLD task. Assuming a 20 hour per day processing window and a low-end throughput of 3,600 mails per hour, this gives an archiving volume of 72,000 mails per day for 1,000 users (or 72 mails per user per day) which is in most cases more than sufficient.

If there are more mails to be archived, or the time window available for archiving much shorter than the 20 hours assumed above, the following work-around can help parallelize the archiving. A (custom) Notes agent creates archiving jobs at random or in a round-robin mode in 4 CSLD job databases (instead of just one). You can then set up four separate (single-threaded) CSLD tasks, each servicing its related job database. Even if all mails remain in the same database, there will not be an access conflict since each mail is referenced in a unique CSLD job. The four single-threaded CSLD tasks connect to the same archpro instance with four CM agents. As in scenario A, this setup ensures four parallel "pipes" from Domino into Content Manager.

Back to top

Parallel archiving operations

A good way to verify the parallel setup is to look at the CSLD job database. Multiple jobs in parallel status clearly indicate parallel processing. In Figure 6, there are 5 jobs in pending status. This means that there are 5 parallel CSLD task threads.

If you have several job databases, you need to do the same analysis for each CSLD job database and sum up the parallel threads.

If you want to verify that the CM agents of archpro are actually connecting and archiving to the CM repository in parallel, the ai*.log will not show this information. While there is a column called PID as depicted in Figure 3, it will always have a value of zero and not reflect the agent number. The only way to find this out is activating archpro tracing. In the trace, you need to search for CM-AGENT WORKER -POOL: notified CM-AGENT WORKER to see which CM agent has been used for archiving. If worker 2 or 3 gets activated, this is a clear indication that the archiving is done in parallel since it shows that worker 1 is busy. Listing 1 shows an excerpt of the archpro trace

				
[16:37:09.568 20-09]  CM-AGENT WORKER -POOL: notified CM-AGENT WORKER #1
                      [com.ibm.esd.commonstore.task.CSThreadPool]
[16:37:09.568 20-09]  Job (ID: : SERVER-JOB QUEUE   : added response server-job 
                      (new job count: 1)
                      [com.ibm.esd.commonstore.job.CSServerJobQueue]
[16:37:09.568 20-09]  SERVERJOB QUEUE: In getNextJob: got a job   
                      [com.ibm.esd.commonstore.job.CSServerJobQueue]
[16:37:09.568 20-09]  CM-AGENT WORKER #1: Job <3> start job processing 
                      [com.ibm.esd.commonstore.agent.worker.CSAgentWorkerThread]
[16:37:09.568 20-09]  processJob() is starting.   
                      [com.ibm.esd.commonstore.agent.worker.CSAgentWorkerThread]

Table 1 shows some CommonStore throughput numbers in a test environment with low-end, rather aged PC servers. Each column represents one test case.

Cases 1 to 4 show how the CommonStore throughput can be increased by multi-threading the CSLD task. While there is an obvious performance improvement with up to 4 CSLD task threads connected to a single archpro instance, case 4 clearly shows that archpro becomes a bottleneck when there are 8 CSLD task threads. This can be avoided by adding a second archpro instance as done in case 5. Thus it is a best practice recommendation to add additional archpro instances (and thus also an additional task) whenever there should be more than ~4 parallel "pipes" into the CM repository.

As a matter of fact, there are always two ways to increase the number of parallel CSLD task threads. In our cases 1-4, we have configured just one CSLD task with several (internal) CSLD task threads. An alternative approach, with similar performance characteristics, would have been to configure additional (single-threaded) CSLD tasks, each servicing a specific directory or Notes database. Thus four single-threaded CSLD tasks give about the same archiving throughput as one CSLD task with four internal threads. For operational reasons, however, the second configuration option is usually preferred since it allows stopping and starting the archive process with just one command (or one Windows service), without caring about the various internal threads. The first option, however, has the advantage that different time periods for archiving can be scheduled since the time slot can be configured per CSLD task.

Case 6 confirms that archiving messages that are five times larger is just slightly slower. This also leads to the conclusion that measuring the throughput in GB might give incorrect results in a system sizing. Comparing cases 3 and 6 shows that identical setups might result in throughputs from 1.8 to 7 GB, depending on the message size. For e-mail archiving, it is recommended to do a sizing based on an average mail size of 100 KB and calculate with a CommonStore for Lotus Domino archiving throughput of ~15,000 documents per hour or 1.5 GB per hour per archpro instance, unless a significantly larger average mail size is found.

Increasing the number of archpro instances will allow a higher throughput, but will also require more hardware (CPU and memory). As of today, there are configurations known with up to four archpro instances on one multi-processor machine, archiving ~90,000 mails per hour. In such a configuration, it is recommended to parallelize also the transfer directories between CSLD task and archpro (separate directory per task) and have them on a hard disk with fast I/O (and possibly also splitting them up on different drives) to avoid a read/write bottleneck. Note that it is always possible to add a second or third CommonStore server as well to enhance the CommonStore throughput even further.

In general, the number of parallel CM agents should at least match the number of parallel CSLD task threads so that each documented extracted by the CSLD task thread can be immediately archived, without being queued by archpro. If you expect retrieval requests at the same time, it is good practice to start additional CM agents that are then kept busy by the CSLD retrieval tasks. It is also recommended to set the number of Domino dispatchers to the number of CM agents since they are the primary entry point to the CSLD task threads into archpro. This is done by modifying the entry with the keyword DOMINODSP in the archpro configuration file archint.ini. Note that the CommonStore product documentation states a maximum of 30 parallel Domino dispatchers for the Windows platform, driven by Windows threading limitations.

Back to top

Other influencing factors

CommonStore for Lotus Domino comes also with the option that before and/or after archiving of a mail, a Notes agent (written in Lotus Script) within the mailbox is triggered by CSLD and executed on the Domino server. These agents are usually referred to as pre- and post-archiving agents. Their processing adds additional time to the duration of the transaction, depending on the complexity of the actions of the Notes agent. In addition, a Domino server usually executes just a certain number of agents in parallel so that this might become a limiting factor with respect to throughput.

Another (optional) CommonStore feature is the so-called intelligent abstracting where the CSLD task creates a summary of the mail content and puts it into the mail body after archiving. This will also increase the overall duration of an archiving transaction.

If the (optional) single-instance-storage feature is turned on, an additional hash code (based on the mail content and other fields) must be generated. Furthermore, before the CM agent stores the object, it executes a query in the repository if the same hash code has already been stored. Both of these tasks slow down the archiving transaction. On the other hand, if it turns out that the identical message is already archived, the CM agent does not have to transfer the entire message to the CM server, but just needs to update the library to reflect the additional instance of the message.

It has also been observed that starting with CM v8.3 fix pack 1, the time needed by the CM agent in archpro has decreased, thus improving overall performance. Thus it is recommended to upgrade Content Manager to fix pack 1 level at least.

Back to top

Comparing CommonStore for Exchange archiving throughput

Many of the concepts from above apply also to CommonStore to Exchange (CSX). Thus this section will focus just on the differences. CSX comes also with the concepts of CSX tasks with internal threads to parallelize the data extraction from Exchange. Here, however, the MS Extended MAPI is used as programming interface which is available only on MS Windows. As such, CSX must run on MS Windows 2000, XP or 2003 whereas CSLD is also available for AIX.

The data flow for CSX is the same as described in Figure 1. Note, though, that the stubbing or removal of the Outlook item after a successful archiving is asynchronous (whereas it was synchronous in the case of CSLD). The archiving is done by a CSX worker thread, the stubbing is handled by a CSX committer thread. This architecture was chosen to optimize the archiving throughput. Figure 7 shows the CSX administration interface (that can be plugged into a Microsoft Management Console) where the number of parallel CSX worker and committer threads can easily be configured.

This is a major difference compared to CSLD, where the number of parallel threads is rather indirectly determined by the number of job databases, separate databases, or data directories, as shown in Figure 4. Similar to CSLD, it is the crawler component that selects the e-mails to be archived. In the case of CSX, however, these jobs are not stored and processed in the job database or in a job public folder in Exchange, but rather managed internally in the CSX task. This architecture also allows an internal scheduling for processing multiple archiving requests in parallel, avoiding the extra responsibility of the system administrator needing to set up a special configuration for this purpose. When starting the CSX task in a command window, the parallel CSX worker and committer threads are listed as depicted in Figure 8.

Each CSX task connects to exactly one archpro instance. If you have four CM agents activated in archpro, you should have at least four CSX worker and four CSX committer threads configured to have four parallel "pipes" into the repository. Remember that configuring 10 or more CSX threads will not necessarily give a better archiving throughput because archpro would become the bottleneck.

To further increase the archiving performance, it is suggested to configure several CSX tasks, each connected to a separate archpro instance. If you have just one Exchange server, you can have two parallel CSX tasks: task 1(with multiple internal worker and committer threads) can service all user mailboxes whereas task 2 (again multi-threaded) can be dedicated to the one or more journal mailboxes on the same Exchange server. Since the journal mailboxes contain copies of all mails sent and received, the volume of mails to be archived is usually extremely high compared to the user mailboxes. This is the reason why it makes good sense to setup a separate CSX task (with a separate archpro instance) just for the journaled mail.

If you have several Exchange servers, it is possible that the same CSX task services multiple Exchange servers. For performance and operational reasons, it is good practice, though, to run (multi-threaded) CSX tasks dedicated to just one Exchange server. In some environments, for instance, maintenance time windows differ between Exchange servers. If you set up separate CSX tasks, it is then possible to configure different active time periods in the CSX task definition panel.

Since CSX is very flexible when it comes to decide on the number parallel CSX tasks, threads or archpro instances, it is recommended to analyse the number of mail users per Exchange server and the expected archiving volumes up-front. In the case of an Exchange server with 100 users, one task servicing both the journal mailbox and all user mailboxes is definitely going to be sufficient. The same task might even be used to service another Exchange server. In a consolidated environment, with an Exchange server with 4,000 users, for instance, separating the journaling and the mailbox tasks and having two parallel archpro instances is probably necessary to handle the archiving volume in the required time frame.

The overall archiving performance of CSX is lower than in the case of CSLD. This is mainly caused by the fact that a different API is used to extract the mail from the messaging system. We have seen for instance, that the duration of the extraction (and archiving) of a single mail will highly depend on the number of mail recipients. A (mass) mail to 1,000 employees that is sent without using a distribution list (group) in the recipient field, but instead with each name individually, might well take more than 120 seconds, as opposed to a standard mail that is archived in just one second.

For a single-threaded archiving, you can expect to have around 3,000 mails archived per hour. The archiving throughput in a multi-threaded environment (with one task with 4-8 workers, 4-8 committers, and one archpro with 4-8 CM agents) will be around 12,000 mails per hour. Assuming a 20 hour per day processing window, this gives an archiving volume of up to 240,000 mails per day per Exchange server. In order to increase the archiving performance further, you need to add a second CSX task and archpro instance. If run on the same physical box, though, do not expect that a second or third instance will exactly duplicate or triple the throughput of 12,000 mails per hour.

Back to top

Conclusion

Archiving throughput is really the outcome of many single aspects. This article has explained the main factors that influence the overall throughput where the CommonStore throughput is just one of them. To optimize the CommonStore throughput, it is necessary to configure the CommonStore task so that it runs with parallel threads. It is also recommended that you set up separate archpro instances to enhance the throughput even further. Thanks to the powerful IBM Content Manager as backend repository and the flexible configuration options of CommonStore, it is possible to address even high volume e-mail archiving requirements, as often seen in compliance and discovery projects.

Back to top

Disclaimer

This article is written to the best of my knowledge. Should you find any discrepancy, please feel free to contact me.

Resources

• Robert J. Nonnenkamp. Archive Lotus QuickPlace attachments with CommonStore for Lotus Domino. developerWorks, July 2006.
  
  
• Allan Tham, Cengiz Satir and Edward Huang. Comparing IBM DB2 Content Manager family products, Part 2: DB2 CommonStore. developerWorks, February 2006.
  
  
• Reinhold Engelbrecht. Optimize the user interface of DB2 CommonStore or Lotus Domino. developerWorks, November 2005.
  
  
• Reinhold Engelbrecht. DB2 CommonStore and its Backend Archive Options - Understanding the Technical and Functional Differences. developerWorks, November 2003.
  
  
• Babette Haeusser, Alex Osuna, Christian Bosman, Dirk Jahn and Giulio John Tarella. ILM Library: Information Lifecycle Management Best Practices Guide. Redbook, November 2006.
  
  
• Wei-Dong Zhu, Torsten Friedrich, Richard Hogg, Juergen Maletz, Philip McBride and Dean New. E-mail Archiving and Records Management Integrated Solution Guide Using IBM DB2 CommonStore and DB2 Records Manager. Redbook, January 2006.
  
  
• DB2 CommonStore for Lotus Domino and DB2 CommonStore for Exchange Server homepages: Learn more about the products. Find technical documentation, how-to articles, education, downloads, product information, and more.
  
  
• Stay current with developerWorks technical events and Webcasts.
  
  
• developerWorks DB2 Content Management and Discovery zone: Learn more about DB2 Content Management products. Find technical articles, tutorials, downloads, related links, product information, and more.
  
  
• developerWorks Information Management zone: Expand your skills on all the IBM Information management products.
  
  
• Join the ibm.software.content-manager newsgroup and discuss the DB2 Content Manager family (including CommonStore).
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  

About the author

Dr. Reinhold Engelbrecht is a certified technical sales specialist and consultant in the area of Content Management and Discovery. He joined IBM in 1993 and has worked in the field of Content Management since 1997. From 2002 to 2006, he provided worldwide sales support and technical enablement for e-mail and SAP archiving. He is currently the leader for the CM technical community in Northeast Europe. Reinhold holds a bachelor's degree in Mechanical Engineering (Diplom-Ingenieur) and a doctorate from the Technical University of Vienna, Austria, as well as a Master's from Purdue University, USA.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Data flow during archiving
• Single archive transaction duration
• Optimizing CommonStore archiving throughput
• Parallel archiving operations
• Other influencing factors
• Comparing CommonStore for Exchange archiving throughput
• Conclusion
• Disclaimer
• Resources
• About the author
• Comments

Next steps from IBM

• Try: DB2 Enterprise
• Demo: Create an electronic form solution with DB2 pureXML and Lotus Forms
• Community: DB2
• Buy: DB2 Enterprise

Dig deeper into Information Management on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers