HP Web Jetadmin - Performance and Threadpools in HP Web Jetadmin

settings activated. As more features are activated on devices in a single HP Web Jetadmin host, the
number of potential devices under management decreases. Administrators might or might not plan to
use all the HP Web Jetadmin features in one HP Web Jetadmin implementation. For example, there
have been installations of HP Web Jetadmin that exceed 20,000 devices in the device list, but in this
case, the installation only runs data collections and reports.
Distributing HP Web Jetadmin across multiple servers
The first factor in sizing is to decide if one implementation of HP Web Jetadmin is possible or if the
implementation of HP Web Jetadmin should be broken into multiple servers. If it is believed that the
number of devices and desired features will overload a single server, perhaps the installations could
be split by groups of devices or by functionality.
Consider the multiregional approach:
 Europe: 2,300 devices and Reports are needed
 North America: 6,000 devices and both Reports and Alerting are needed
 Asia: 3,000 devices and Reports are needed
In this case, there are both functionality and devices to consider. In the Europe and Asia cases, one
server might be implemented for each population, while in the North America case, two server
implementations might be considered.
Here are some more hints on how Web Jetadmin features and devices impact the system:
Consolidated reports—This is one item that cannot be accomplished through distribution across
multiple servers. If the number of devices is large, deployment should consider one server dedicated
to reports data collection. In highly scaled environments, data might have to be drawn out of multiple
HP Web Jetadmin servers using Database Views.
By User/Peak Usage reports—If By User or Peak Usage reports are required across a large number of
devices, then consolidated reports is probably not an option. These data collections must be
distributed, so hopefully this work can be distributed across multiple servers by geography, function,
or some other logical grouping.
Alerts—Alerts is a very common bottleneck. However, it is also the easiest to distribute across servers.
Reducing the alerts load on any given server increases the performance and responsiveness. Regional
or organizational alerting across multiple servers is easy to implement.
Auto-grouping—Many customers use auto-grouping to drive configuration policies. Auto-grouping
causes a constant draw from system resources, so there is often a benefit to having a server dedicated
to configuration and auto-grouping policies. Many times there is a difference between groups that
provide general management structure and organization and groups that drive automatic
functionality. It should also be considered whether those auto-groups need to be replicated across all
of their servers.
Number of devices per server—When looking to distribute functionality across servers, it is useful to
limit the number of devices in each system. This increases the responsiveness across devices for the
intended functionality. For instance, if you have a server dedicated for alerts in the North America
region, make sure that the server only knows about the devices in the North America region that need
alerts.
Client load—Client load is another item to consider, although it is harder to distribute unless there is a
clear delineation by geography or other logical grouping of devices. Many times it is recommended
to set aside a server for help desk functionality that tends to have more ad hoc use models.