Performance Monitor (PerfMon) - Detailed Guide for Desktop Application Performance Testing
1. What is Performance Monitor (PerfMon)?
- Performance Monitor (PerfMon) is a built-in Windows tool that allows users to monitor system performance in real time and analyze performance metrics. It helps track system resources such as CPU, memory, disk usage, and network activity.
- This tool is especially useful for diagnosing performance issues in applications, including desktop applications, by identifying resource consumption and bottlenecks.
2. How Does Performance Monitor (PerfMon) Work?
- PerfMon works by collecting system and application performance data using counters. These counters provide real-time data on various system resources such as:
Processor Usage (CPU utilization, threads, and context switching)
Memory Usage (RAM consumption, page faults, and working set)
Disk Activity (Read/Write speed, disk queue length)
Network Activity (Bandwidth usage, packet loss)
Application-Specific Performance (Handles, Threads, GDI objects, private bytes)
PerfMon can display this data in:
Live Graphs (for real-time monitoring)
Reports (for detailed analysis)
Logs (for historical analysis)
3. Can We Use PerfMon for Desktop Application Performance Testing?
Yes! PerfMon is an effective tool for monitoring desktop application performance because it helps in:
✅ Identifying CPU, memory, and disk usage of the application
✅ Detecting memory leaks and resource consumption issues
✅ Measuring application response times and efficiency
✅ Analyzing performance trends over time
✅ Finding bottlenecks in the system
4. How to Measure Application Performance Using PerfMon?
To measure the performance of a desktop application using PerfMon, follow these steps:
Step 1: Open Performance Monitor
- Press Win + R, type perfmon, and press Enter
- The Performance Monitor window will open
Step 2: Create a New Data Collector Set
- In the left panel, expand Data Collector Sets
- Right-click User Defined → Select New → Click Data Collector Set
- Enter a name (e.g., "AppPerformanceTest") and click Next
- Select Create manually (Advanced) and click Next
- In the Performance Monitor window, click Performance Monitor in the left panel
- Click the Green ‘+’ icon (Add Counters)
- Choose counters based on what you want to measure:
- Processor → % Processor Time → Monitors CPU usage
- Memory → Working Set - Private → Tracks RAM usage of the application
- Process → Handle Count → Measures resource usage
- Process → Thread Count → Monitors number of active threads
- Disk → Disk Read/Write Bytes/sec → Measures disk I/O
- Network → Bytes Sent/Received → Tracks network usage
- Click Add, then OK
Step 4: Configure Data Logging (Optional - For Detailed Reports)
- In Data Collector Set, right-click your test set → Select Properties
- Go to the Stop Condition tab → Set the duration (e.g., 10 minutes)
- In the File Tab, select CSV format for logs
Step 5: Start Performance Monitoring
- Go to Performance Monitor
- Right-click your Data Collector Set → Click Start
- Launch your desktop application and perform test activities
- After testing, return to PerfMon and Stop the Data Collector
Step 6: Analyze Performance Data
- Go to Reports → User Defined → Select your test
- Review CPU, memory, disk, and network usage graphs
- Identify performance bottlenecks such as high CPU usage, memory leaks, or disk slowdowns
1. CPU Usage (Processor Performance)
Counters to Monitor:
Processor → % Processor Time
Process → % Processor Time (specific to your app)
Processor → Processor Queue Length
What to Look For:
% Processor Time: Should ideally be below 80% for smooth performance. If it's consistently high, the app may be CPU-intensive.
Processor Queue Length: If >2 per CPU core, it means the processor is overloaded.
CPU Spikes: Sudden spikes indicate inefficient processing, excessive loops, or unoptimized background tasks.
Possible Issues:
High CPU usage = Inefficient algorithms, infinite loops, excessive background tasks
CPU spikes = Poorly optimized queries, real-time calculations, or excessive logging
2. Memory Usage (RAM Consumption)
Counters to Monitor:
Process → Working Set - Private (Memory used by the application)
Memory → Available MBytes (Remaining system memory)
Memory → Page Faults/sec (Swapping between RAM and disk)
What to Look For:
High Working Set - Private: If it keeps increasing over time, there might be a memory leak.
Available MBytes: Should not drop below 500MB, or the system may slow down.
Page Faults/sec: High values indicate insufficient RAM or excessive swapping.
Possible Issues:
High RAM consumption = Memory leaks, improper garbage collection
Low Available Memory = Application using more RAM than expected
3. Disk Usage (Disk Read/Write Speed)
Counters to Monitor:
Logical Disk → % Disk Time (Utilization of the disk)
Logical Disk → Disk Read Bytes/sec & Disk Write Bytes/sec
Process → IO Data Bytes/sec (I/O operations of the application)
What to Look For:
% Disk Time should not be consistently above 80%, or the disk is under heavy load.
High Disk Read/Write Bytes may indicate excessive logging, database queries, or file handling.
Possible Issues:
Slow app loading time = High Disk Read/Write due to unoptimized file handling
High disk usage = Unnecessary logging, inefficient database queries
4. Network Performance (Bandwidth & Connectivity)
Counters to Monitor:
Network Interface → Bytes Sent/sec & Bytes Received/sec
Process → IO Other Bytes/sec (Includes network traffic)
TCPv4 → Connection Failures (Tracks dropped connections)
What to Look For:
High Bytes Sent/Received = Application is using too much bandwidth.
Connection Failures should be close to zero to avoid connectivity issues.
Possible Issues:
Slow network performance = Too many requests, large file transfers
Connection failures = Poor network handling, frequent API timeouts
5. Thread & Handle Count (Application Stability)
Counters to Monitor:
Process → Thread Count
Process → Handle Count
What to Look For:
Thread Count: Too many active threads (e.g., >200) can slow down the application.
Handle Count: If it keeps increasing without dropping, it indicates a resource leak.
Possible Issues:
High thread count = Too many background processes running
High handle count = Resource leak, inefficient process handling
6. Application Response Time (Performance Delays)
Counters to Monitor:
System → Context Switches/sec (Tracks multi-threading efficiency)
Processor → % Privileged Time (Time spent on OS-related tasks)
Process → Elapsed Time (Total runtime of the application)
What to Look For:
High Context Switches/sec: If it is too high (>10,000 per second), it means too many processes are competing for CPU time.
High Privileged Time: If the app is spending too much time in system-level operations, it may indicate inefficient API calls.
Possible Issues:
Slow UI response = Too many context switches or high privileged time
High OS-level processing = Inefficient system interactions
7. Garbage Collection (For .NET Applications)
Counters to Monitor:
.NET CLR Memory → % Time in GC (Time spent in garbage collection)
.NET CLR Memory → Gen 0/1/2 Collections
What to Look For:
% Time in GC should be <5%: If it's high, garbage collection is consuming too much CPU time.
Frequent Gen 2 Collections: Indicates memory pressure and possible memory leaks.
Possible Issues:
High GC time = Inefficient memory allocation, excessive object creation
Frequent garbage collection = Too many short-lived objects
Comments
Post a Comment