Introducing the image resizer service

Monday Dec 20

Squidex performance is mainly driven by external services like MongoDB. To improve scalability it is important to keep CPU work low. Therefore a small microservice has been introduced to outsource image resizing.

Like most webservices Squidex is mainly driven by IO. This means that most of the time, when a request is handled, Squidex waits for the database or the client to accept the response. Therefore Squidex should usually scale well and does not need powerful servers as long as the database is fast enough.

The only exception to this is resizing images. This is a complex task, because most images are compressed. For example PNG is just ZIP compression. Therefore to resize an image you have to load the file to the server, load it (decompression), resize it in memory, compress it again and sent it back. Of course this is much slower than most other tasks that Squidex would perform. We use Imagesharp for this task for most formats in combination with ImageMagikck for WebP and TGA images.

It is really impressive how fast these libraries are now, given that they are Open Source and build as hobby project and that they are not built in C++. But C# has many features to make usage of the newest hardware instructions of modern CPUs and the team behind ImageSharp is just amazing.

Image ResizingImage Resizing

But nevertheless, if you have a 5MB photo and want to shrink it down to a 300x200 pixels it will take a while and it will need a lot of CPU time. If this would take only 2 seconds (2000 milliseconds), it would probably take as much time as 200 to 400 normal requests and of course this is a problem. Therefore small microservice was built to outsource these tasks to another service. This does not mean that it will be faster to resize an image, but from the perspective of the Squidex API it is just an external process and while the Thread that accepted to request to resize the image is waiting for the result it can handle other HTTP requests.

This micro-service is available as a docker image and it is easy to install:

It has no dependencies and does not need a database to run. Therefore you can just install it on your server or kubernetes cluster and you can also use managed services like google cloud run ( for infinite scalability. It is really recommended to host it in the same network as your Squidex machines because it does not have authentication and you do not want to pay for traffic.

In Squidex (starting with 6.4.0) you can just configure the ASSETS__RESIZERURL environment variable to point to the resizer. You can use this yaml file for kubernetes: Then your URL would be: http://resizer.default.svc.cluster.local.

Have you tried it out? I would like to get your feedback.