High cpu usage when using cp asset browser

rrelmy commented 2 years ago

Bug description

In bigger assets collection with nice high resolution images browsing in the asset browser causes high cpu usage on the server. Sometimes the CPU usage and IO throughput stays at 100% for >5min and block the server completely.

We have enabled config('statamic.assets.cache') but it does not seem to affect cp thumbnails

How to reproduce

Create an asset collection with some big high-res images.
Open the CP and scroll through the asset browser pages
Check the cpu usage on the server

To increase the effect disable browser caching to force the browser to download the images again

Logs

No response

Environment

Statamic 3.3.23 Pro
Laravel 8.83.22
PHP 8.1.8
edalzell/forma 1.2
rias/statamic-redirect 2.4.0
silentz/mailchimp 2.9.1
statamic/collaboration 0.4.0
statamic/seo-pro 3.1.0

Installation

Fresh statamic/statamic site via CLI

Antlers Parser

regex (default)

Additional details

No response

jasonvarga commented 2 years ago

Is the CPU spike happening on the server or client?

rrelmy commented 2 years ago

On the server, I updated the description to reflect that.

jasonvarga commented 2 years ago

You said you can disable browser caching to force the images to download again. Are you saying that the CPU still spikes when you are browsing images that have already had their thumbnails generated?

If you were to actually clear the glide cache then browse the listing, I could see the CPU spike since it has to actually do the expensive image manipulation.

But for already generated images... that's odd.

rrelmy commented 2 years ago

You said you can disable browser caching to force the images to download again. Are you saying that the CPU still spikes when you are browsing images that have already had their thumbnails generated?

Yes, I am not sure if it's generating new thumbnails, but the requests are visible on the server and use quite some CPU per request, is there an easy way to check if the image was served from cache?

Maybe it's just the amount of requests that are handled through laravel that cause the total usage

statamic / cms