performance - streamshare - streamserve

StreamServe Persuasion SP5 Enhancement Pack 1Performance Guidelines

Reference Guide

Rev A

StreamServe Persuasion SP5 Enhancement Pack 1 Performance Guidelines Reference GuideRev A© OPEN TEXT CORPORATIONALL RIGHTS RESERVEDUnited States and other international patents pending

Use of this software program is protected by copyright law, patent law, and international treaties. No part ofthis software product, associated documentation (including online help tools) may be reproduced ortransmitted in any form or by any means, electronic or mechanical, for any purpose, without the expresswritten permission of Open Text Corporation. Information in this documentation is subject to change withoutnotice. Open Text Corporation assumes no responsibility or liability for any errors or inaccuracies that mayappear in this software program. All brands, product names and trademarks of other companies mentionedin this software program are used for identification purposes only and are acknowledged as property of therespective company. Companies, names and data used in examples in this software program are fictitiousunless otherwise noted.

Open Text Corporation offers no guarantees and assumes no responsibility or liability of any type withrespect to third party products and services, including any liability resulting from incompatibility between thethird party products and services and the products and services offered by Open Text Corporation and itsdirect/indirect subsidiaries. By using Open Text Corporation software products and the third party productsor services mentioned in this software product, you agree that you will not hold Open Text Corporation andits direct/indirect subsidiaries responsible or liable with respect to use of such third party products or services.

The trademarks, logos, brands, and service marks found in this software program are the property of OpenText Corporation or other third parties. You are not permitted to use such marks without the prior writtenconsent of Open Text Corporation or the third party that owns the marks.

Use of any Open Text Corporation products or services with any third party products or services notmentioned in this documentation is entirely at your own risk.

3

Contents

Introduction.......................................................................................................5About this document ...........................................................................................6

Profiling the StreamServe environment .........................................................7Enabling the Profiler service ..............................................................................8Configuring processing events ..........................................................................8Configuring the Profiler service .........................................................................9

Profile providers ............................................................................................. 9Filters ........................................................................................................... 11

Example - Analyzing profile output ..................................................................13Measuring web service requests (SSSP).........................................................16

Optimizing StreamServe processing ............................................................17Tuning the input and output queues................................................................18

Enabling asynchronous input directory scanning......................................... 18Storing queued documents on disk.............................................................. 19Tuning the stream cache.............................................................................. 20Tuning asynchronous queuing for output queues........................................ 21

Tuning the service queue..................................................................................22Tuning the service queue for the StreamServer application ........................ 23Tuning the service queue for the Service Gateway ..................................... 24

Optimizing StreamServe post-processing ...................................................25

Optimizing StreamServe repositories...........................................................27Tuning the database connection pools ...........................................................28

Database connection pools, StreamServer and Archiver applications ........ 29Database connection pool, Management Gateway ..................................... 30Database connection pools, Service Gateway............................................. 31Database connection pool, StreamStudio.................................................... 33

Increasing the size of the memory buffer ........................................................34Optimizing the number of threads for an Archiver application.....................36

Optimizing StreamServe web applications ..................................................39Tuning the Service Gateway .............................................................................40

Tuning the thread pool for the Service Gateway.......................................... 40Tuning the keep alive timeout for the Service Gateway............................... 41

Tuning web service properties .........................................................................42Tuning socket and connection timeouts....................................................... 43Load-balancing Service Gateways............................................................... 43Tuning timeouts for failed Service Gateways............................................... 44Tuning connections pools for Service Gateways ......................................... 44Increasing size of the MTOM cache............................................................. 45

StreamServe Persuasion SP5 Enhancement Pack 1 Performance Guidelines Reference Guide Rev A

4

Tuning the preview cache for the SSSP application...................................... 46Allocating memory to StreamServe web applications................................... 47Changing Java Virtual Machine version.......................................................... 48

Appendix A - StreamServe configuration files............................................ 49Editing configuration files ................................................................................ 50

Application specific files............................................................................... 50Template files .............................................................................................. 51Platform configuration files .......................................................................... 52

Configuration files and locations..................................................................... 53Configuration files ........................................................................................ 53Locations of configuration files, Windows.................................................... 54Locations of configuration files, UNIX.......................................................... 56


5Introduction

Introduction

By default, the StreamServe software is designed to ensure well-rounded overall performance related to operating systems, databases, job throughput, response times, and memory consumption.

However, depending on your specific environment and configurations, you may still experience performance issues and system bottlenecks.

Optimization factors

When tuning, typically certain factors are optimized at the expense of others. For example, increasing cache sizes may improve throughput and response times, but at the cost of memory consumption. Compressing files may save disk space, but have a negative impact on performance.

Before tuning your StreamServe environment, you must find out which optimization factors your company prioritizes.

Performance factors

The primary determinant of performance is the configuration and design of the Design Center Project. In general, the more complex configuration, the longer the processing time.

Besides the Project configuration, many other factors also affect performance. Some examples include:

• The operating environment and hardware.

• The format, type, and quantity of input data.

• The number of concurrent users.

• How input data and number of users vary over time.

You must be aware of these performance factors when profiling and tuning the StreamServe environment.

Tuning a StreamServe environment is an ongoing process.

You must continuously monitor the environment to ensure that the system remains within the required performance range. You must identify problems and trends in time and tune the environment accordingly.


6 About this documentIntroduction

About this documentThis document provides tips and recommendations to profile and tune the StreamServe environment.

Out of scope

The following is out of the scope for this document:

• Performance benchmarks and metrics.

• Architectural and hardware recommendations. For this information, see the StreamServe Persuasion SP5 Hardware Guidelines for StreamServer applications, available at OpenText Knowledge Center:

https://knowledge.opentext.com/

• Information about third-party products, such as external profiling tools. For this information, see the user documentation for the related product.

Intended audience

The document is intended for:

• Developers, for example StreamServe Professional Services consultants.

• System administrators.

• Database administrators.

It is assumed that the reader is familiar with the StreamServe software.

Related information

You may find descriptions of possible performance bottlenecks together with suggested solutions in articles and blogs at StreamShare:

http://streamshare.streamserve.com

The tips and recommendations in this document should be considered as starting points for trying out the most optimal settings for the specific environment and configuration.


https://knowledge.opentext.com/knowledge/llisapi.dll/Open/StreamServe

http://streamshare.streamserve.com

7Profiling the StreamServe environment

Profiling the StreamServe environment

When profiling, you investigate how the StreamServe software behaves during processing. The purpose is to determine the most critical performance bottlenecks and the sections that may need optimization.

Profiling is an iterative process that should be done throughout all implementation phases for the Design Center Project. It needs to be revisited as the Project and the requests evolve.

StreamServe Profiler service

Most likely, your company already uses third-party profiling tools and platform specific commands to profile the environment.

As a complement, you can use the StreamServe Profiler service for the StreamServe related parts. The Profiler service enables you to monitor and measure times for the following:

• Processing events, such as collecting, preprocessing, and processing data.

• Database invocations to and from the StreamServe repositories.

• Web service requests to and from the Service Gateway.

• Cache service operations (mainly for ADEP Designer Processes).

In this section

• Enabling the Profiler service on page 8.

• Configuring processing events on page 8.

• Configuring the Profiler service on page 9.

• Example - Analyzing profile output on page 13.

• Measuring web service requests (SSSP) on page 16.

When profiling, you should always strive to use real data. In a test environment, you should use data and volumes that resemble production data as closely as possible.

Since logging affects performance, it is recommended to minimize the logging.


8 Enabling the Profiler serviceProfiling the StreamServe environment

Enabling the Profiler serviceYou must enable the Profiler service for each application (StreamServer, Archiver, Task Scheduler, or Service Gateway) that you want to profile.

After you enable the Profiler service, all profile data is handled by the Profiler service and presented in the profile output.

To enable the Profiler service

1 In Control Center, select the application to profile.

2 In the Properties view, enable the Profiler property.

3 Restart the application.

Configuring processing eventsAfter you enable the Profiler service for a StreamServer application, you must specify the processing events to profile.

Specifying processing events

You can measure how long it takes to process certain individual events. For example, collecting, preprocessing, and processing data. To do this, you use the -timer startup argument together with dedicated timers. For more information, see the Startup arguments documentation in OpenText StreamServe Online Help.

Note: When the Profiler service is enabled, the StreamServer application does not use the “Write to file” timer (hex value 0X80).

Specifying processing flows

As an alternative to profiling separate events, you can measure the execution time for a longer processing flow. To do this, you use the StartTimer and StopTimer scripting functions. For more information, see the Scripting reference documentation in OpenText StreamServe Online Help.

Profiling affects StreamServe processing performance.

In a production environment, you should disable the Profiler service.


Configuring the Profiler service 9Profiling the StreamServe environment

Configuring the Profiler serviceThe Profiler service is configured in the profilerservice.xml file.

You can update the default configuration. For example, you can:

• Specify a profile provider that suits an external tool that you want to use to analyze the profile output.

• Configure filters to make the output less comprehensive.

Common or application-specific file

You can either:

• Update the common profilerservice.xml file, applicable for all profile-enabled applications.

• Copy the file to the working directory of a specific application and apply updates to this application only (recommended).

For file location, see Appendix A - StreamServe configuration files on page 49.

To configure the Profiler service

1 Open the profilerservice.xml file.

2 Configure the profile providers. See Profile providers below.

3 Configure the filters. See Filters on page 11.

4 Save and close the file.

5 Restart the application(s).

Profile providersA profile provider provides an interface between the Profiler service and the tool in which you intend to analyze the profile output. By default, a profiler.data file is generated in the working directory of each profiler-enabled application.

Properties and delimiters

Eight properties are available for each profiled event, see Event properties on page 10. By default, all these properties are presented in the profile output, using commas (,) as delimiters.

In the profilerservice.xml file, you can use the messageformat attribute to limit the properties in the profile output and to specify other delimiters. See Example 1 on page 10.

Note: The delimiters must match the tool in which you intend to analyze the profile output.


10 Configuring the Profiler serviceProfiling the StreamServe environment

Event properties

Example 1 Profile provider configuration

In this example, a profiler.data file is generated in the working directory. In the file, a limited number of properties are presented and # is used as delimiter.

<provider value="http://schemas.streamserve.com/uid/component/fileprofilerprovider/1.0"> <configuration> <fileprofilerprovider xmlns="http://schemas.streamserve.com/ uid/component/fileprofilerprovider/1.0"> <provider name="http://schema.streamserve.com/uid/ resource/fileprofilerprovder/logfile/1.0" messageformat="%2#%4#%5#%6#%7#%8"> <configuration> <providers xmlns="http://schemas.streamserve.com/ uid/manager/logmanager/1.0"> <provider name="http://schema.streamserve.com/ uid/resource/fileprofilerprovder/logfile/ 1.0" type="http://schema.streamserve.com/ uid/component/filelogprovider/1.0" default="no" source="profiler.data" codepage="UTF-8" msginfo="0" sizelimit="10" savepath="." delete="no" asynchronous="yes"/> </providers> </configuration> </provider> </fileprofilerprovider> </configuration></provider>

Property Description

%1 The UID (Unique IDentifier) for the event in numeric format.

%2 The UID for the event in string format.

%3 The UID for the event namespace in numeric format.

%4 The UID for the event namespace in string format.

%5 The context of the event.

%6 The ID of the thread that generated the event.

%7 The timestamp when the event was executed.

%8 The elapsed time for the event (in milliseconds).


Configuring the Profiler service 11Profiling the StreamServe environment

FiltersBy default, all measured profile events are presented in the profile output, which results in a comprehensive list. You can apply filters to limit the number of events that are passed down to the profile provider and included in the profile output.

Namespaces

You can filter on the following namespaces and their sub-events:

• streamserve.notification.streamserver.profiler.profilerevent.

timer – Contains information about profiled processing events configured using the -timer startup argument.

• streamserve.notification.streamserver.profiler.profilerevent.

timer.custom – Contains information about profiled processing events configured using the StartTimer and StopTimer scripting functions.

• streamserve.notification.profiler.profilerevent.repositoryconnec

tionprovider – Contains information about database invocations to and from StreamServe repositories

• streamserve.notification.servicegateway.profiler.profilerevent

– Contains information about web service requests to and from the Service Gateway.

• streamserve.notification.profiler.profilerevent.cacheservice – Contains information about cache service operations (mainly for ADEP Designer Processes).

Namespace filter syntax

In the profilerservice.xml file, you can add one or more filter elements, each containing one or more namespace filter configurations. Use the following syntax to combine the appropriate filters:

• include – Includes information from the namespace in the profile output. Use * to include all namespaces, except the ones excluded.

• exclude – Excludes information from the namespace in the profile output. Use * to exclude all namespaces, except the ones included.

See Example 2 on page 12.


12 Configuring the Profiler serviceProfiling the StreamServe environment

Example 2 Filter configuration

The filter below includes information in the profile output about all profiled processing events configured using the -timer startup argument. All operations from other namespaces are excluded.

<filters> <filter type="http://schemas.streamserve.com/uid/resource/ profilerservice/namespacefilter/1.0"> <configuration> <namespacefilters xmlns="http://schemas.streamserve.com/ uid/resource/profilerservice/namespacefilter/1.0"> <namespacefilter type="include"> streamserve.notification.streamserver.profiler. profilerevent.timer</namespacefilter> <namespacefilter type="exclude">*</namespacefilter> </namespacefilters> </configuration> </filter></filters>


Example - Analyzing profile output 13Profiling the StreamServe environment

Example - Analyzing profile outputYou can use a third-party tool to analyze the profile output. For example, you can import the output into a Microsoft Excel spreadsheet, or you can create a repository and analyze the output via the Database Management System.

This section gives an example of how to create a dedicated repository on Microsoft SQL Server, import the profile output into this repository, and finally analyze the output by running SQL queries against the repository.

Figure 1 Profile output analyzed in Microsoft SQL Server Management Studio

Example prerequisites

• The Profiler service is enabled for the StreamServer application.

• The -timer startup argument is used to measure the time for processing (hex value 0x08).

• The profile provider and filter are configured according to:

– Example 1 on page 10.

– Example 2 on page 12.

• Some typical jobs are run.

• The StreamServer application is stopped.


14 Example - Analyzing profile outputProfiling the StreamServe environment

To create a profile database in SQL Server

1 Open Microsoft SQL Server Management Studio and connect to the host.

2 Create a new repository called StrsProfiler.

3 Run the following SQL query to create the database tables:

Note: The tables in the query above match the event properties configured for the profile provider. See Example 1 on page 10l.

To load the profile data into the profile database

1 Run the following SQL query to load the profile output from the profile.data file into the new StrsProfiler repository:

Note: The FIELDTERMINATOR in the query matches the delimiter configured for the profile provider. Example 1 on page 10.

USE [StrsProfiler]GO

/****** Object: Table [dbo].[ProfilerData] Script Date: 09/29/2011 08:01:23 ******/SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOSET ANSI_PADDING ONGOCREATE TABLE [dbo].[ProfilerData]( [EventID] [varchar](max) NULL, [EventNamespaceID] [varchar](max) NULL, [Context] [varchar](max) NULL, [ThreadID] [int] NULL, [Timestamp] [datetime] NULL, [ElapsedTime] [decimal](18, 3) NULL) ON [PRIMARY]GOSET ANSI_PADDING OFFGO

