[GH-ISSUE #1705] Limit All Clients view #1063

New issue

Open

opened 2026-03-02 02:20:55 +03:00 by kerem · 3 comments

kerem commented

2026-03-02 02:20:55 +03:00

Owner

Originally created by @nomadusje on GitHub (Dec 15, 2023).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1705

We have 1500 devices in TRMM. When we click on "All Clients" it takes a long time to load because it shows all 1500 agents. We use "All Clients" because of the search function. We want to search for a specific user or hostname in all sites/clients.

It would be better if the first result of "All Clients" is limited to 20, 50 or 100 devices. When you scroll down, it would load another 20, 50 or 100. When you search, it will search all 1500 devices.

Originally created by @nomadusje on GitHub (Dec 15, 2023). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1705 We have 1500 devices in TRMM. When we click on "All Clients" it takes a long time to load because it shows all 1500 agents. We use "All Clients" because of the search function. We want to search for a specific user or hostname in all sites/clients. It would be better if the first result of "All Clients" is limited to 20, 50 or 100 devices. When you scroll down, it would load another 20, 50 or 100. When you search, it will search all 1500 devices.

kerem added the

enhancement

label

2026-03-02 02:20:55 +03:00

kerem commented

2026-03-02 02:20:55 +03:00

Author

Owner

@wh1te909 commented on GitHub (Dec 18, 2023):

I am aware of the slow load times. The real solution is to add more caching and optimize queries (which we have been working on, if you think dashboard load times are slow, it was waaay worse before). So still work to be done. Searching is currently done all client side, hence the need for all data to be loaded beforehand. Better to have one slow load time but search be instant.

Just curious how long does it take to load "All Clients" with 1500 agents for you? Hardware will obviously impact this as well, I've seen people with 200 devices load slower than someone with 900 devices depending on hardware.

@wh1te909 commented on GitHub (Dec 18, 2023): I am aware of the slow load times. The real solution is to add more caching and optimize queries (which we have been working on, if you think dashboard load times are slow, it was waaay worse before). So still work to be done. Searching is currently done all client side, hence the need for all data to be loaded beforehand. Better to have one slow load time but search be instant. Just curious how long does it take to load "All Clients" with 1500 agents for you? Hardware will obviously impact this as well, I've seen people with 200 devices load slower than someone with 900 devices depending on hardware.

kerem commented

2026-03-02 02:20:55 +03:00

Author

Owner

@nomadusje commented on GitHub (Dec 18, 2023):

Hi, it takes about 12 seconds to load the "All Clients" page with 1500 agents. We run a VM on a AMD Epyc 7443 with 16 virtual cores and 32 GB RAM. When I click on a single site/customer, it's almost instant.

The hardware usage is 40% CPU and 22 GB RAM at peak times.

@nomadusje commented on GitHub (Dec 18, 2023): Hi, it takes about 12 seconds to load the "All Clients" page with 1500 agents. We run a VM on a AMD Epyc 7443 with 16 virtual cores and 32 GB RAM. When I click on a single site/customer, it's almost instant. The hardware usage is 40% CPU and 22 GB RAM at peak times.

kerem commented

2026-03-02 02:20:55 +03:00

Author

Owner

@silversword411 commented on GitHub (Dec 20, 2023):

The database query is a gnarly beast to get all the data necessary for that initial table to populate. I'm pretty sure it's the database queries that are compiling that pay load to deliver that's the big time suck.

2023-12-19_235355 - brave_Tactical_RMM_-_Brave

I think the status indicator is one query...almost want to lazy load that, but then then availability filters wouldn't be accurate till it finished transferring.

@silversword411 commented on GitHub (Dec 20, 2023): The database query is a gnarly beast to get all the data necessary for that initial table to populate. I'm pretty sure it's the database queries that are compiling that pay load to deliver that's the big time suck. <img width="343" alt="2023-12-19_235355 - brave_Tactical_RMM_-_Brave" src="https://github.com/amidaware/tacticalrmm/assets/13395348/4f5d7b50-1ffd-475d-a87d-e921071faa73"> I think the status indicator is one query...almost want to lazy load that, but then then availability filters wouldn't be accurate till it finished transferring.

kerem referenced this issue

2026-03-14 04:45:36 +03:00

[GH-ISSUE #1063] ParrotOS with systemd not working #2597