I am currently working at Rubick.ai OMS (order management system) and we encountered few performance bottlenecks when loading images from AWS S3.
Initially, we directly fetched these images from S3, a process that generally worked well but occasionally resulted in longer loading times, with certain images taking up to 1 second to load.
Upon some research, a noteworthy discovery emergedβAWS S3 utilizes the HTTP 1.1 protocol. This led me to a deeper understanding of the challenges posed by HTTP 1.1, particularly the inherent limitation of opening only six connections per domain.
Consequently, when the browser-initiated requests for numerous resources from S3, it often became stalled, necessitating the opening of new connections after the initial six. This behavior was identified as a key contributor to the observed delays in image loading times.
To solve this issue, I implemented a Content Delivery Network (CDN), a widely recognized solution for optimizing the delivery of web content.
AWS has a CDN solution as CloudFront, so it was configured to serve all images and files, mitigating the limitations imposed by S3's use of HTTP 1.1.
The impact of this transition was vividly demonstrated when a profile picture, initially taking approximately 1.5 seconds to load from S3, was seamlessly reduced to a mere ~155 milliseconds after the migration to CloudFront.
Different Http Protocol:
HTTP/1.0:
- Simple request-response model.
- Each request opens a new connection, leading to performance inefficiencies.
HTTP/1.1:
- Persistent connections to reuse a single connection for multiple requests.
- Limited to six simultaneous connections per domain, potentially causing delays.
HTTP/2:
- Multiplexing allows multiple requests and responses over a single connection simultaneously.
- Header compression reduces overhead, improving performance.
- Prioritization of requests for optimized resource loading.
HTTP/3:
- Based on Google's QUIC protocol.
- Focuses on improving performance over unreliable networks.
- Multiplexing and encryption are integral components.
Compressing the Response
Furthermore, we addressed another performance bottleneck related to API responses, where the size ranged from 25 KB to 100 KB.
In this context, we implemented gzip compression, a technique aimed at reducing the size of transmitted data. Gzip compression resulted in an impressive 4x to 9x reduction in response size, contributing to improved overall system efficiency.
To dive deeper into compression, it is a process of encoding data to reduce its size for efficient transmission over networks. Gzip is one of the widely used compression algorithms, applying the DEFLATE algorithm to compress data.
Other compression algorithms, such as Brotli, are also gaining popularity due to their superior compression ratios. The benefits of compression extend beyond reduced data transmission size; they include faster loading times, lower bandwidth consumption, and ultimately, an enhanced user experience.
These optimizations not only resolved the challenges associated with S3's limitations but also significantly enhanced the overall speed, efficiency, and user experience of our system.
Top comments (0)