Server performance testing and diagnostic data collection is vital for ensuring proper system performance by locating...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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
Cleanly divided and straightforward applications are good candidates for a container-based deployment, whereas complex applications pose more ...continue reading
Assessing the impact of containers on application workloads can be extremely challenging, partially because of how quickly containers are spun up and...continue reading
There are many tools that help with container orchestration, but it's important to review all the features before choosing a platform to make sure it...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.