If many images need to be processed at the same time, the server capacity could be exhausted for a long period of time. The application server has limited computing power, which is set upfront, and is not well-suited for burst request handling.This could increase the general response time because of the greater workload on the CPU The images are processed on the application server.It is then transformed in three different formats used in different places of the front-end application: 800圆00px, 400x300px, and 200x150px.īeing a Ruby on Rails developer, my first approach was to use a RubyGem - in particular Paperclip or Dragonfly, which both make use of ImageMagick for image processing.Īlthough this implementation is quiet straightforward (since it it mostly just configuration), there are different drawbacks that could arise: In one of my last projects, a marketplace web application where users have to upload an image of a product they want to sell, the original image is first cropped to the correct image ratio (4:3). ![]() In this article I am going to describe a serverless architecture based on AWS, that is extremely scalable and cost-efficient.īut let’s start from the beginning. Each time an application allows a user to upload an image, it is very likely that this image needs to be pre-processed before it is served to a front-end application. Image pre-processing is a task required by many web applications. In this article, I am going to describe how I moved a heavy task like image pre-processing from my application server to a completely serverless architecture on AWS in charge of storing, processing and serving images. By Domenico Angilletta How to boost your performance with serverless architecture Photo by Jesse Darland on Unsplash
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |