Snipe-IT slow when using pre-designed view filters

[novatchyk-84]

When using pre-designed asset (or component) filters for the amount of records to be displayed (10,20,30,50,100,150,200,500) it appears that SnipeIT gets slower and slower, eventually hitting almost a 'stuck' position with the "500" value.
I'd assume that this is caused by the amount of information displayed within the GUI, but is that also linked to the filters applied to my view setup?
I've opened different "Feature request" ticket which is directly linked to this issue, whereas I am not able to Download ALL of the recorded components, so when generating one myself I have to run a download for each individual page.

Displaying "500" records would allow me to do the process much faster, especially when having over 2000 components within the DB, but with the slow performance of the GUI, this is impossible.

I'm currently using SnipeIT Version v8.3.1 - build 19577 (master)

[uberbrady]

What exactly do you mean when you say "pre-designed asset (or component) filters" - are you talking about using search terms in the 'Search' box near the upper-right of the table? If so, do you find that not using those search terms is actually faster? Which column are you sorting by - do different columns to sort by give you different results? It sounds like you have 2000-ish components in the system, how many assets do you have (roughly)?

Is this system exposed to the public? If not, you might want to consider turning on APP_DEBUG in your .env file. But this setting can be dangerous as it can expose secrets, so you'd only want to do this in a trusted environment. With APP_DEBUG turned on, you can use DebugBar (a little Laravel icon in the lower-left) to trace the queries - the 'queries' tab is a stack of disks, fifth icon over from the left. If you see a ton of duplicated queries then we might have a "thousand-and-one queries" problem. If, instead, you see some queries that seem like they're taking a really long time, then we might have an indexing issue. Or, if that section all seems fine, maybe it's something else.

[snipe]

More info on the debugger here: https://snipe-it.readme.io/docs/advanced-debugging

Snipe-IT Documentation

Advanced Debugging

Snipe-IT ships with the Laravel Debugbar, an amazing piece of software that lets you introspect much further into the framework and application to troubleshoot issues that may be a little harder to track down. To enable the debugbar, set the following in your .env file, and clear your config cache: …

[novatchyk-84]

sorry for not being specific enough.
This is the section I was referring to.

[swift2512]

@uberbrady Snipe-IT today feels a bit less responsive than it was few month ago. I also receive complaints from admins that pulling lists takes ages. And it really is slow when I set rows per page to 500 or 1000 (in Assets > List all). I've measured times and it takes 30-40 seconds to load a table. On DEMO, 500 rows per page with all fields checked loads in 8-10 seconds on my machine. Page itself loads in less than two seconds, but table hangs on ' Loading... Please wait...' for some time.
Number of items or custom fields didn't change on my system for the last 3 months, correction to custom fields were minimal. Basically, with all columns enabled in Assets View and with 1000 rows per page, clicking through pages pushes RAM usage to 2.7GB on that Edge tab. (I have 15k assets and 20 custom fields.) I blame sticky columns for this 😃

[snipe]

@swift2512 we've literally been talking about that here for two weeks. See #18512, #18356, #18472, #18511, and #18561

[snipe]

I've just reverted the change that we suspect caused the slowness. If anyone watching this thread would like to pull from develop or master and see if that reversion helps, that would be very useful.