Processing images is extremely slow

Summary

The “Processing” stage of uploading images with a large resolution (larger than 1500 pixels in one dimension) takes extremely long

Steps to reproduce

Using version 5.11.0, but this problem also existed on 5.9.0. It wasn’t always like this, however, the processing stage got slower and slower as time went on.
How to reproduce, try to upload an image with a large resolution. Might only be on my server, though.

Expected behavior

Processing should probably not take that long.

Observed behavior

The actual uploading of the image happens fairly quickly, but then gets seemingly stuck at the processing stage. Sometimes it finishes in around 3-6 minutes, sometimes even longer than 15 minutes where I stopped waiting.
I have tried observing the data directory and the logs when I try to upload images to the server, but the logs only tell about finished jobs from various workers, no error messages, even at debug output level.
The data directory contains the image as expected, but then gets stuck when creating the thumbnail and preview images.
All users on my server are affected, and it seems to only fail at large resolutions, not necessarily at large files. A 3000x2000 JPEG compressed to 80 kB failed to upload, but a binary file with 500 kB was done instantly.

Any ideas on what the issue could be? I’m kinda at a loss.

Hi @QuappaX,

What device, OS and OS version do you see this on?

Oh sorry, totally forgot to mention this.

The server is a Raspberry Pi 3 Model B+, running Raspbian Stretch, kernel version 4.14.98-v7+

Hi @QuappaX, would you be open to sharing your settings related to files: https://docs.mattermost.com/administration/config-settings.html#files, as well as this setting: https://docs.mattermost.com/administration/config-settings.html#allow-untrusted-internal-connections-to?

@amy.blais Sure.

File Storage System: Local File System
Local Storage Directory: “./data/”
Amazon S3 Bucket: none
Amazon S3 Region: none
Amazon S3 Access Key ID: none
Amazon S3 Endpoint: none
Amazon S3 Secret Access Key: none
Enable Secure Amazon S3 Connections: false
Enable Amazon S3 Debugging: false
Allow File Sharing: true
Maximum File Size: 8 MB
Enable Image Proxy: false
Image Proxy Type: none
Remote Image Proxy URL: none
Remote Image Proxy Options: none

Allow untrusted internal connections to: none

I should mention that I have the Open Source version, so I’m missing settings available for Enterprise.

Hi @QuappaX,

This (Raspberry Pi 3B+) is an unsupported architecture (arm64). Furthermore, it’s not that great in regards to compute power and memory. Would you be open to trying if you can reproduce the issue on a supported architecture? List is here: https://docs.mattermost.com/install/requirements.html#software-requirements.

1 Like

@amy.blais

Of course. I will set up a server on a supported architecture as soon as I get to it, and I will respond when I tried reproducing it.

I’ve the same issue on my ARM server. We use Mattermost for company internal usage only, is there any way to disable this very slow “processing image”?

Mattermost version: dev-linux-arm-v5.30.1
Storage: local

Everything else has good performances, search, sending message, PDF and others files uploads, etc. Only “Image processing” after uploading an image is crazy slow.

Or if anyone know what I could change in the Mattermost source code to improve the situation?
I’m OK to disable the thumbnail generation or anything which cause this issue :sweat_smile:.

2880 × 18481 pixels picture on Mattermost Version: 7.4.0 Database Schema Version: 93 Database: postgres using the web interface on a Macbook Pro - it’s been “Processing” for half an hour now. No ETA, no information what “processing” means. I’d rather have my picture uploaded unprocessed as a file, so the other parties can download and look at it, than have an hour long delay in the process.

Hi @tuexss and welcome to the Mattermost forums!

While trying to reproduce that (had quite a hard time to find such a beast of an image), I found out that this only happens when the image size is larger than the value of MaxImageResolution in your config.json.
As a workaround, you can just increase this value to a value larger than 2880*18481:

root@ag-ubuntu0101:~# mmctl --local config get FileSettings.MaxImageResolution
60000000
root@ag-ubuntu0101:~# echo 2880*18481 | bc
53225280

When I change this value to something lower than 53225280, the image is stuck in “Processing” forever since the memory limit is being reached and the client does not handle that properly, but when you give the server process enough memory, it completes in a decent time (at least for the biggest image I could find on the web).

hey, thanks for the fast reply. those large pictures are common when taking screenshots of websites that go from header to footer. that’s a good find with the config setting. but do you know what “processing” needs to be done, and why it takes so much memory? I could only imagine resizing or converting and that should both be quite quick and not heavy on memory. It would be nice if the error handling was better, and maybe even if a fallback to transfering as a regular file would be supported. Especially in QA you sometimes have image files that are broken or extreme on purpose, and processing isn’t even expected - having to wrap it in a zip first would be quite annoying. Currently I have to evade to email.

I can’t answer your questions, I can only relay to them to the developers but wanted to make sure that the issue can be worked around on your setup by increasing the MaxImageResolution variable to confirm that this actually the same behaviour on your end before I escalate this issue further.

This is definitely a bug. If the image exceeds max resolution, then the server throws an error which the client should show up. There seems to be some related issues around this upload image code path where the client just shows “processing …” and nothing else. I am thinking this is a symptom of the same root cause: [MM-49088] - Mattermost

EDIT: this is the actual ticket: [MM-49621] - Mattermost