Web Farm and Web Garden Support
- 6 minutes to read
This document describes key concepts and requirements for Web reporting applications that operate in a clustered web environment (Web Farm or Web Garden).
Overview
A web farm is composed of two or more web servers (or nodes) that host multiple instances of an application and share the same IP address. User requests are sent to a single virtual web server, and the load balancer selects a web farm’s node to handle the request. A web garden is a web server that operates on a single machine. The web server configuration allows an application to run on multiple worker processes in an application pool and distributes the work to multiple CPUs.
Large web applications can benefit from the increased performance, reliability, and availability the clustered environment provides.
Note
If you use Azure App Service, review the following topic: Microsoft Azure Reporting.
Document and Report Cache
The Document Viewer component and the Report Designer component in Preview mode need access to the document while it is being generated.
For more information on the document generation process, review the following topic: Document Viewer Lifecycle.
In the distributed clustered environment there are two options: use ARR affinity so that all requests are routed to the same process or implement a document cache shared between processes.
Application Request Routing (ARR) on Web Farm
This option ensures that all user requests are handled by the same physical server/process where the report creation process was started. Otherwise, a new request sent to another server fails to find the necessary report. It means that each request initiated by a unique client should go to the same server. The load balancer must be instructed to use Application Request Routing (ARR) and provide client affinity (sticky session) to route all user requests to the same web server.
Share Reports and Documents Between Application Instances
If ARR affinity is not an option, an application should be configured to allow report and document sharing between application instances. The easiest solution is a shared folder that is accessible by both servers.
To implement this solution, modify your application to meet the following requirements:
Open a report with the Document Viewer methods that use a report’s unique name as a parameter:
ASP.NET Web Forms ASP.NET MVC ASP.NET Core OpenReport(String) Bind(String) Bind(String) To resolve a report’s unique name, create and register a service that implements the IReportProvider interface, and translates the specified name to a XtraReport instance.
Force the Report Designer’s Preview to use cached report source. For this, call the UseCachedReportSourceBuilder method at application startup:
ASP.NET Web Forms and MVC ASP.NET Core DefaultWebDocumentViewerContainer.UseCachedReportSourceBuilder WebDocumentViewerConfigurationBuilder.UseCachedReportSourceBuilder Implement a persistent storage to store the generated documents. When you start with the Devexpress template to create an ASP.NET Core Reporting project, you have the option to add document storage. You can use the resulting project with the added document storage as a guide and customize it as needed. For more information, review the following help topic: Microsoft Azure Integration Specifics.
Alternatively, use the file storage that is available out-of-the-box. For this, call the following methods with the StorageSynchronizationMode parameter set to InterProcess:
Implement a persistent file storage to store the report instance. This step is required for the Report Designer’s Preview or when the report includes interactive features.
In this case, the Document Viewer recreates the document from a report instance that is in memory. Save the report instance to the persistent file storage instead. When the memory cache is empty, the Document Viewer retrieves a report from the directory that contains a serialized report and creates a document.
When you start with the Devexpress template to create an ASP.NET Core Reporting project, you have the option to implement a Document Cache Storage. You can use the resulting project with the added document storage as a guide and customize it as needed. For more information, review the following help topic: Microsoft Azure Integration Specifics.
To use file storage, call the following methods with the StorageSynchronizationMode parameter set to InterProcess:
If the asynchronous export mode is enabled explicitly (the AsyncExportApproach is set to true) or content editing is enabled in the exported document, call the following methods with the StorageSynchronizationMode parameter set to InterProcess:
Important
Make sure that all the web farm’s nodes have access to the folder used as file storage.
Report and Document TTL Settings
Provide time settings for cleaning the in-memory cache that stores documents and reports. Create an instance of the CacheCleanerSettings object and specify its properties.
Provide time settings for cleaning the file storage that stores documents, exported documents and reports. Create an instance of the StorageCleanerSettings object and specify its properties.
Register the CacheCleanerSettings and StorageCleanerSettings services as described in the following topics:
ASP.NET Web Forms and MVC ASP.NET Core Register Services in the Document Viewer Register Services in the Document Viewer
Shared Machine Key
The End-User Report Designer requires that all nodes in the Web Farm have the same value for validationKey and decryptionKey (which comprise the machine key). These values are used to encrypt and decrypt connection parameters sent to the client. A shared machine key is necessary because the Load Balancer can route successive requests to different servers.
Do one of the following to meet this requirement:
- Use connections names instead of connection parameters. Connection names do not need encryption and the machine key is unnecessary. This technique requires a global service that implements the IConnectionProviderFactory interface to resolve connection names. Note that the connection provider factory should resolve names for connections listed in the web.config/appsettings.json configuration files.
- Share the machine key to make it available for all Web Farm nodes.
Shared Data Protection Keys
Data protection keys encrypt the data source to which the client connects. The encrypted object can be a connection string or an object type. It is important to share the data protection keys between instances.
For more information, review the following documents: