Applixure Agent is designed to have as low impact as possible on the devices it is installed on so as not to cause any performance issues by itself.
However, depending on the usage profile of the device and software installed on it, the amount of work and data that the Applixure Agent has process may vary. If there are number of concurrent users (such as in RDSH scenarios) and/or lot of software used concurrently, the amount of data that Agent tracks naturally increases. This makes it impossible to state exactly the amount of computing resources required on a constant basis.
Applixure Agent uses both event-driven passive monitoring (for things like detecting software crashes, software inventory etc.) and active monitoring (for things like application usage, responsiveness, etc.) and thus the CPU load may change from less than 0.1% to occasional 20-30% usage when larger data sets are being processed. On average, the usage is less than 1% of the CPU capacity.
Futhermore, Applixure Agent purposefully drops its processes' Windows scheduling priority into Below Normal level in order to make sure that Agent will always yields to any more criticial processes even in [short] times of high CPU use during certain operations.
The usage of the memory is highly dependent on the amount of software being used, amount of monitored events, concurrent sessions etc. which means that it can easily range from 20 MB to over 100 MB of memory usage, but on average it should be well under 100 MB on even a busy system.
When looking at the memory usage by Applixure Agent, it is however very important to understand that since the Agent is executed by the .NET Runtime, the memory usage shown in Windows Task Manager does not tell the whole picture of the actual memory usage. Memory usage by .NET programs is non-deterministic in nature from the perspective of the program being run, because the .NET Runtime itself manages the actual memory allocations from Windows for those processes, and does not necessarily free unused portions of the memory immediately back to the system unless there is a memory pressure from other processes in the system. In other words, this means that even though the Task Manager may show some specific value of the memory usage for Applixure Agent it may not actually use that much memory internally, but the .NET decides to keep it reserved for the process for the time being in any case.
For the Mac version of the Applixure Agent, the Swift runtime manages the Agent's process' memory in very similar manner to how .NET Framework works on the Windows platform, making the actual decisions to allocate or free memory from the operating system which may cause "incorrect" memory usage values shown in Activity Monitor etc.
For the disk space, Applixure Agent consumes very little disk space for its own purposes, mainly consisting of the update files (few megabytes in size per update) and the local cache for the data (typically few tens of megabytes in size).
Network -usage wise, Applixure Agent is designed to use only that amount of network bandwidth that it needs to update itself [automatically] and transfer the delta of the data that's been cached.
Like mentioned above for other metrics, it is impossible to state exactly how much bandwidth is being used by a single agent in any given point of time as the amount of data needed to be transferred varies depending on how much usage or activity there has been on a device. Agent will try to send pending data at minimum of every four hours but sometimes may send data sooner if certain relevant changes to the configuration are detected and/or if the agent process is restarted for any reason.
By average the amount of data transferred [outbound] is around 2-4 kilobytes / agent per communication attempt. This is not necessarily true for the initial synchronization the Agent is doing after installation, as more baseline data needs to be sent at that stage, or if there has been lot of new software installations. Another bandwidth consuming operation is when the Agent auto-updates itself, which happens at minimum 12 hours interval should there be any updates at that time. Usually these updates are only published once a week or even more infrequently. The amount of data being transferred [inbound] during update is 3 - 4 megabytes.