Database Reference
In-Depth Information
information that will be stored by default in the RavenDB, but the subscription storage's
configuration can be changed to save it to other databases as well.
Performance monitoring
When using clustering, an important practice is to monitor the performance of the hand-
lers and workers. This is needed to determine whether workers are even needed, and if so,
how many.
The first step is to ensure that the solution has the performance counters installed. We dis-
cussed this in the use of PowerShell to test the installation of the performance counters.
There are two main types of performance counters in NSB. The first is the critical time
performance that is more of an end-to-end performance, and the other is the endpoint
Service-level agreement ( SLA ) that monitors the mean time of the endpoint to ensure it
meets the service level. The SLA endpoint has to specify a time that it must meet in the
performance. In order to do this, the endpoint SLQ must be set in code. The monitor will
show the seconds left until you breach your SLA time. Let's look at adding the code into
the handler's EndpointConfig.cs: .
In this section, we will be using the ScaleOut - Performance solution, which is
the same as the ScaleOut solution, except for the fact that some performance settings
have been added to this solution.
The performance counters are used by default if the profile of the deployment is in pro-
duction mode. This mode is set by default, but it needs to be specified if other parameters
such as master or worker are used. Let's look at the handler's deployment properties:
We can see that the performance counters are installed at startup:
Search WWH ::




Custom Search