Server performance testing and diagnostic data collection is vital for ensuring proper system performance by locating...
potential bottlenecks, spotting inadequate resources and so on. However, diagnostic functions do impose a certain amount of load on a server's resources. If left unchecked, the diagnostic's resource demands might divert enough processor cycles, storage IOPS and network bandwidth to potentially impose a performance penalty on a server.
Consider a tool like VMware's vCenter Server which allows the collection of server performance data statistics over time. Administrators can set data collection to various levels of increasing detail (such as level 1, level 2 and so on). Increasing the level collects more data, but more data requires more compute and storage from the server. Increasing the collection level higher than level 2 can cause a variety of side-effects including bloated vCenter Server database and transaction log file sizes, unusually long times to organize the performance data (which may include gaps in the data), and even impair the overall performance of vCenter Server or its services. Server performance testing stress might also be seen even with generic tools like Microsoft's Performance Monitor when collecting and storing a large number of counters at high data rates.
The solution here is to apply common-sense and judicious use of server performance testing and monitoring diagnostics on production servers. Understand the performance characteristics that you need to see, turn off the data collection that you don't and set the collection frequency to a level that's appropriate. There may be some instances where more data and resolution are needed to isolate problems -- and that's perfectly acceptable as a necessary troubleshooting tactic -- as long as the diagnostics are scaled back or turned off when testing is completed.
If you discover that some other workloads are adversely affected by the diagnostic's computing overhead, consider migrating an affected workload to another server. If issues "follow" a migrated workload to another server, which can also be used as a diagnostic indicator, the problem is in the workload rather than the server hardware. You can always restore an affected workload back to the original server once the diagnostic process is completed and the data collection is scaled back or turned off.
The art of virtual application performance testing
Server benchmark and testing guide
What to look for in PerfMon benchmark testing
Dig Deeper on Virtual machine performance management
Related Q&A from Stephen J. Bigelow
Your power users will want to be the first in line to try out upcoming features through the Office 365 targeted release program. Set up early access ... Continue Reading
Many compatibility issues can arise when moving VMs to the public cloud. Watch out for compatibility problems with partitions, OSes and image formats... Continue Reading
To migrate a VM and its dependencies from a local data center to a public cloud, use the forklift method to prepare the VM for migration, deploy the ... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.