The first step in planning an AppMon deployment is to collect the relevant sizing data required to accurately size your deployment. Although obtaining precise sizing data can be challenging, this step should be considered essential and not overlooked. The more accurate your sizing data is, the more likely your deployment successfully supports the current sizing requirements of your environment and scales to meet any future requirements.
To determine the data required to correctly size your AppMon deployment, answer the questions below. The answers to these questions provide the necessary input to enter in the Deployment Sizing Calculator. For help in answering a question, click the question to view information that explains the important considerations and details about the question.
Determine the number of agents
Agents collect data and frequently send this data to the AppMon Collector, which in turn passes the data to the AppMon Server. More Agents means more data and more effect on your sizing requirements.
Determine the number of Agents you plan to instrument for:
- Java virtual machines
- .NET Agents
- .NET servers
- PHP processes
- Web server processes
- Message Broker processes (execution groups)
- Native processes
- Host Monitoring Agents (servers)
- NoSQL processes
- CICS regions
Special considerations for .NET Agents
.NET Windows OS instances (WOSI) can support multiple Agents, but .NET is licensed per Windows OS instance (WOSI) and not per Agent. As a result, do not use the number of WOSI licenses as an accurate count of the number of .NET Agents.
To count the number of .NET Agents, add together the total number of IIS w3wp worker processes. This number is equal to or greater than the number of app pools.
If you can not provide this number, count the total number of ASP.NET applications hosted in the w3wp processes (=webapps, app domains). The number is equal to or greater than the number of w3wp processes. ASP.NET webapps show up in IIS Manager (Applications column in the Application Pools page). Your system administrators should know how many ASP.NET webapps are deployed.
- Total number of non-IIS .NET instances. This is the sum of:
- .NET-based Windows services that you want to instrument.
- .NET-based standalone executables, which could be user programs or worker processes of non-IIS .NET servers such as Cassini.
See http://www.iis.net/learn/get-started/getting-started-with-iis/getting-started-with-appcmdexe for more help to determine the number of required .NET Agents.
You must also determine the total number of app pools across all servers as part of this process.
Customer deployment - lessons learned
An AppMon customer purchased 20 .NET Agents. Filling in the number 20 in the Deployment Sizing Calculator created a recommendation for a small to medium deployment. However, when deploying this environment, the AppMon Server was completely undersized.
What happened? Every one of the 20 .NET Windows OS instances (WOSIs) consisted of approximately 70 Agents. In the end, it was not a small environment but an xlarge environment with more than 1,400 Agents. Instead of deploying one Collector, 30 additional Collectors had to be deployed. Obtaining precise sizing data can make a very significant difference in a deployment.
Special considerations for web server processes
For Apache and IBM HTTP Servers, you can simply count the number of instrumented processes, which is identical to the number of licenses you need. Microsoft IIS Web Servers, however, require only one license per Windows OS (similar to .NET licensing), meaning that you need to count the total number of worker processes instead.
Collect PurePath numbers
Estimate the number of transactions (this is the number of server-side requests) that are handled by the data center during one day. Normally, operators have a good understanding of how many transactions are produced. If you don't have this number, you can also estimate it with a POC in which you can see the current transactions per seconds in the Client, and then compute the daily transactions.
In addition, you may need to estimate the number of nodes per PurePath (or transaction). The number of nodes may vary. In some environments, the number is relatively low (about 50), but our experience leads us to recommend higher estimates (200 to 300). You can empirically derive the number of nodes with self-monitoring during a POC.
If you use UEM, review the static resources.
Are static resources delivered by the web server? If yes, this leads to a higher number of transactions with only one node. A typical web request contains some 40 static resources, 80 percent of which are cached. As a result, the number of transactions per second is increased, but the average number of nodes per PurePath is lowered due to the caching. Within a UEM environment, the average Nodes per PurePath are estimated with the following formula:
(Transactions per Day * average Nodes per PurePath + Static Resources requested per Day) / (Transactions per Day + Static Resources requested per Day).
The number of transactions influences the Session Storage size. Session Storage is a data area controlled by the AppMon Server used to store all PurePath information in it. Consequently, the duration of how long you want to keep your PurePath sessions stored on the disk influence the Session Storage size.
In addition, the Session Storage size is influenced by the use of auto sensors, which increases the size requirements, and by UEM visits or PurePath percentages, which decrease the size requirements.
Sizing the Session Storage to less than 2 TB is recommended. Although it is technically possible to exceed this limit into the tens of terabytes, analyzing this amount of data is not a practical consideration.
The Performance Warehouse size is primarily influenced by the amount of time required to retain high-resolution data. The medium- and high-resolution periods play a rather insignificant role.
More important than the Performance Warehouse size, which is typically quite reasonable, is the number of measurements it can handle. Too many measurements overload the database server. In this case, a reduction of cyclic measures or business transactions should be considered.
In a production environment, more than just scalability must be considered. Even if an AppMon Server could accommodate more Agents (more load), the Server always has physical limits. To avoid reaching these limits, decrease the number of PurePath nodes. Usually there is not any reason to have an average node number of 5,000 in a production environment. A value of 10 or 50 is generally good for production. A successful POC is always a good source to get proper values. To reduce the average node length, you can switch off several sensors or use aggregation, such as for JDBC.
User experience management (UEM) delivered with static resources has additional impact on the AppMon Server. Therefore, it's assumed that every transaction has an extra load and generates more total PurePaths. Learn more about UEM.
It is crucial to figure out when your applications incur the heaviest traffic and transactions. For example, web shops need to prepare in advance for peak load during the holiday shopping. This means that the AppMon Server has to handle the entire load during the heavy load period calculated with the right Peak Factor.
The default load distribution value is 24 hours, but this time period is dependent on your application or web shop and how the load is distributed. For example, a web shop that is available only in Europe has a load distribution of about 8 hours. In this time frame, most of the business transactions occur. This means that the total number of transactions must be divided by 8 and not 24 hours, which significantly changes the number of total transactions per day.