Indexing Service

The 'Sleep Time' property controls how frequently the Indexing Service checks for new, updated, or deleted documents in the repository.

Usage

• Enter a time span in a supported format, such as 30s (30 seconds), 5m (5 minutes), or 1h (1 hour).
• The default value is 30s.

Impact

• Shorter intervals result in more immediate indexing but may increase system load.
• Longer intervals reduce load but may delay updates to the AI Search index.
• Choose a value that balances indexing responsiveness with system performance.

The 'Hours Of Operation' property restricts when the Indexing Service is allowed to process indexing jobs.

Usage

• Enter one or more time ranges as a comma-separated list, using a hyphen (-) to separate start and end times.
• Example: 8AM - 12PM, 1:30PM - 4:45PM
• If left blank, indexing runs 24 hours per day.

Impact

• Indexing will only occur during the specified time windows.
• Use this to avoid running indexing jobs during off-hours or maintenance windows.

The 'Local Processing Threshold' property determines when the Indexing Service will process jobs locally versus submitting them for distributed processing.

Usage

• Enter a positive integer to set the maximum number of documents for local processing.
• A value of 0 disables local processing entirely.
• The default value is 3.

Impact

• Small jobs (at or below the threshold) are processed immediately on the local server, reducing overhead and latency.
• Larger jobs are submitted to the Processing Queue for distributed processing by Activity Processing services.
• Adjust this value based on your environment's size and performance needs.

The 'Job Size' property controls how many documents are batched together in a single indexing job.

Usage

• Enter a positive integer to set the batch size.
• The default value is 5000.

Impact

• Smaller job sizes allow for more granular, responsive indexing but may increase job management overhead.
• Larger job sizes are more efficient for bulk indexing but may delay processing of individual document changes.
• Tune this value based on the frequency and volume of document changes in your environment.

The Priority property determines the scheduling priority for indexing jobs submitted by the Indexing Service.

Usage

• Enter an integer value; lower numbers indicate higher priority.
• The default value is 3.

Impact and Best Practices

• The priority value directly affects the order in which jobs are processed within the assigned Processing Queue.
• If indexing jobs and batch processing jobs share the same queue, use this property to control which jobs are processed first:
  • Assign a higher (numerically lower) priority to indexing jobs to ensure they are processed before batch processing jobs.
  • Assign a lower (numerically higher) priority to indexing jobs to ensure batch processing jobs are not delayed by indexing activity.
• This property is especially important in environments where all jobs run on the same queue and resource contention is possible.
• Adjust the priority as needed to balance the timeliness of search index updates with the throughput of production batch processing.

Example Scenarios

• Prioritize Indexing:
  Set the priority of indexing jobs to 1 and batch processing jobs to 3 to ensure search indexes are updated as quickly as possible.
• Defer Indexing:
  Set the priority of indexing jobs to 5 and batch processing jobs to 2 to ensure that production batches are always processed first.

Use this property to fine-tune job scheduling and prevent unwanted delays or resource contention between indexing and batch processing workloads.

The Processing Queue property determines which servers and thread pools are responsible for executing indexing jobs created by the Indexing Service.

Usage

• Select a Processing Queue from the available options in your environment.
• Assign a queue that is monitored by one or more Activity Processing services.

Impact on Batch Processing

Indexing jobs submitted by the Indexing Service are processed by Activity Processing services assigned to the selected queue. If the same queue is used for both indexing and production batch processing, there is potential for indexing jobs to delay or compete with critical batch work. This can result in slower processing of batches, especially in high-volume environments or when large numbers of documents are being indexed.

To avoid this, it is recommended to create a dedicated Processing Queue specifically for indexing jobs. By assigning indexing jobs to a separate queue, you can ensure that production batch processing is never delayed or blocked by indexing activity. This separation allows for more predictable performance and easier troubleshooting of processing bottlenecks.

Best Practices

• Use a Dedicated Queue for Indexing:
  Create a separate Processing Queue for indexing jobs to isolate them from production batch processing workloads.
• Install Dedicated Activity Processing Instances:
  Assign one or more Activity Processing services to the indexing queue. This ensures that indexing jobs are processed promptly and do not interfere with other critical processing tasks.
• Monitor Queue Utilization:
  Regularly review the status and workload of each queue to ensure that both indexing and batch processing jobs are being handled efficiently.
• Adjust Resources as Needed:
  If indexing jobs are not being processed quickly enough, consider adding additional Activity Processing instances to the indexing queue.

Example Scenario

• Production Queue: Used exclusively for batch processing steps such as extraction, classification, and export.
• Indexing Queue: Used exclusively for indexing jobs submitted by the Indexing Service.
• Result: Indexing jobs are processed in parallel with batch work, without risk of delays or resource contention.

The 'Delete Completed Jobs' property controls whether completed indexing jobs are retained or removed from the system.

Usage

• Set to true to automatically delete jobs after they finish.
• Set to false to retain job history for auditing or troubleshooting.
• The default value is true.

Impact

• Deleting completed jobs helps keep the database clean and reduces storage requirements.
• Retaining jobs may be useful for environments that require detailed job tracking or compliance auditing.

Binds the Service Instance to a specific Grooper repository. This association is permanent for the lifetime of the service instance. To change the repository, uninstall and reinstall the service with the desired repository assignment.

Usage

• Select the target repository when installing or configuring the service.
• The repository must be accessible and properly configured for the service to function.

Impact

• All operations performed by this Service Instance will be executed against the selected repository.
• Changing the repository after installation is not supported; uninstall and reinstall to rebind.

Specifies the internal Windows service name used to identify the Service Instance on the target machine. This value is typically auto-generated but can be customized during installation.

Usage

• Use a descriptive name to clarify the service's function or assignment.
• The name must be unique among all Windows services on the machine.

Example

Grooper.ActivityProcessing.01

Impact

• Used by system tools and scripts to control or monitor the service.
• Changing this value after installation requires uninstalling and reinstalling the service.

Sets the friendly name shown in the Windows Services control panel and Grooper UI for this Service Instance. This name helps administrators and users identify the service's purpose.

Usage

• Use a clear, descriptive display name to distinguish this service from others.
• The display name can include the service type and instance number for clarity.

Example

Grooper Activity Processing, Instance 01

Impact

• Changing the display name updates how the service appears in management tools but does not affect its internal operation.

Can be one of the following values:

Controls the thread scheduling priority for all processing performed by this Service Instance.

Usage

• Select a priority appropriate for the server's workload.
• On workstations, use a lower priority to avoid impacting user interface responsiveness.

Options

• Values are from the ThreadPriority enumeration, such as Normal, BelowNormal, or AboveNormal.

Impact

• Higher priorities may improve processing speed but can affect other applications.
• Lower priorities reduce the risk of interfering with interactive users.

Specifies the Windows user account used to run the Service Instance. This account must have the necessary permissions for service operation.

Requirements

• Logon as Service permission on the target machine.
• Access to the Grooper database (if using Windows authentication).
• Access to any required file store locations.

Usage

• Enter the account name in the format DOMAIN\\Username or .\LocalUser.
• Avoid using built-in accounts unless required by your environment.

Impact

• The service will run with the permissions of the specified account.
• Insufficient permissions may prevent the service from starting or accessing required resources.

Sets the password for the specified user account. This value is stored securely and is required for non-built-in accounts.

Usage

• Enter the password for the account specified in 'User Name'.
• The password is encrypted and not displayed in the UI.

Security

• Ensure the password is kept up to date if the account's credentials change.
• Only users with administrative privileges should be allowed to view or modify this property.

Impact

• Incorrect passwords will prevent the service from starting.