BULK INSERT ProfilerData FROM 'C:\ManagementGateway\1.0\root\applications\StreamServer\DEV\profiler.data' WITH ( FIELDTERMINATOR = '#', ROWTERMINATOR = '\n' ) GO


Example - Analyzing profile output 15Profiling the StreamServe environment

To analyze the profile data in the DBMS

Retrieve and analyze the profile output by running SQL queries against the StrsProfiler repository.

For example:

For an example of a possible result of the analysis, see Figure 1 on page 13.

--Processing times in max -> min order.

SELECT Context, Timestamp, ElapsedTime FROM [dbo].[ProfilerData]WHERE EventID = 'streamserve.notification.streamserver. profiler.profilerevent.timer.processing'ORDER BY ElapsedTime DESC

--Processing times in timestamp order.

SELECT Context, Timestamp, ElapsedTime FROM [dbo].[ProfilerData]WHERE EventID = 'streamserve.notification.streamserver. profiler.profilerevent.timer.processing'ORDER BY Timestamp ASC

--Average Time spent processing.

SELECT AVG( ElapsedTime ) AS 'Average Processing in MS' FROM [dbo].[ProfilerData]WHERE EventID = 'streamserve.notification.streamserver. profiler.profilerevent.timer.processing'

--Min time spent processing.

SELECT MIN( ElapsedTime ) AS 'Min Processing in MS' FROM [dbo].[ProfilerData]WHERE EventID = 'streamserve.notification.streamserver. profiler.profilerevent.timer.processing'

--Max time spent processing.

SELECT MAX( ElapsedTime ) AS 'Max Processing in MS' FROM [dbo].[ProfilerData]WHERE EventID = 'streamserve.notification.streamserver. profiler.profilerevent.timer.processing'


16 Measuring web service requests (SSSP)Profiling the StreamServe environment

Measuring web service requests (SSSP)The StreamServe Service Provider (SSSP) application contains the business logic for Ad Hoc Correspondence, Correspondence Reviewer, and the Document Broker Query Tool.

You can generate a report about the response times for web service requests between the SSSP application and the Service Gateway. The web service requests are measured at the SSSP application.

You can compare this report with the corresponding output from the Profiler service. The web service requests are then measured at the Service Gateway. If there are notable differences between the results, this indicates latency and bottlenecks in the network.

To generate a report with web service requests

1 Open the following file:

<Portal root>\sssp\WEB-INF\spring\application-context.xml

For example, for Apache Tomcat:

<TOMCAT_HOME>\webapps\sssp\WEB-INF\spring\application-context.xml

2 Uncomment the following element:



3 Restart the Java application server and run a few typical jobs.

4 Use the following URL to generate and access the report:

http://<Host>:<Port>/sssp/perfmon/report

5 Reload the URL to update the report.

17Optimizing StreamServe processing

Optimizing StreamServe processing

The complexity and configuration of the Design Center Project affects the StreamServe processing time. In general, the more complex configuration, the longer the processing time.

For example, for a StoryTeller Process, the size and complexity of the document design (fonts, images, business graphics, scripted layout rules, etc.) affect the processing time. When the document is delivered to the output destination, the format and structure of the output data, including the driver type and driver settings impact performance. Any handling of variables, metadata, post-processing, and ODBC database calls are added to the overall processing time.

Note: Always consult the OpenText StreamServe Online Help for information about how a certain configuration or function affects performance.

In this section

• Tuning the input and output queues on page 18.

• Tuning the service queue on page 22.

Use clones when trying out settings

You can create clones of your site or application domains and use these clones to try out the most optimal settings for your specific environment. Using clones enables you to try out the settings in different sets of pre-configured applications domains.

For more information, see StreamServe Persuasion SP5 Enhancement Pack 1 Reference Guide > Transport and migration. The document is available at OpenText Knowledge Center.


18 Tuning the input and output queuesOptimizing StreamServe processing

Tuning the input and output queuesIn this section

• Enabling asynchronous input directory scanning on page 18.

• Storing queued documents on disk on page 19.

• Tuning the stream cache on page 20.

• Tuning asynchronous queuing for output queues on page 21.

Enabling asynchronous input directory scanningBy default, a Directory input connector scans the input folder synchronously. The connector runs in single-threaded mode and retrieves the files one by one from the input folder.

You can disable synchronized scanning and instead scan the input folder asynchronously. The input connector then runs in multi-threaded mode and retrieves several files in parallel.

Recommendations and tips

• If you expect many small input jobs, you may increase the job throughput if you run the input connector asynchronously.

• Running one input connector asynchronously is often more efficient than running multiple input connectors synchronously.

When not to use asynchronous directory scanning

• If you expect large batches of input jobs, delivered to the input folder one by one, asynchronous scanning will not enhance performance.

• If you use Microsoft SQL Server and use more than one Directory input connector in the application domain, asynchronous scanning may not enhance performance. For example, if you share queues between several StreamServer applications and the hardware or the database server cannot handle the extra load of the asynchronous scanning.

Related topics

For information on how to disable synchronized scanning, see the Design Center documentation in OpenText StreamServe Online Help.

Running asynchronously means that several files are pushed into the input queue in parallel, which increases the load on the queue.

The runtime repository must be able to handle the extra load. If not, asynchronous scanning may result in resource contention and lower job throughput.


Tuning the input and output queues 19Optimizing StreamServe processing

Storing queued documents on diskDocuments in input and output jobs are by default stored as blobs (Binary Large Objects) in the queues in the runtime repository.

For each queue, you can choose to store the blobs as files on disk instead. The runtime repository then includes references to the blobs instead of the actual data.

Recommendations

• If you expect large blobs, you might increase job throughput and decrease resource consumption by storing the blobs on disk. The cost of the extra disk space must be weighed against the resource consumption of the StreamServe software and the database software.

• If you store blobs on disk, it is recommended to back up the blobs.

When not to store blobs on disk

• If several StreamServer applications share queues.

• If you want to use StreamStudio Reporter to resend or delete jobs.

• If you want to use StreamStudio Collector.

Related topics

For information on how to enable and configure blobs on disk, see the Design Center documentation in OpenText StreamServe Online Help.


20 Tuning the input and output queuesOptimizing StreamServe processing

Tuning the stream cacheBy default, the StreamServe input and output queues use stream caches for storing blob data in temporary data streams. Each queue has its own stream cache. The stream cache reduces the number of database readings from the runtime repository when the same StreamServer application both queues and processes a job.

By default, up to 50 data streams can be cached per queue. The cache timeout (how long blob data remains in the cache before being expired) is 5 seconds.

Recommendations

• If the StreamServer application does not fully utilize the stream cache, you might decrease the memory and resource consumption by reducing the number of cached data streams. You reduce the number of cached streams using the -streamcache startup argument.

• If several StreamServer applications share queues, one application may queue a job and another application may process the job. A cache miss is introduced and the data must be retrieved from the runtime repository instead. To avoid this, you can do one of the following:

– Reduce the cache timeout via the -streamcachetimetolive <time> argument until a sufficient hit ratio is achieved.

– Disable the stream cache using the -disablestreamcache argument.

– Enable effective usage of the stream cache via the –alternativequeuing argument. After queuing a job, the same StreamServer application immediately tries to process the job.

Related topics

For more information about the -streamcache, -disablestreamcache, and –alternativequeuing arguments, see the Startup arguments documentation in OpenText StreamServe Online Help.


Tuning the input and output queues 21Optimizing StreamServe processing

Tuning asynchronous queuing for output queuesBy default, asynchronous queuing is enabled for all output queues. Asynchronous queuing may increase performance if most of your input jobs generate many output jobs.

By default, a maximum of 10 concurrent asynchronous requests is allowed for each input job. Each request writes one output job to the output queue.

Recommendations

• If an average input job creates too much load on the output queue or if several highly loaded output queues are handled simultaneously, you might increase database performance and job throughput by reducing the number of asynchronous requests. You reduce the number of requests using the -asynchronqueue startup argument.

• If most of the input jobs generate a single output job, it is recommended to disable asynchronous queuing using the -disableasynchronqueuing argument. By disabling asynchronous queuing, the processing job writes all output jobs in sequential order to the output queue.

Related topics

For information about the -asynchronqueue and -disableasynchronqueuing arguments, see the Startup arguments documentation in OpenText StreamServe Online Help.

Running asynchronously means that several files are pushed into the output queue in parallel, which increases the load on the queue.

The runtime repository must be able to handle the extra load. If not, asynchronous scanning may result in resource contention and lower job throughput.


22 Tuning the service queueOptimizing StreamServe processing

Tuning the service queueIf the Design Center Project includes service-enabled Messages or Service Request input connectors, a service queue is used as an input queue. By default, this is a shared queue for which scheduled spooling is enabled.

Both the StreamServer application and the Service Gateway access the service queue.

In this section

• Tuning the service queue for the StreamServer application on page 23.

• Tuning the service queue for the Service Gateway on page 24.

Configuring a Rule resource for a service-enabled Message affects Message runtime performance.


Tuning the service queue 23Optimizing StreamServe processing

Tuning the service queue for the StreamServer application

Each service request can be seen as a separate job stored in the service queue. By default, the StreamServer application polls the service queue for new jobs every second. When the StreamServer application finds some jobs, five threads are invoked simultaneously for parallel processing of the jobs.

You can edit the polling interval and the number of threads used by the application in the repositorymanager.xml file for the StreamServer application.

Recommendations

If you expect a large number of concurrent service requests, you might:

• Enhance formatting performance by increasing the number of threads and editing the default spooling interval.

Note: Each thread consumes system resources.

• Avoid performance bottlenecks related to the runtime repository by setting up several StreamServer applications that poll the same service queue.

To tune the service queue for the StreamServer application

1 Open the repositorymanager.xml file for the application. For information and location, see Appendix A - StreamServe configuration files on page 49.

2 Edit the following elements:

<queues> <servicequeue> <queueservice> ... </queueservice> <resourceservice> ... </resourceservice> <schedule>T II * * S * * 1</schedule> <threadpool min="5" max="5" /> </servicequeue></queues>

Note: You must use the same value for the minimum and the maximum number of threads in the thread pool. For example, <threadpool min="10" max="10" />


4 Restart the StreamServer application.


24 Tuning the service queueOptimizing StreamServe processing

Tuning the service queue for the Service GatewayThe Service Gateway polls the service queue for completed jobs.

The time interval at which the Service Gateway polls the service queue (by default, 500 ms) is specified in the repositorymanager.xml configuration file for the Service Gateway. By default, a maximum of 20 threads can be used when polling the queue for completed jobs.

Recommendations

• If the processing time for the StreamServer application is less than 500 ms, you may enhance performance by decreasing the time interval at which the Service Gateway polls the service queue.

• If you expect a large number of concurrent service requests, you may avoid performance bottlenecks related to the runtime repository by:

– Increasing the time interval at which the Service Gateway polls the service queue.

– Decreasing the maximum number of threads to be used. For example, to 5 threads.

To tune the polling interval and the number of threads

1 Open the repositorymanager.xml file for the Service Gateway. For information and location, see Appendix A - StreamServe configuration files on page 49.

2 Edit the time interval (ms) at which the Service Gateway application polls the service queue in the following element:

<service ...> ... <configuration type=...> <executeRemoteService xmlns=...> <checkResultFrequency>500</checkResultFrequency> <onTimeOut> ... </onTimeOut> <accessServiceName> ... </accessServiceName> </executeRemoteService> </configuration></service>

3 Add the following element to the <executeRemoteService ...> element to specify how many concurrent threads to be used when checking the job status:

<concurrentStatusThreads><Number_Of_Threads></concurrentStatusThreads>

Where <Number_Of_Threads> is the number of threads to be used. For example, 5


5 Restart the Service Gateway.

25Optimizing StreamServe post-processing

Optimizing StreamServe post-processing

This section contains tips for optimizing performance in a post-processing scenario.

Sheet layout, OMR, and labels

• Apply sheet layout, OMR, and labels on the highest possible level (where job is the highest level and page is the lowest level).

Scripts

• Apply scripts on the highest possible level (where job is the highest level and inside a Process – for example, on a block – is the lowest level).

Post-processor with multiple calls

• If a script gives input to another script in a sorting or bundling scenario, it is recommended to first calculate the required input and then ignore the remaining Process using the NextSegment, NextDoc, NextProc, or NextPage scripting function. Use the function on the highest possible level (where segment is the highest level and page is the lowest level).

PPQ (Post Processor Query)

• If possible, query one single document type at a time.

Metadata guidelines – Document Broker for FastObjects

• Do not use more metadata than needed.

• Limit the number of metadata updated by scripts.

• Use the DeclareMetadata scripting function for all metadata that is exclusively accessed from scripts (that is, not only for metadata used for enveloping and sorting).

• Consider indexing metadata that is frequently used for document selection. This is especially important when a small amount of documents is selected out of a larger set.

If a table is subjected to lots of inserts, increasing the number of indexes may have negative impact on the insert performance.


26Optimizing StreamServe post-processing

Metadata guidelines – Document Broker Plus

• Do not use more metadata than needed and do not use the Post-processing context (in the Document Type Editor in Design Center) unless necessary.

• Limit the number of metadata updated by scripts.

• For Projects that require metadata updates, you can use the following script functions to cache metadata updated by the Save<xx>Metadata functions:

– PPBeginDocMDUpdate

– PPCommitDocMDUpdate

– PPRollbackDocMDUpdate

For more information, see StreamServe Persuasion SP5 Enhancement Pack 1, Reference Guide, available at OpenText Knowledge Center.

• Consider indexing metadata that is frequently used for document selection. This is especially important when a small amount of documents is selected out of a larger set.

• Make sure database indexes and statistics are properly maintained.

For more information, see:

StreamServe Persuasion SP5 Microsoft SQL Server, Database Guidelines

StreamServe Persuasion SP5 Oracle Database, Database Guidelines

StreamServe Persuasion SP5 Enhancement Pack 1, IBM DB2, Database Guidelines

The documents are available at OpenText Knowledge Center:

If a table is subjected to lots of inserts, increasing the number of indexes may have negative impact on the insert performance.


27Optimizing StreamServe repositories

Optimizing StreamServe repositories

Database performance is largely dependent on the tuning and maintenance of the StreamServe repositories. For example, by indexing columns in the runtime repository and in the StreamServe archive, you may improve the speed of the data retrieval operations. By optimizing the way in which expired top jobs are deleted from the runtime repository, you may improve the delete performance.

For information about tuning and maintenance, see:

StreamServe Persuasion SP5 Microsoft SQL Server, Database Guidelines

StreamServe Persuasion SP5 Oracle Database, Database Guidelines

StreamServe Persuasion SP5 Enhancement Pack 1 IBM DB2 Database Guidelines

The documents are available at OpenText Knowledge Center.

In this section

• Tuning the database connection pools on page 28.

• Increasing the size of the memory buffer on page 34.

• Optimizing the number of threads for an Archiver application on page 36.


