Problem with image uploading

[korosa]

Please help me solve the problem. Images and videos take a very long time to process when uploading to the site. The upload to S3 itself is fast, but the "processing" takes a long time — around 20 seconds per image or video. As a result, uploading a folder with around 100 files takes a lot of time.

It's important to note that the upload directly to the server is fast. What could be the issue? I’ve tried different S3 services, and the problem doesn’t seem to be related to that.

33fps upload

 

[Rodolfo]

Processing doesn't take that long, check if you have a proxy without a cap on post body max size.

When using a proxy (for example nginx) you may configure a body max size which when unlimited cause the connection to keep waiting for several seconds.

 

[korosa]

Processing doesn't take that long, check if you have a proxy without a cap on post body max size.

When using a proxy (for example nginx) you may configure a body max size which when unlimited cause the connection to keep waiting for several seconds.

Thank you for your response. However, I'm using Apache, so this probably isn't suitable for me. Could you suggest any other options? Thx

 

[Rodolfo]

around 20 seconds per image or video

In that context the most expensive CPU call is the hashing function on the uploaded file, which up to 4.2.5 uses md5 (and it does it twice). There's an RFC for upgrading to xxh64, which will be merged in 4.3.0.

md5 hashing is only a concern for files of certain size (64 MB up?), for small files it should be instant. You should also check the network responses.

You could try using xrDebug to determine where it goes slow.

// <actual code>
xr(__LINE__);
// <actual code>

By adding xr(__LINE__) you will get the line in the debugger plus its time, by doing this you can label the code at different parts and determine how long does it take to get there by simply running Chevereto.

 

[korosa]

In that context the most expensive CPU call is the hashing function on the uploaded file, which up to 4.2.5 uses md5 (and it does it twice). There's an RFC for upgrading to xxh64, which will be merged in 4.3.0.

md5 hashing is only a concern for files of certain size (64 MB up?), for small files it should be instant. You should also check the network responses.

You could try using xrDebug to determine where it goes slow.

// <actual code>
xr(__LINE__);
// <actual code>

By adding xr(__LINE__) you will get the line in the debugger plus its time, by doing this you can label the code at different parts and determine how long does it take to get there by simply running Chevereto.

I finally had some free time and also got tired of the slow upload speed. Please help me resolve this issue or suggest what I can do.

Here’s the current situation:

1. I couldn’t manage to use xr(LINE).
2. My PHP settings are:

• max_execution_time = 300
• max_file_uploads = 20
• max_input_time = 60
• memory_limit = 512M
• post_max_size = 256M

1. I’ve tested three different S3 services.
2. I’ve used different browsers and various files.
3. I updated Chevereto to version 4.3.6.
4. When uploading to the local disk, files upload very quickly, in parallel, and without issues. But as soon as I switch to S3, the upload becomes very slow (the spinner keeps spinning). Upload time for each file via S3 ranges from 4 to 20 seconds (based on the browser’s Network tab). For example:

Request timing:

• Blocked: 0 ms
• DNS lookup: 0 ms
• Connection: 0 ms
• TLS setup: 0 ms
• Upload: 142 ms
• Waiting: 19.42 s
• Receiving: 0 ms

 

[Rodolfo]

When you are using Upload Stoage the server needs to send that file to the storage server, that process depends on several factors like filesystem and network. It also vary depending on the Storage API and service being used, for example "S3 Compatible" is not actually the same as AWS S3 API, the one from Amazon is way more robust and complete, the other ones are just commercial polyfills.

At this point what matters the most is to gather usable information like Storage API, service provider, os, filesystem, etc.

 

[korosa]

When you are using Upload Stoage the server needs to send that file to the storage server, that process depends on several factors like filesystem and network. It also vary depending on the Storage API and service being used, for example "S3 Compatible" is not actually the same as AWS S3 API, the one from Amazon is way more robust and complete, the other ones are just commercial polyfills.

At this point what matters the most is to gather usable information like Storage API, service provider, os, filesystem, etc.

Would you be able to recommend a few services (preferably several) that are known to work well with S3, so I can test them and rule out potential issues? Unfortunately, I’m not able to test Amazon S3, Google Cloud, Microsoft Azure, or Alibaba at the moment. I’m currently using Backblaze S3 configured via S3 Compatible.

Spoiler

Server data from Chevereto dashboard:
Server: Apache/2.4.52 (Ubuntu) ~ v862735898.local
Linux/apache2handler


MySQL: 8.0.42-0ubuntu0.22.04.1
Uptime: 1275303
Threads: 3
Questions: 7,484,377
Slow queries: 1,147
Opens: 2,350
Flush tables: 3
Open tables: 1,122
Queries per second avg: 5.868


Cache: Disabled


PHP version: 8.2.28
Max execution time: 300 seconds
Memory limit: 512 MB


Graphics library:
GD Version bundled (2.1.0 compatible)
JPEG: enabled
GIF: read/write
PNG: enabled
WEBP: enabled
WBMP: enabled
XBM: enabled


ExifTool:
ExifTool bin: exiftool
ExifTool binary not found in PATH


ExifTran:
ExifTran bin: exiftran
ExifTran binary not found in PATH


FFmpeg:
FFmpeg bin: /usr/bin/ffmpeg
FFprobe bin: /usr/bin/ffprobe
Version: 4.4.2-0ubuntu0.22.04.1


Max upload file size: 256 MB
Encryption: Enabled


From server panel:
CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz (3 cores)
RAM: 1127 / 3911 MB
Disk space: 39.26 GB
Swap: 0 MB
Load average (1, 5, 15 min): 0.27 0.24 0.14

 

[Rodolfo]

Would you be able to recommend a few services (preferably several) that are known to work well with S3

I really doubt this is provider related, unless your server is really far away from the storage datacenter. You should be aware that the process can't be instant as local uploads and won't be ever that fast. That's impossible, because it needs to send the file to the server from client, then Chevereto needs to send the file (again) to the external storage server so the process requires time.

In this case the buffer that is being perceived could it be the allocation required to prepare the file for sending from Chevereto to the external storage server, as it needs to read the file and send it to the external storage server, it takes double time to read + send.

Contrary to the client to Chevereto chunked upload process, which happens on parallel and is very memory efficient, uploading to the external storage server is still carried on a single call without chunking.

At this time your only options is to get a server closer and get faster drives.