Endpoint Privilege Management for Windows Performance Reports
Endpoint Privilege Management for Windows (EPM-W) performance reports are available for the following versions:
EPM-W 24.1 Performance Report
Introduction
The aim of this document is to provide data on agreed performance metrics of the EPM-W desktop client compared to the previous release.
The content of this document should be used to provide general guidance only. There are many different factors in a live environment which could show different results such as hardware configuration, Windows configuration and background activities, 3rd party products, and the nature of the EPM policy being used.
Performance Benchmarking
Test Scenario
Tests are performed on dedicated VMs hosted in our data center. Each VM is configured with:
- Windows 10 21H2
- 4 Core 3.3GHz CPU
- 8GB Ram
Testing was performed using the GA release of 24.1
Test Name
Quick Start policy with a single matching rule.
Test Method
This test involves a modified QuickStart policy where a single matching rule is added which auto elevates an application based on its name. Auditing is also turned on for the application. The application is trivial command line app and is executed once per second for 60 minutes. Performance counters and EPM-W activity logging are collected and recorded by the test and this data is available as an archive which should be attached to this report.
Process Start Latency After Rule Match
|
Series |
Mean |
Min |
Max |
|---|---|---|---|
|
Process Matching Rule Latency (ms) |
0.80 |
0.45 |
4.57 |
Process Start Latency vs. Processor Time
|
Series |
Mean |
Min |
Max |
|---|---|---|---|
|
Process Matching Rule Latency (ms) |
0.80 |
0.45 |
4.57 |
|
% Processor Time |
2.52 |
1.70 |
8.52 |
CPU User/System Time
|
Series |
Mean |
Min |
Max |
|---|---|---|---|
|
% User Time |
1.01 |
0.31 |
4.58 |
|
% Privileged Time |
1.50 |
0.89 |
4.08 |
Defendpoint CPU User/System Time
|
Series |
Mean |
Min |
Max |
|---|---|---|---|
|
% User Time (DP) |
1.02 |
0.16 |
2.02 |
|
% Privileged Time (DP) |
0.93 |
0.00 |
2.18 |
Defendpoint Private Bytes
|
Series |
Mean |
Min |
Max |
|---|---|---|---|
|
Private Bytes (DP) |
13,905,599.00 |
12,357,630.00 |
14,520,320.00 |
Defendpoint Handle/Thread Counts
|
Series |
Mean |
Min |
Max |
|---|---|---|---|
|
Thread Count (DP) |
38.80 |
35.00 |
41.00 |
| Handle Count (DP) | 565.84 | 489.00 | 641.00 |
EPM-W 23.9 Performance Report
Introduction
The aim of this document is to provide data on the agreed performance metrics of the EPM-W desktop client compared to the previous release.
The content of this document provides general guidance only. There are many different factors in a live environment, which could show different results such as hardware configuration, Windows configuration and background activities, third-party products, and the nature of the EPM policy being used.
Performance Benchmarking
Test Scenario
Tests are performed on dedicated VMs hosted in our data center. Each VM is configured with:
- Windows 10 21H2
- 4 Core 3.3GHz CPU
- 8GB Ram
Testing was performed using the GA release of 23.9.
Test Name
QuickStart policy with single matching rule
Test Method
This test involves a modified QuickStart policy where a single matching rule is added, which auto-elevates an application based on its name. Auditing is also turned on for the application. The application is a trivial command line app and is executed once per second for 60 minutes. Performance counters and EPM-W activity logging are collected and recorded by the test.
The QuickStart policy is commonly used as a base for all of our customers, and it can be applied using our Policy Editor Import Template function. It was chosen because it's our most common use case. The application being elevated is a dummy application EXE, which we’ve created specifically for this testing. It terminates quickly and doesn't have a UI, making it ideal for the testing scenario.
Results
Listed below are the results from the runs of the tests on 23.9 and our previous release, 23.7. Due to the nature of our product, we are very sensitive to the OS and general computer activity, so some fluctuation is to be expected.
Rule Matching Latency
Shows the time taken for the rule to match. A significant decrease in mean latency was observed.
| Series | Mean | Min | Max |
|---|---|---|---|
| 23.9 Process Matching Rule Latency (ms) | 1.14 | 0.62 | 8.64 |
| 23.7 Process Matching Rule Latency (ms) | 5.51 | 3.52 | 24.37 |
Processor Time (Defendpoint)
Percentage of processor time used by the Defendpoint service. A notable decrease in processor time was observed.
| Series | Mean | Min | Max |
|---|---|---|---|
| 23.9 % Processor Time (DP) | 2.00 | 0.78 | 3.42 |
| 23.7 % Processor Time (DP) | 2.84 | 1.55 | 5.14 |
Private Bytes (Defendpoint)
Shows the whole size of the memory consumed by the Defendpoint process. A small decrease in memory usage was observed.
| Test/Version | Mean | Min | Max |
|---|---|---|---|
| 23.9 Private Bytes (DP) | 13330194.56 | 11558910.00 | 14221310.00 |
| 23.7 Private Bytes (DP) | 14,957,248.84 | 12,779,520.00 | 15,843,330.00 |
I/O Write Bytes/sec (Defendpoint)
Shows disk I/O used by the Defendpoint service. A significant decrease was observed for I/O write.
| Test/Version | Mean | Min | Max |
|---|---|---|---|
| 23.9 IO Write Bytes/sec (DP) | 3.98 | 0.00 | 265.97 |
| 23.7 I/O Write Bytes/sec (DP) | 41.76 | 0.00 | 2,283.15 |
I/O Read Bytes/sec (Defendpoint)
Shows disk I/O used by the Defendpoint service. A significant decrease was observed for I/O read.
| Series | Mean | Min | Max |
|---|---|---|---|
| 23.9 IO Read Bytes/sec (DP) | 31.47 | 0.00 | 6067.36 |
| 23.7 I/O Read Bytes/sec (DP) | 28,238.12 | 24,547.62 | 34,688.76 |
Memory Testing
For each release, we run through a series of automation tests (covering application control, token modification, DLL control, and event auditing) using a build with memory leak analysis enabled to ensure there are no memory leaks. We use Visual Leak Detector (VLD) version 2.51, which, when enabled at compile time, replaces various memory allocation and deallocation functions to record memory usage. On stopping a service with this functionality, an output file is saved to disk, listing all leaks VLD has detected. We use these builds with automation so that an output file is generated for each test scenario within a suite.
The output files are then examined by a developer, who reviews the results, looking for anything notable. Due to the number of automation tests, only suites that test impacted areas are run, for example, EventAuditJson is run if a release contains ECS auditing changes. If nothing concerning is found, then the build continues to production.
In the 23.9 release, our testing uncovered a memory leak caused by a thread that doesn't stop, unlike other threads initiated by the service, it has been determined that it will not impact the release.
For more information, see Visual Leak Detector.
EPM-W 23.7 Performance Report
Introduction
The aim of this document is to provide data on agreed performance metrics of the (EPM-W) desktop client compared to the previous release.
The content of this document should be used to provide general guidance only. There are many different factors in a live environment which could show different results such as hardware configuration, Windows configuration and background activities, 3rd party products, and the nature of the EPM policy being used.
Performance Benchmarking
Test Scenario
Tests are performed on dedicated VMs hosted in our datacenter. Each VM is configured with:
- Windows 10 21H2
- 4 Core 3.3GHz CPU
- 8GB RAM
Testing was performed using the GA release of 23.7
Test Name
Quick Start policy with single matching rule
Test Method
This test involves a modified Quick Start policy where a single matching rule is added which auto elevates an application based on its name. Auditing is also turned on for the application. The application is trivial command line app and is executed once per second for 60 minutes. Performance counters and EPM-W activity logging are collected and recorded by the test.
The Quick Start policy is commonly used as a base for all of our customers and it can be applied using our Policy Editor Import Template function. It was chosen as it's our most common use case. The application being elevated is a dummy application EXE, which we’ve created specifically for this testing and it terminates quickly and doesn't have a UI, making it ideal for the testing scenario.
Results
Listed below are the results from the runs of the tests on 23.7 and our previous release, 23.6. Due to the nature of our product, we are very sensitive to the OS and general computer activity, so some fluctuation is to be expected.
Rule Matching Latency
Shows the time taken for the rule to match. No significant difference in mean latency was observed.
|
Series |
Mean |
Min |
Max |
|---|---|---|---|
|
23.6 Process Matching Rule Latency (ms) |
5.77 |
3.54 |
19.93 |
|
23.7 Process Matching Rule Latency (ms) |
5.51 |
3.52 |
24.37 |
Processor Time (Defendpoint)
Percentage of processor time used by the Defendpoint service. A small decrease in processor time was observed.
|
Series |
Mean |
Min |
Max |
|---|---|---|---|
|
23.6 % Processor Time (DP) |
3.06 |
2.02 |
4.82 |
|
23.7 % Processor Time (DP) |
2.84 |
1.55 |
5.14 |
Private Bytes (Defendpoint)
Shows the whole size of the memory consumed by the Defendpoint process. A small increase in memory consumption was observed.
|
Series |
Mean |
Min |
Max |
|---|---|---|---|
|
23.6 Private Bytes (DP) |
14,083,881.69 |
11,878,400.00 |
15,073,280.00 |
|
23.7 Private Bytes (DP) |
14,957,248.84 |
12,779,520.00 |
15,843,330.00 |
IO Write Bytes/sec (Defendpoint)
Shows disk I/O used by the Defendpoint service. A small increase was observed for both I/O write and read
|
Series |
Mean |
Min |
Max |
|---|---|---|---|
|
23.6 IO Write Bytes/sec (DP) |
25.74 |
0.00 |
567.85 |
|
23.7 IO Write Bytes/sec (DP) |
41.76 |
0.00 |
2,283.15 |
IO Read Bytes/sec (Defendpoint)
|
Series |
Mean |
Min |
Max |
|---|---|---|---|
|
23.6 IO Read Bytes/sec (DP) |
28,117.99 |
26,066.16 |
31,837.98 |
|
23.7 IO Read Bytes/sec (DP) |
28,238.12 |
24,547.62 |
34,688.76 |
Memory Testing
For each release we run through a series of automation tests (covering Application control, token modification, DLL control and Event auditing) using a build with memory leak analysis enabled to ensure there are no memory leaks. We use Visual Leak Detector (VLD) version 2.51 which when enabled at compile time replaces various memory allocation and deallocation functions to record memory usage. On stopping a service with this functionality an output file is saved to disk, listing all leaks VLD has detected. We use these builds with automation so that an output file is generated for each test scenario within a suite.
The output files are then examined by a developer who will review the results looking for anything notable. Due to the number of automation tests, only suites that test impacted areas are ran, for example, EventAuditJson would be ran if a release contained ECS auditing changes. If nothing concerning is found, then the build is continued to production. For 23.7, our testing did not find anything that would cause us to withhold the release.
For more information, see Visual Leak Detector.
EPM-W 23.6 Performance Report
Introduction
The aim of this document is to provide data on agreed performance metrics of the EPM-W desktop client compared to the previous release.
The content of this document should be used to provide general guidance only. There are many different factors in a live environment which could show different results such as hardware configuration, Windows configuration and background activities, 3rd party products, and the nature of the EPM policy being used.
Performance Benchmarking
Test Scenario
Tests are performed on dedicated VMs hosted in our datacenter. Each VM is configured with:
- Windows 10 21H2
- 4 Core 3.3GHz CPU
- 8GB RAM
Testing was performed using the GA release of 23.6.
Test Name
Quick Start policy with single matching rule
Test Method
This test involves a modified Quick Start policy where a single matching rule is added which auto elevates an application based on its name. Auditing is also turned on for the application. The application is trivial command line app and is executed once per second for 60 minutes. Performance counters and EPM-W activity logging are collected and recorded by the test.
The Quick Start policy is commonly used as a base for all of our customers and it can be applied using our Policy Editor Import Template function. It was chosen as it's our most common use case. The application being elevated is a dummy application exe, which we’ve created specifically for this testing and it terminates quickly and doesn't have a UI, making it ideal for the testing scenario.
Results
Listed below are the results from the runs of the tests on 23.6 and our previous release, 23.5. Due to the nature of our product, we are very sensitive to the OS and general computer activity, so some fluctuation is to be expected. For 23.6, a small increase in processor usages was observed, memory showed a reduction and rules latency and disk IO showed no significant change.
Rule Matching Latency
Shows the time taken for the rule to match. No significant difference in mean latency was observed.
|
Test/version |
Mean |
Min |
Max |
|---|---|---|---|
|
23.6 Process Matching Rule Latency (ms) |
5.47 |
3.54 |
98.28 |
|
23.5 Process Matching Rule Latency (ms) |
5.22 |
3.42 |
21.39 |
Processor Time (Defendpoint)
Percentage of processor time used by the Defendpoint service. A small increase in processor time was observed.
|
Test/version |
Mean |
Min |
Max |
|---|---|---|---|
|
23.6 % Processor Time (DP) |
2.78 |
1.24 |
4.51 |
|
23.5 % Processor Time (DP) |
2.47 |
1.09 |
5.13 |
Private Bytes (Defendpoint)
Shows the whole size of the memory consumed by the Defendpoint process. A small decrease in memory consumption was observed.
|
Test/version |
Mean (MB) |
Min (MB) |
Max (MB) |
|---|---|---|---|
|
23.6 Private Bytes (DP) |
13.082 |
10.972 |
13.941 |
|
23.5 Private Bytes (DP) |
14.259 |
10.921 |
15.273 |
I/O Read and Write (Defendpoint)
Shows disk I/O used by the Defendpoint service. No noticeable difference was observed.
|
Test/version |
Mean (MB) |
Min (MB) |
Max (MB) |
|---|---|---|---|
|
23.6 IO Read Bytes/sec (DP) |
0.026 |
0.025 |
0.043 |
|
23.5 IO Read Bytes/sec (DP) |
0.026 |
0.025 |
0.031 |
|
Test/version |
Mean (MB) |
Min (MB) |
Max (MB) |
|---|---|---|---|
|
23.6 IO Write Bytes/sec (DP) |
0.000039 |
0.00 |
0.0030 |
|
23.5 IO Write Bytes/sec (DP) |
0.000037 |
0.00 |
0.0017 |
Memory Testing
For each release we run through a series of automation tests (covering Application control, token modification, DLL control and Event auditing) using a build with memory leak analysis enabled to ensure there are no memory leaks. We use Visual Leak Detector (VLD) version 2.51 which when enabled at compile time replaces various memory allocation and deallocation functions to record memory usage. On stopping a service with this functionality an output file is saved to disk, listing all leaks VLD has detected. We use these builds with automation so that an output file is generated for each test scenario within a suite.
The output files are then examined by a developer who will review the results looking for anything notable. Due to the number of automation tests, only suites that test impacted areas are ran, for example EventAuditJson would be ran if a release contained ECS auditing changes. If nothing concerning is found then the build is continued to production. For 23.6, our testing did not find anything that would cause us to withhold the release.
For more information, see Visual Leak Detector.
EPM-W 23.5 Performance Report
Introduction
The aim of this document is to provide data on agreed performance metrics of the EPM-W desktop client compared to the previous release.
The content of this document should be used to provide general guidance only. There are many different factors in a live environment which could show different results such as hardware configuration, Windows configuration and background activities, 3rd party products, and the nature of the EPM policy being used.
Performance Benchmarking
Test Scenario
Tests are performed on dedicated VMs hosted in our datacenter. Each VM is configured with:
- Windows 10 21H2
- 4 Core 3.3GHz CPU
- 8GB RAM
Testing was performed using the GA release of 23.5.
Test Name
Quick Start policy with single matching rule
Test Method
This test involves a modified Quick Start policy where a single matching rule is added which auto elevates an application based on its name. Auditing is also turned on for the application. The application is trivial command line app and is executed once per second for 60 minutes. Performance counters and EPM-W activity logging are collected and recorded by the test.
The Quick Start policy is commonly used as a base for all of our customers and it can be applied using our Policy Editor Import Template function. It was chosen as it's our most common use case. The application being elevated is a dummy application exe, which we’ve created specifically for this testing and it terminates quickly and doesn't have a UI, making it ideal for the testing scenario.
Results
Listed below are the results from the runs of the tests on 23.5 and our previous release, 23.3. Due to the nature of our product, we are very sensitive to the OS and general computer activity, so some fluctuation is to be expected. For 23.5, Rule matching latency, Processor time and Memory usage all saw a reduction, whilst disk I/O remained around the same (within a margin of less than 1%).
Rule Matching Latency
Shows the time taken for the rule to match. A small decrease in mean latency was observed.
|
Test/version |
Mean |
Min |
Max |
|---|---|---|---|
|
23.5 Process Matching Rule Latency (ms) |
5.22 |
3.42 |
21.39 |
|
23.3 Process Matching Rule Latency (ms) |
5.66 |
3.52 |
82.16 |
Processor Time (Defendpoint)
Percentage of processor time used by the Defendpoint service. A small decrease in mean processor time was observed.
|
Test/version |
Mean |
Min |
Max |
|---|---|---|---|
|
23.5 % Processor Time (DP) |
2.47 |
1.09 |
5.13 |
|
23.3 % Processor Time (DP) |
2.76 |
1.24 |
6.99 |
Private Bytes (Defendpoint)
Shows the whole size of the memory consumed by the Defendpoint process. A notable decrease in memory usage was observed.
|
Test/version |
Mean (MB) |
Min (MB) |
Max (MB) |
|---|---|---|---|
|
23.5 Private Bytes (DP) |
14.26 |
10.92 |
15.27 |
|
23.3 Private Bytes (DP) |
16.57 |
10.36 |
18.05 |
I/O Read and Write (Defendpoint)
Shows disk I/O used by the Defendpoint service. No notable change has been observed.
|
Test/version |
Mean (MB) |
Min (MB) |
Max (MB) |
|---|---|---|---|
|
23.5 IO Read Bytes/sec (DP) |
0.026884 |
0.024850 |
0.031710 |
|
23.3 IO Read Bytes/sec (DP) |
0.026706 |
0.024847 |
0.036863 |
|
Test/version |
Mean (MB) |
Min (MB) |
Max (MB) |
|---|---|---|---|
|
23.5 IO Write Bytes/sec (DP) |
0.000038 |
0.000000 |
0.001724 |
|
23.3 IO Write Bytes/sec (DP) |
0.000033 |
0.000000 |
0.000924 |
Memory Testing
For each release we run through a series of automation tests (covering Application control, token modification, DLL control and Event auditing) using a build with memory leak analysis enabled to ensure there are no memory leaks. We use Visual Leak Detector (VLD) version 2.51 which when enabled at compile time replaces various memory allocation and deallocation functions to record memory usage. On stopping a service with this functionality an output file is saved to disk, listing all leaks VLD has detected. We use these builds with automation so that an output file is generated for each test scenario within a suite.
The output files are then examined by a developer who will review the results looking for anything notable. Due to the number of automation tests, only suites that test impacted areas are ran, for example EventAuditJson would be ran if a release contained ECS auditing changes. If nothing concerning is found then the build is continued to production.
For 23.5, our testing did not find anything that would cause us to withhold the release.
For more information, see Visual Leak Detector.
EPM-W 23.3 Performance Report
Introduction
The aim of this document is to provide data on agreed performance metrics of the Endpoint Privilege Management for Windows (EPM-W) desktop client compared to the previous release.
The content of this document should be used to provide general guidance only. There are many different factors in a live environment which could show different results such as hardware configuration, Windows configuration and background activities, 3rd party products, and the nature of the EPM policy being used.
Performance Benchmarking
Test Scenario
Tests are performed on dedicated VMs hosted in our datacenter. Each VM is configured with:
- Windows 10 21H2
- 4 Core 3.3GHz CPU
- 8GB RAM
Testing was performed using the GA release of 23.3.
Test Name
Quick Start policy with single matching rule
Test Method
This test involves a modified Quick Start policy where a single matching rule is added which auto elevates an application based on its name. Auditing is also turned on for the application. The application is trivial command line app and is executed once per second for 60 minutes. Performance counters and EPM-W activity logging are collected and recorded by the test.
The Quick Start policy is commonly used as a base for all of our customers and it can be applied using our Policy Editor Import Template function. It was chosen as it's our most common use case. The application being elevated is C:\Windows\System32\ipconfig.exe, which was chosen because it terminates quickly and doesn't have a UI.
Results
Listed below are the results from the runs of the tests on 23.3 and our previous release, 23.1. Due to the nature of our product, we are very sensitive to the OS and general computer activity, so some fluctuation is to be expected.
Rule Matching Latency
Shows the time taken for the rule to match. No notable change has been observed.
|
Test/version |
Mean |
Min |
Max |
|---|---|---|---|
|
23.3 Process Matching Rule Latency (ms) |
5.66 |
3.52 |
82.16 |
|
23.1 Process Matching Rule Latency (ms) |
5.32 |
3.56 |
16.11 |
Processor Time (Defendpoint)
Percentage of processor time used by the Defendpoint service. No notable change has been observed.
|
Test/version |
Mean |
Min |
Max |
|---|---|---|---|
|
23.3 % Processor Time (DP) |
2.76 |
1.24 |
6.99 |
|
23.1 % Processor Time (DP) |
2.72 |
1.09 |
5.60 |
Private Bytes (Defendpoint)
Shows the whole size of the memory consumed by the Defendpoint process. No notable change has been observed.
|
Test/version |
Mean |
Min |
Max |
|---|---|---|---|
|
23.3 Private Bytes (DP) |
17375800.03 |
10866690.00 |
18927620.00 |
|
23.1 Private Bytes (DP) |
17638657.49 |
14401540.00 |
18874370.00 |
I/O Read and Write (Defendpoint)
Shows disk I/O used by the Defendpoint service. No notable change has been observed.
|
Test/version |
Mean |
Min |
Max |
|---|---|---|---|
|
23.3 IO Read Bytes/sec (DP) |
28003.40 |
26054.48 |
38654.06 |
|
23.1 IO Read Bytes/sec (DP) |
28043.81 |
26051.22 |
33294.56 |
|
Test/version |
Mean |
Min |
Max |
|---|---|---|---|
|
23.3 IO Write Bytes/sec (DP) |
34.72 |
0.00 |
969.35 |
|
23.1 IO Write Bytes/sec (DP) |
40.58 |
0.00 |
1832.25 |
Memory Testing
For each release we run through a series of automation tests (covering Application control, token modification, DLL control and Event auditing) using a build with memory leak analysis enabled to ensure there are no memory leaks. We use Visual Leak Detector (VLD) version 2.51 which when enabled at compile time replaces various memory allocation and deallocation functions to record memory usage. On stopping a service with this functionality an output file is saved to disk, listing all leaks VLD has detected. We use these builds with automation so that an output file is generated for each test scenario within a suite.
The output files are then examined by a developer who will review the results looking for anything notable. Due to the number of automation tests, only suites that test impacted areas are ran, for example EventAuditJson would be ran if a release contained ECS auditing changes. If nothing concerning is found then the build is continued to production.
For 23.3, our testing did not find anything that would cause us to withhold the release.
For more information, see Visual Leak Detector.
EPM-W 23.3 Performance Report
Introduction
The aim of this document is to provide data on agreed performance metrics of the EPM-W desktop client compared to the previous release.
The content of this document should be used to provide general guidance only. The are many different factors in a live environment which could show different results such as hardware configuration, Windows configuration and background activities, 3rd party products, and the nature of the EPM policy being used.
Performance Benchmarking
Test Scenario
Tests are performed on dedicated VMs hosted in our datacenter. Each VM is configured with:
- Windows 10 21H2
- 4 Core 3.3GHz CPU
- 8GB RAM
Testing was performed using the GA release of 23.3.
Test Name
Quick Start policy with single matching rule
Test Method
This test involves a modified Quick Start policy where a single matching rule is added which auto elevates an application based on its name. Auditing is also turned on for the application. The application is trivial command line app and is executed once per second for 60 minutes. Performance counters and EPM-W activity logging are collected and recorded by the test.
The Quick Start policy is commonly used as a base for all of our customers and it can be applied using our Policy Editor Import Template function. It was chosen as it's our most common use case. The application being elevated is C:\Windows\System32\ipconfig.exe, which was chosen because it terminates quickly and doesn't have a UI.
Results
Listed below are the results from the runs of the tests on 23.3 and our previous release, 23.1. Due to the nature of our product, we are very sensitive to the OS and general computer activity, so some fluctuation is to be expected.
Rule Matching Latency
Shows the time taken for the rule to match. No notable change has been observed.
|
Test/version |
Mean |
Min |
Max |
|---|---|---|---|
|
23.3 Process Matching Rule Latency (ms) |
5.66 |
3.52 |
82.16 |
|
23.1 Process Matching Rule Latency (ms) |
5.32 |
3.56 |
16.11 |
Processor Time (Defendpoint)
Percentage of processor time used by the Defendpoint service. No notable change has been observed.
|
Test/version |
Mean |
Min |
Max |
|---|---|---|---|
|
23.3 % Processor Time (DP) |
2.76 |
1.24 |
6.99 |
|
23.1 % Processor Time (DP) |
2.72 |
1.09 |
5.60 |
Private Bytes (Defendpoint)
Shows the whole size of the memory consumed by the Defendpoint process. No notable change has been observed.
|
Test/version |
Mean |
Min |
Max |
|---|---|---|---|
|
23.3 Private Bytes (DP) |
17375800.03 |
10866690.00 |
18927620.00 |
|
23.1 Private Bytes (DP) |
17638657.49 |
14401540.00 |
18874370.00 |
I/O Read and Write (Defendpoint)
Shows disk I/O used by the Defendpoint service. No notable change has been observed.
|
Test/version |
Mean |
Min |
Max |
|---|---|---|---|
|
23.3 IO Read Bytes/sec (DP) |
28003.40 |
26054.48 |
38654.06 |
|
23.1 IO Read Bytes/sec (DP) |
28043.81 |
26051.22 |
33294.56 |
|
Test/version |
Mean |
Min |
Max |
|---|---|---|---|
|
23.3 IO Write Bytes/sec (DP) |
34.72 |
0.00 |
969.35 |
|
23.1 IO Write Bytes/sec (DP) |
40.58 |
0.00 |
1832.25 |
Memory Testing
For each release we run through a series of automation tests (covering Application control, token modification, DLL control and Event auditing) using a build with memory leak analysis enabled to ensure there are no memory leaks. We use Visual Leak Detector (VLD) version 2.51 which when enabled at compile time replaces various memory allocation and deallocation functions to record memory usage. On stopping a service with this functionality an output file is saved to disk, listing all leaks VLD has detected. We use these builds with automation so that an output file is generated for each test scenario within a suite.
The output files are then examined by a developer who will review the results looking for anything notable. Due to the number of automation tests, only suites that test impacted areas are ran, for example EventAuditJson would be ran if a release contained ECS auditing changes. If nothing concerning is found then the build is continued to production.
For 23.3, our testing did not find anything that would cause us to withhold the release.
For more information, see Visual Leak Detector.