28 Tuning the database connection poolsOptimizing StreamServe repositories

Tuning the database connection poolsA StreamServe application uses a database connection to communicate with the database server. The application takes an available connection from a connection pool, executes the database commands, and returns the connection to the pool.

By default, each application allocates a number of connections. It is recommended to tune these default connections to fit the actual conditions.

For example, you may increase throughput by increasing the number of database connections in the connection pool for a StreamServer application. While doing so, you must be aware of the consequences. For example, allocating too many connections may have negative impact on the database performance, because you would have potential waits due to contention. If Microsoft SQL Server is used, an increased number of connections may result in deadlocks.

In this section

• Database connection pools, StreamServer and Archiver applications on page 29.

• Database connection pool, Management Gateway on page 30.

• Database connection pools, Service Gateway on page 31.

• Database connection pool, StreamStudio on page 33.

Any tuning of the database connection pools affects performance.


Tuning the database connection pools 29Optimizing StreamServe repositories

Database connection pools, StreamServer and Archiver applications

A StreamServer application uses a connection pool to access the runtime repository. An Archiver application uses a connection pool to access the StreamServe archive.

By default, the maximum number of connections in each pool is set to 25, allowing temporary growth if needed. You can edit the number of connections in the repositorymanager.xml file for each application.

Recommendations

• It is recommended to deny temporary growth (that is, change the allowtemporaryobjects="true" attribute to "false").

• If multiple threads are configured for the queues in the Design Center Project, you may increase throughput by increasing the number of database connections for the StreamServer application.

Note: Allocating too many connections may have negative impact on the database performance, because you would have potential waits due to contention. If Microsoft SQL Server is used, an increased number of connections may result in deadlocks.

• If a background event is not used (for example, if you run several jobs and configure the event for the database instead), you can remove the background event from the repositorymanager.xml file and decrease the number of database connections.

• The maximum number of connections should be 10 or more.

To tune the connection pool in repositorymanager.xml

1 Open the repositorymanager.xml file for the application. For information and location, see Appendix A - StreamServe configuration files on page 49.

2 Edit the following element:

<objectpools> <objectpool type=...> <configuration> <objectpoolex xmlns=...> <general min="0" max="25" allowtemporaryobjects="true" /> </objectpoolex> </configuration> </objectpool></objectpools>


4 Restart the application.



Database connection pool, Management GatewayControl Center connects to StreamServe Enterprise Repository via the Management Gateway. The Management Gateway uses a connection pool to access the enterprise repository.

By default, the maximum number of connections in the pool is set to 25, allowing temporary growth if needed. You can edit the number of connections in the mgw-repositorymanager.xml file.

Recommendations


• If the number of Control Center users that access the Management Gateway simultaneously (deploying Design Center Projects, starting and stopping applications, etc.) is low, you can decrease the number of database connections.


To tune the connection pool in mgw-repositorymanager.xml

1 Open the mgw-repositorymanager.xml file. For information and location, see Appendix A - StreamServe configuration files on page 49.






Database connection pools, Service GatewayThe Service Gateway handles web services requests from clients to the StreamServe repositories. For example, from the StreamStudio portal to the runtime repository and the StreamServe archive, and from the SSSP application, to the runtime repository and the Document Broker repository.

You can edit the number of database connections for the Service Gateway in the following files:

• repositorymanager.xml for the Service Gateway.

• securitymanager.xml.

Connection pool in repositorymanager.xml

By default, the maximum number of database connections in the pool is set to 25, allowing temporary growth if needed.

Recommendations



To tune the connection pool in repositorymanager.xml

1 Open the repositorymanager.xml file for the Service Gateway. For information and location, see Appendix A - StreamServe configuration files on page 49.







Connection pool in securitymanager.xml

The Service Gateway can access the runtime repository in order to validate StreamStudio settings, for example StreamStudio user roles. When accessing the runtime repository for such reasons, the Service Gateway uses a dedicated connection pool.

By default, the maximum number of connections in the pool is set to 20, allowing temporary growth if needed. You can edit the number of connections in the securitymanager.xml file.

Recommendations


• If the Design Center Project includes script functions for checking users, or if the Project is configured to validate senders and/or receivers, you can tune the connection pool in accordance with the number of concurrent StreamStudio users. For example, if you expect few users, you can decrease the number of database connections.


To tune the connection pool in securitymanager.xml

1 Open the securitymanager.xml file. For information and location, see Appendix A - StreamServe configuration files on page 49.


<objectpools> <objectpool type="http://schemas.streamserve.com/uid/ component/objectpoolex/1.0" name="http:// schemas.streamserve.com/ uid/resource/connectionpool/repository"> <configuration> <objectpoolex xmlns=...> <general min="0" max="20" allowtemporaryobjects="true" /> </objectpoolex> </configuration> </objectpool> ...</objectpools>





Database connection pool, StreamStudioThe following StreamStudio applications can access a StreamServe repository directly, without passing the Service Gateway:

• StreamStudio Reporter – Accesses the runtime repository.

• StreamStudio Administrator – Accesses the runtime repository.

• StreamStudio Composition Center – Accesses the web content repository.

When a repository is accessed directly from StreamStudio, the number of database connections is specified in the datasources.xml file for the StreamStudio portal. By default, the maximum number of connections in the pool is set to 20.

Each database server uses one pool. The pool is shared by all StreamStudio applications accessing the database server. Since the connections are used only when they are needed, the pool starts empty.

Recommendations

• If you expect many concurrent StreamStudio users, you can increase the number of connections.

• The number of connections should be 20 or more.

To tune the connection pool in datasource.xml

1 Open the datasources.xml file, located in:

<Portal name>\WEB-INF\spring


<TOMCAT HOME>\webapps\<Portal name>\WEB-INF\spring

2 Edit the following element in the datasources.xml file:

<property name="maxActiveJdbcConnections" value="20" />



34 Increasing the size of the memory bufferOptimizing StreamServe repositories

Increasing the size of the memory bufferDuring processing, a StreamServer application produces a number of temporary files. For example, files with blob data, stream caches, and settings for output jobs.

As long as the size of a single temporary file is less than the size of the memory buffer, the StreamServer application keeps the file in memory. If the file size exceeds the buffer size, the file is stored to disk.

By default, the size of the memory buffer (bufferKBsize) is 150 kB. The buffer pool is set to 200. A buffer from the pool remains allocated after the temporary file is released and can be reused by other files. If the buffer pool is exhausted, temporary buffers, which are not reusable, are created.

Prerequisites and recommendations

• If the sizes of the template files are larger than the buffer size, you may enhance performance by increasing the size of the memory buffer.

• The buffer size should be equal to (or slightly larger than) the size of the majority of the template files, rather than the maximum size of a single file.

• The buffer size times the buffer pool must not exceed the available memory.

Note: The memory consumption of the buffers is added to the ordinary memory consumption of the StreamServer application execution process.

Note: Because StreamServer is a 32-bit application, the maximum available memory is somewhat limited. For details, see the user documentation for your platform. Exception – On HP-UX IA-64 platforms, StreamServer runs as a 64-bit application with considerably more available memory.

Decreasing memory usage per process

To decrease the memory usage (provided there is enough memory available within the system), you may consider:

• Splitting up the execution process on several StreamServer applications.

• Decreasing the size of the Events in the input data.


Increasing the size of the memory buffer 35Optimizing StreamServe repositories

To increase the size of the temporary buffer

1 Open the iomanager.xml file for the StreamServer application. For information and location, see Appendix A - StreamServe configuration files on page 49.

2 Edit the following elements:

