This article outlines changes made to the core side brokerservice.exe. BrokerService.exe (aka. LANDesk Management Gateway Service) is the core side service that is responsible for establishing SSL Tunnels to the Management Gateway. Previously a hard limit was configured in order to keep the service from consuming too many resources and locking up the core. Due to enhancements in OS technology the resources for brokerservice.exe are now configurable. These changes result in virtually eliminating a major performance bottleneck when managing clients through the Gateway. For details please see the Performance and Detailed Description of Changes section below.
Settings Quick Reference
This is a section for those who are familiar with the changes outlined in this article and just need to reference how to configure the options for brokerservice.exe.
Post 9.0 SP1 Patch: LDMG-4810790.1 (This patch will be included in subsequent versions.)
The options for brokerservice.exe are configurable as command line parameters. The changes should be made directly to the service itself as shown in the example below:
"C:\Program Files (x86)\LANDesk\ManagementSuite\BrokerService.exe" /numthreads 1024 /matchthreads 30
/Numthreads = Maximum number of threads allowed. Default = 256. Maximum = 2048. (Note: Some OS's should not have over 512 threads. Filling up the thread pool will completely lock an OS)
/Matchthreads = Number of threads that will build a connection to the Gateway and wait for a client connection. Default = 15. Maximum = 2048.
Note: The default settings should be enough to handle most situations.
Performance and Detailed Description of Changes
Despite the Management Gateway's ability to handle more than 5,000 connections the core brokerservice.exe could only handle 120 with 6 waiting connections. These limitations made spikes in connections and the total amount of connections difficult to handle. The limitations were necessary due to older OS limitations. If the thread pool on the OS were to fill up the OS would lock up and need to be reset. The brokerservice.exe was fast in handling these connections but a bottle neck existed not only with the total number of connections but with the overhead of rebuilding the SSL Tunnels.
Configurable. Up to 2048 on both total connections and matching connections. See above for settings.
When the broker service is started it will spin up 256 threads (default). The threads will go to different states based on demand.
Matching = Currently connected to the Gateway and waiting for a connection.
Working = Currently handling a client request.
Waiting = Sitting idle in the pool to become the next matching thread.
When a thread is moved to working from a matching state an idle thread is moved to matching. The change in behavior is that now threads move from state to state instead of being shutdown and restarted. This helps with scalability and stability during peak load times.
Previous brokerservice.exe limitations only allowed 10 connections per second due to hard limits in the thread creation pool. In customer testing over 2500 vulscans were handled in 1 hour with the settings of 256 threads and 15 matching. We were also able to see around 30 connections per second during peek times. (Note: In the customer test case the patch server for downloading patches was accessible from the internet)