In order to solve this problem, we enabled color quantization in Libvips. The top 10 heaviest banners were caused by oversized PNGs. In the meantime, one of our automated tests reported that 8% of our banners were too heavy, where a failure is defined as: the banner weight exceeds 800KB for width = 970 pixels. We strongly improved the image processing time:
IMAGEMAGICK OPENCL BENCHMARK PATCH
The maintainer merged a complementary patch with a different approach: falling back to a default ICC profile. We reported the issue and we implemented a straightforward conversion algorithm in Libvips. Also, CMYK to sRGB color space conversion was a missing feature. Thanks to the high throughput of processed images, we discovered and contributed to fix two issues in Libvips: a segmentation fault when saving a PNG image, and a memory leak. Thus, we deployed two applications in production during three months: a reference with ImageMagick and a test app with Libvips. Performance comparison between Libvips and ImageMagick Testing in productionįollowing these promising results, we decided to test Libvips with real traffic. Up to x8 on JPEGs and x2.3 on PNGs with 8 threads.Up to x4 on JPEGs with 1 thread, slight improvement on 4k PNGs.We tested our wrapper on some product images with a real scenario for measuring its performance compared to ImageMagick and the JNI overhead cost.įirst, we ran a simple benchmark which read an input, resized it, wrote back into a memory buffer. Proof of conceptĪt the beginning, we started to implement a tiny Java wrapper using Java Native Interface to call some Libvips functions chosen according to our use case. Thus, we decided to test this library in our application. The maintainers are continuously experimenting new implementations to bring more performance (e.g.: libspng). Another advantage to Libvips is its pro-active community. We found some interesting benchmarks which demonstrate a good scalability, an impressive speed up and memory usage compared to other libraries, expecting up to 5.5 times faster than ImageMagick. Libvips is a processing image library, written in 1990, oriented on concurrency and low memory needs. We were very frustrated by the performance of this library according to the necessity to process images as fast as possible in our context. Indeed, the refresh of a customer catalog with many PNGs triggered significant CPU utilization peak. We observed a lack of concurrency and processing operations on PNGs were a bottleneck with ImageMagick. So far, our application was using a Java wrapper of ImageMagick for image related computations. These operations have a certain CPU cost and a significant impact on request latency. We process more than 18k images per second, applying some basic operations like resizing, cropping or padding.
This service handles up to 170k queries per second worldwide, at peak time.
This application stores, serves and processes our customers product images. To handle this traffic, we developed our own Content Delivery Network. Thanks to our dynamic creative generation pipeline, Criteo creates optimized banners with a set of recommended products the user is interested in.Įach day billions of product images are displayed across the Web. Criteo displays billions of personalized ads a per day.
0 kommentar(er)