<manager type=...> <configuration> <iomanager xmlns=...> <temporarystream bufferKBsize="150"> <objectpool type=...> <configuration> <objectpool xmlns=...> <general min="1" max="200" allowtemporaryobjects="true" /> </objectpool> </configuration> </objectpool> </temporarystream> </iomanager> </configuration></manager>


4 Restart the StreamServer application.


36 Optimizing the number of threads for an Archiver applicationOptimizing StreamServe repositories

Optimizing the number of threads for an Archiver application

By optimizing the number of threads used by an Archiver application, you may enhance insert performance for the following repositories:

• StreamServe archive

• OpenText Content Server

• OpenText Archive Server

You edit the number of threads in:

• archiver.config.xml – Number of threads for the Archiver application.

• threadmanager.xml – Common thread pool for all applications.

If the Archiver application uses all the threads in the common thread pool, no threads are available for other Service Component Framework activities, such as logging etc.

Recommendations

• It is recommended to have at least one thread (preferably several threads) available in the common thread pool. To achieve this, the number of threads for the Archiver application (in archiver.config.xml) should be less than the number of threads in the common thread pool (in threadmanager.xml).

• The optimal number of threads for the Archiver application depends on the database server performance.


To optimize the number of threads

1 Open archiver.config.xml for the Archiver application, located in:

<Base directoy>\root\applications\<Archiver application>\wd

2 Increase the number of threads in the following element:

<tasks> ... <advanced> <num_docs>...</num_docs> <segmentsize>...</segmentsize> <threads>10</threads> </advanced> ...</tasks>

3 Open threadmanager.xml for the Platform. For information and location, see Appendix A - StreamServe configuration files on page 49.


Optimizing the number of threads for an Archiver application 37Optimizing StreamServe repositories


<threadmanager ...> <dispatchqueues> <dispatchqueue ...> ... </dispatchqueue> <dispatchqueue type="http://schemas.streamserve.com/uid/ component/dispatchqueue/1.0" name="http://schemas. streamserve.com/uid/resource/iodispatchqueue/1.0"> <configuration> <threadpool min="12" max="12"/> </configuration> </dispatchqueue> </dispatchqueues></threadmanager>

5 Save and close the files.


38 Optimizing the number of threads for an Archiver applicationOptimizing StreamServe repositories


39Optimizing StreamServe web applications

Optimizing StreamServe web applications

The StreamStudio web portal contains the StreamStudio web applications, such as Composition Center, Collector, and Reporter.

In addition to the StreamStudio portal, the StreamStudio setup also includes two plug-in web applications – Ad Hoc Correspondence and Correspondence Reviewer. These clients make their web service requests via an SSSP application.

The SSSP application is also used by the Document Broker Query (DBQ) Tool to collect documents from a Document Broker repository. The DBQ Tool is installed with Enhancement Pack 1 or any of the subsequent SP5/EP1 hotfixes.

The StreamStudio portal and the SSSP application run on Java application servers and access the related repositories using web services, hosted by the Service Gateway.

In this section

• Tuning the Service Gateway on page 40.

• Tuning web service properties on page 42.

• Tuning the preview cache for the SSSP application on page 46.

• Allocating memory to StreamServe web applications on page 47.

• Changing Java Virtual Machine version on page 48.

Related topics

• Tuning the service queue on page 22.

Related information

For performance recommendations when using the StreamServe Persuasion SDK (Software Development Kit) to build customized solutions, see the StreamServe Persuasion SP5 Web Service API Programming Guide.

The document is included in the StreamServe Persuasion SP5 SDK, available at OpenText Knowledge Center.


40 Tuning the Service GatewayOptimizing StreamServe web applications

Tuning the Service GatewayThe Service Gateway handles web services requests from clients to the StreamServe repositories. For example, from the StreamStudio portal to the runtime repository and the StreamServe archive, and from the SSSP application, to the runtime repository and the Document Broker repository.

You might enhance the response times by tuning the Service Gateway.

In this section

• Tuning the thread pool for the Service Gateway on page 40.

• Tuning the keep alive timeout for the Service Gateway on page 41.

Related topics

For information about how to tune the database connection pools for the Service Gateway, see Database connection pools, Service Gateway on page 31.

Tuning the thread pool for the Service GatewayThe number of threads used by the Service Gateway for web service requests is configured in the threadmanager.xml configuration file for the gateway. Using several threads enables parallel processing of the service requests.

Recommendations

If you expect a large number of concurrent service requests, you might enhance response times by increasing the number of threads. For example, if you expect 100 concurrent requests, you can increase the thread pool to 100.


To tune the thread pool

1 Open the threadmanager.xml file for the Service Gateway. For location, see Appendix A - StreamServe configuration files on page 49.


<threadmanager ...> <dispatchqueues> <dispatchqueue ...> ... </dispatchqueue> <dispatchqueue type="http://schemas.streamserve.com/uid/ component/dispatchqueue/1.0" name="http://schemas. streamserve.com/uid/resource/iodispatchqueue/1.0"> <configuration> <threadpool min="20" max="20"/> </configuration> </dispatchqueue> </dispatchqueues></threadmanager>




Tuning the Service Gateway 41Optimizing StreamServe web applications

Tuning the keep alive timeout for the Service GatewayThe Service Gateway can reuse one connection for several web service requests, meaning that a new connection does not have to be established for each request. This is especially important when running the SSSP application.

A connection is held open until the keep alive timeout (by default, 1 second) is reached. If there is no new inbound traffic during this time, the connection is closed down.

Prerequisites and recommendations

• The clients accessing the Service Gateway must support keep alive.

• If the expected time periods between the service requests are larger than 1 second you should increase the keep alive timeout.

Note: A timeout consumes the thread that keeps the connection open.

• If you expect a large number of concurrent service requests, you might benefit from disabling the keep alive timeout if one of the following applies:

– The clients are not handling keep alive correctly, that is are not reusing connections for subsequent requests.

– A large amount of different, individual, concurrent clients are used.

– You experience thread starvation.

To increase the keep alive timeout for the Service Gateway

1 Open the semper.xml file. For information and location, see Appendix A - StreamServe configuration files on page 49.

2 Increase the timeout in the following element:

<soaplistener xmlns=...> <interface port="27180" name="*" backlog="100" reuseaddr="false"/> <timeout read="60" write="60"/> <keepalive max="100" timeout="1"/>  </soaplistener>



Related topics

For information about the security properties in the semper.xml file, see the StreamServe Persuasion SP5 Security User Guide, available at OpenText Knowledge Center.


http://streamshare.streamserve.com/Downloads

42 Tuning web service propertiesOptimizing StreamServe web applications

Tuning web service propertiesYou might enhance performance by tuning the web service properties for the StreamStudio portal and the SSSP application. The web service properties are defined in ws.properties files.

Default location of ws.properties, StreamStudio portal

<Portal root>\<Portal name>\WEB-INF\spring\properties


<TOMCAT_HOME>\webapps\<Portal name>\WEB-INF\spring\properties

Default location of ws.properties, SSSP application

<Portal root>\sssp\WEB-INF\spring\properties


<TOMCAT_HOME>\webapps\sssp\WEB-INF\spring\properties

Using an external directory for configuration files

If you use a directory outside the portal root for web application configuration files, you must update the ws.properties files in this directory.

The path to the external directory is defined by a dedicated system environment variable (STRS_WEB_CONFIG_DIR). For more information, see the StreamServe Persuasion SP5 Enhancement Pack 1 Reference Guide > StreamServe web applications, available at OpenText Knowledge Center.

In this section

• Tuning socket and connection timeouts on page 43.

• Load-balancing Service Gateways on page 43.

• Tuning timeouts for failed Service Gateways on page 44.

• Tuning connections pools for Service Gateways on page 44.

• Increasing size of the MTOM cache on page 45.

Related topics

• For information on how to tune the database connection pools for StreamStudio, see Database connection pool, StreamStudio on page 33.

• For information about the security properties in the ws.properties file, see the StreamServe Persuasion SP5 Security User Guide, available at OpenText Knowledge Center.


http://streamshare.streamserve.com/Downloads

Tuning web service properties 43Optimizing StreamServe web applications

Tuning socket and connection timeoutsYou can change the duration before a timeout occurs when the StreamStudio portal or the SSSP application connects to the Service Gateway. If the connection times out, an exception is returned to the client and a failure is presented.

The socket timeout (ws.socket.timeout) limits the time to establish a connection to the Service Gateway. It also limits the time spent on reading the response from the Service Gateway. By default, this is 60 000 ms.

The connection timeout (ws.connection.timeout) is how long the connection is kept open, waiting for the Service Gateway to send more data. By default, this is 60 000 ms.

Recommendations

Timeouts reduce the loss of processing resources consumed by idle connections. You should adjust the timeouts in conjunction with your environment (network capacity, bandwidth, etc.) and the expected size of the responses.

To edit the connection and socket timeouts

1 Open the ws.properties file in a text editor.

2 Edit the following properties:

#Property file for Web Service settingsws.connection.timeout=60000ws.socket.timeout=60000


Load-balancing Service GatewaysIn Control Center, you can specify a primary and a secondary Service Gateway.

By default, the secondary Service Gateway is only used if the primary Service Gateway is unavailable. If required, you can load balance the Service Gateways instead. The StreamStudio portal or the SSSP application then connects to the Service Gateway that was used at the last occasion.

Recommendations

If you add the secondary Service Gateway because the load on a single Service Gateway is too extensive, it is recommended to load balance the gateways.

To enable load balancing


2 Change the ws.servicegateway.url.lb.roundrobin property to true.


Related topics

For information on how to specify a secondary Service Gateway, see the Control Center documentation in OpenText StreamServe Online Help.


44 Tuning web service propertiesOptimizing StreamServe web applications

Tuning timeouts for failed Service GatewaysIf the StreamStudio portal or the SSSP application fails to connect to a Service Gateway, this Service Gateway becomes unavailable for connection retries for a limited period of time.

If there are two or more Service Gateways available, the ws.servicegateway.bad.reputation.long property specifies the time that a failed Service Gateway is unavailable for connection retries. By default, this is 300 000 ms.

If there is one single Service Gateway available, the ws.servicegateway.bad.reputation.short property specifies the time that a failed Service Gateway is unavailable for connection retries. By default, this is 500 ms.

To tune the timeouts for failed Service Gateways



ws.servicegateway.bad.reputation.long=300000ws.servicegateway.bad.reputation.short=500


Tuning connections pools for Service GatewaysTwo connection pools are available when the StreamStudio portal or the SSSP application connects to the Service Gateway. If a pool is exhausted, any remaining requests are lined up in a queue.

The ws.max.connections.per.host property specifies the maximum number of concurrent connections between the StreamStudio portal or the SSSP application and a single Service Gateway. By default, this is 10 connections.

If there are two or more Service Gateways available, the ws.max.connections.in.total property specifies the maximum number of concurrent connections between the StreamStudio portal or the SSSP application and the Service Gateways. By default, this is 20 connections.

To edit the Service Gateway connections



# Increase for more concurrent connections to SGWws.max.connections.per.host=10ws.max.connections.in.total=20



Tuning web service properties 45Optimizing StreamServe web applications

Increasing size of the MTOM cacheThe size threshold for caching a single Composition Center document or Ad Hoc document is specified in the MTOM (Message Transmission Optimization Mechanism) cache property. By default, this is 2.5 MB.

As long as the size of a single document is less than this threshold value, the document remains in the memory. If the threshold value is exceeded for a single document, the document is cached to disk. Since the document remains on disk after being processed and released, this results in lost disk space.

Recommendations

If you expect the size of the documents to be larger than the threshold value, you can either increase the size of the MTOM cache, or create a maintenance job that continuously deletes released documents from disk.

To increase the size of the MTOM cache



# Cache settingsws.axis2.cache.attachments.size_threshold=2500000ws.mtom.cache.dir=WEB-INF/mtom.cache


Increasing the size of the MTOM cache consumes more memory, which may result in decreased performance. End of warning.


46 Tuning the preview cache for the SSSP applicationOptimizing StreamServe web applications

Tuning the preview cache for the SSSP application

The SSSP application uses a separate preview cache to store document information from previews made in Ad Hoc Correspondence and Correspondence Reviewer.

The preview cache is configured in the ehcache.properties file using the following properties:

• sssp.doccache.maxElementsInMemory – The maximum number of objects that can be cached. By default, this is 100 objects.

• sssp.doccache.timeToIdleSeconds – How long these objects remain in the cache if they are not accessed. By default, this is 900 seconds.

• sssp.doccache.timeToLiveSeconds – How long a new object remains in the cache after being created. By default, this is 900 seconds.

Recommendations

If a large number of service requests are sent to the Service Gateway, you may reduce the response times by optimizing the preview cache. Increasing the maximum number of cached objects (sssp.doccache.maxElementsInMemory) has largest impact on the response times.

To edit the cache for the SSSP application

1 Open the ehcache.properties file in a text editor. The file is located in:

<Portal root>\sssp\WEB-INF\spring\properties


<TOMCAT_HOME>\webapps\sssp\WEB-INF\spring\properties

2 Edit the following properties (primarily the first one):

sssp.doccache.maxElementsInMemory=100sssp.doccache.timeToIdleSeconds=900sssp.doccache.timeToLiveSeconds=900


Increasing the size of the preview cache consumes more memory, which may result in decreased performance. End of warning.


Allocating memory to StreamServe web applications 47Optimizing StreamServe web applications

Allocating memory to StreamServe web applications

There must be enough memory allocated for the StreamStudio portal and the SSSP application on the JVM (Java Virtual Machine).

The amount of memory required depends on the current deployment scenario. For example:

• Deploying several StreamStudio web portals to the same Java application server requires more memory than deploying a single web portal.

• Deploying the Ad Hoc, Reviewer and SSSP applications to the same Java application server as the StreamStudio portal requires more memory than deploying these applications to a separate Java application server.

Recommendations

• For JVM memory recommendations, see the following documentation:

– StreamStudio Administrator’s Guide in OpenText StreamServe Online Help

– Ad Hoc Correspondence and Correspondence Reviewer Administrator’s Guide in OpenText StreamServe Online Help

– StreamServe Persuasion SP5 Enhancement Pack 1 Reference Guide > Document Broker Query Tool available at OpenText Knowledge Center

• If you expect more than 200 concurrent service requests from Ad Hoc users, it is recommended to install Ad Hoc Correspondence and the SSSP application on separate Java application servers.

Note: Since the Ad Hoc application is restricted to only access data from the site where it is deployed, an HTTP web server must then be used as a front-end proxy between the Ad Hoc and the SSSP application.

Related topics

For information about how to specify the memory settings, see the user documentation for the Java application server.

Deploying several applications to the same Java application server requires more memory, which may result in decreased performance.


48 Changing Java Virtual Machine versionOptimizing StreamServe web applications

Changing Java Virtual Machine versionApplicable if Java HotSpot VM is used as Java Virtual Machine (JVM).

The better the Java Virtual Machine (JVM) performs, the better the Java application server performs.

By default, the Client version of the JVM is used by the StreamServe web applications. When running Java HotSpot VM, it is recommended to use the Server version.

Related topics

To use the Server version on Java HotSpot VM, you must enable the –server option. For more information, see:

http://www.oracle.com/technetwork/java/hotspotfaq-138619.html


http://www.oracle.com/technetwork/java/hotspotfaq-138619.html

49Appendix A - StreamServe configuration files

Appendix A - StreamServe configuration files

You tune StreamServe applications (StreamServer, Archiver, Service Gateway, and Task Scheduler applications) by editing parameters in the configuration files for the applications.

In this section

• Editing configuration files on page 50.

• Configuration files and locations on page 53.


50 Editing configuration filesAppendix A - StreamServe configuration files

Editing configuration filesThe configuration files, in which you change the parameters for the StreamServe applications, are either application specific files, template files, or Platform files.

Some settings in the configuration files can be overridden by startup arguments. For example, if you use the -streamcache argument to specify the number of cached data streams per queue, this argument overrides the default setting in the iomanager.xml configuration file for the StreamServer application.

In this section

• Application specific files on page 50.

• Template files on page 51.

• Platform configuration files on page 52.

Application specific filesA StreamServe application primarily follows the instructions in the application specific configuration files, which reside in the working directory of the application.

Figure 2 Deployed configuration files for a StreamServer application

Editing an application specific file

You edit the application specific configuration file to apply changes to a specific application. The changes do not apply to any other applications.


Editing configuration files 51Appendix A - StreamServe configuration files

Template filesApplication specific files are based on template files.

Template files are deployed to the working directory when an application is created (Service Gateway, Archiver or Task Scheduler application) or the first time a Design Center Project is deployed to the application (StreamServer application).

The template files are either specific for a certain type of application or common for all types of StreamServe applications.

Figure 3 Template files for StreamServer applications

Figure 4 Common template file for all types of StreamServe applications

If a template file is stored both as an application specific file and as a common file, the application specific file is deployed to the working directory. For example, for Service Gateway applications, the application specific logmanager.xml file is deployed instead of the common logmanager.xml file.

Editing application specific files

By editing a template file, you can apply changes to all new applications created after the update is made. The changes do not apply to existing applications.

Note: You must have administrator rights to update files in the Program Files folder on Windows 7 and Windows 2008.


52 Editing configuration filesAppendix A - StreamServe configuration files

Platform configuration filesIn case there are no application specific template files and no common template files, the configuration files for the Platform are used.

Rather than being deployed to the working directories of the applications, the Platform configuration files are accessed directly from the StreamServe installation folder.

Figure 5 Template files in the Platform folder

If a configuration file is stored both as an application specific file and as a Platform configuration file, the application specific template file is deployed to the working directory and used by the application. For example, for Service Gateway applications, the application specific threadmanager.xml file is used instead of the threadmanager.xml Platform configuration file.

Editing Platform configuration files

By editing a Platform configuration file, you apply changes to all applications that use this file. The changes apply to both existing and new applications. The files are read when the applications are restarted.

Note: You must have administrator rights to update files in the Program Files folder on Windows 7 and Windows 2008.


Configuration files and locations 53Appendix A - StreamServe configuration files

Configuration files and locationsIn this section

• Configuration files on page 53.

• Locations of configuration files, Windows on page 54.

• Locations of configuration files, UNIX on page 56.

Configuration filesThis section lists configuration files that might be of interest when tuning the StreamServe environment.

Configuration file Contains settings for

repositorymanager.xml • The connection to the relevant repository for the application. That is, the runtime repository for StreamServer, Service Gateways, and Task Scheduler applications and the StreamServe archive for Archiver applications.

• The connection pool for the repository.

• The services for the repository. For example, settings for job deletion, job status updates, and heartbeat.

iomanager.xml • The pool of memory buffers for the StreamServe applications and the Service Component Framework.

• The maximum memory size allocated to each memory buffer.

logmanager.xml • The database log. For example, the log level.

threadmanager.xml • The thread pools.

semper.xml • The socket ports, keep alive timeouts, interfaces, etc. for the Service Gateway.

securitymanager.xml • The available authentication providers and directory providers.

• The connection pool for the security and role repository (in the runtime repository), and for the directory servers.

mgw-

repositorymanager.xml

• The Management Gateway used by Control Center to access the enterprise repository.

repositoryodbcproviders

.xml

• The ODBC database drivers. For example, the database connection string templates.

profilersevice.xml • The configuration of the Profiler service. For example, profiler provider and how to filter and present the profiling metrics in the output.


54 Configuration files and locationsAppendix A - StreamServe configuration files

Locations of configuration files, Windows

Abbreviations

• STRSCS – StreamServer application.

• STRSCI – Archiver application.

• STRSSG – Service Gateway application.

• STRSTS – Task Scheduler application.

Directories with template files

The paths below are specified relative to <StreamServe installation>, which is the path for the StreamServe installation. For example: C:\Program Files\StreamServe

Configuration file Directory


iomanager.xml

Applications\Management\<Version>\etc\config\<Version>\STRSCS\

Applications\Management\<Version>\etc\config\<Version>\STRSCI\

Applications\Management\<Version>\etc\config\<Version>\STRSSG\

Applications\Management\<Version>\etc\config\<Version>\STRSTS\

logmanager.xml Applications\Management\<Version>\etc\config\<Version>\common\

For Service Gateway applications:


threadmanager.xml Platform\Core\<Version>\bin\



semper.xml Applications\Service gateway\<Version>\bin

securitymanager.xml Platform\Core\<Version>\bin\

mgw-repositorymanager.xml Platform\Core\<Version>\bin\

repositoryodbcproviders.xml Platform\Core\<Version>\bin\

profilerservice.xml Platform\Core\<Version>\bin\



Directories with application specific files

The paths below are specified relative to <Base directory>, which is the path specified for StreamServe Projects during the Framework and Control Center installation. For example: C:\ManagementGateway\1.0



iomanager.xml

root\applications\<StreamServer>\<Layer>

root\applications\<Archiver>\wd

root\applications\<Service Gateway>\wd

root\applications\<Task Scheduler>\wd

logmanager.xml root\applications\<StreamServer>\<Layer>

root\applications\<Archiver>\wd


root\applications\<Task Scheduler>\wd

threadmanager.xml For Service Gateway applications:




Locations of configuration files, UNIX

Abbreviations

• STRSCS – StreamServer application.

• STRSCI – Archiver application.

• STRSSG – Service Gateway application.

• STRSTS – Task Scheduler application.

Directories with template files

The paths are specified relative to <StreamServe installation>, which is the path for the StreamServe installation.



iomanager.xml

applications/managementgateway/etc/config/<Version>/STRSCS/

applications/managementgateway/etc/config/<Version>/STRSCI/

applications/managementgateway/etc/config/<Version>/STRSSG/

applications/managementgateway/etc/config/<Version>/STRSTS/

logmanager.xml applications/managementgateway/etc/config/<Version>/common/


applications/managementgateway/etc/config/

<Version>/STRSSG/

threadmanager.xml platform/


applications/managementgateway/etc/config/

<Version>/STRSSG/

semper.xml applications/servicegateway/

securitymanager.xml platform/

mgw-repositorymanager.xml platform/

repositoryodbcproviders.xml platform/

profilerservice.xml platform/



Directories with application specific files

The paths are specified relative to <Project location>, which is the Project location specified during the StreamServer installation.For example: /opt/streamserve/root



iomanager.xml

applications/<StreamServer>/<Layer>

applications/<Archiver>/wd

applications/<Service Gateway>/wd

applications/<Task Scheduler>/wd

logmanager.xml applications/<StreamServer>/<Layer>

applications/<Archiver>/wd

applications/<Service Gateway>/wd

applications/<Task Scheduler>/wd

threadmanager.xml applications/<Service Gateway>/wd
