Improving Glide image server response by 6x with PHP-PM and zero code changes

Joe Cohen
3 min readJan 9, 2018

--

The PHP League Glide project it’s an “easy on-demand image manipulation library written in PHP”. It uses an HTTP API to manipulate images on the fly similar of what services like services like Imgix and Cloudinary, but self hosted.

We’ve use this project many times as a standalone library or as a self hosted service and it’s really great! However when used on high traffic projects or scaling the service into many servers it can be tricky and very slow since it uses PHP to process and serve static files.

Last week we’ve experimented switching one of our images services from PHP-FPM to PHP-PM written in Laravel Lumen and using Glide.

The cool thing it’s that we didn’t change a line code! (only server config)

PHP-PM is a new PHP process manager using ReactPHP (an “Event-driven, non-blocking I/O with PHP”) underneath, that focuses in making modern PHP applications fast by spawning several PHP instances as workers with your application bootstrapped and stored in memory prepared for every incoming request, and the results are very impressive!

The tests below were made on two Linode’s with 4GB on RAM and 2 CPU’s, both with php 7.2 but one running PHP-FPM and the other PHP-PM.

We ran ab -c 10 -n 1000 http://path on each server and here are the results:

Server running php-fpm with php-7.2 and opcache

Document Path:          /images/img_growth.png
Document Length: 35908 bytes
Concurrency Level: 10
Time taken for tests: 133.043 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 36317000 bytes
HTML transferred: 35908000 bytes
Requests per second: 7.52 [#/sec] (mean)
Time per request: 1330.430 [ms] (mean)
Time per request: 133.043 [ms] (mean, across all concurrent requests)
Transfer rate: 266.57 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 65 70 3.5 70 89
Processing: 670 1219 267.6 1199 6120
Waiting: 602 1148 267.5 1128 6049
Total: 738 1290 267.9 1269 6188
Percentage of the requests served within a certain time (ms)
50% 1269
66% 1330
75% 1367
80% 1396
90% 1479
95% 1563
98% 1688
99% 1756
100% 6188 (longest request)

Server running php-pm with php-7.2 using 4 workers

Document Path:          /images/img_growth.png
Document Length: 35908 bytes
Concurrency Level: 10
Time taken for tests: 20.929 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 36344000 bytes
HTML transferred: 35908000 bytes
Requests per second: 47.78 [#/sec] (mean)
Time per request: 209.291 [ms] (mean)
Time per request: 20.929 [ms] (mean, across all concurrent requests)
Transfer rate: 1695.83 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 65 68 2.2 68 81
Processing: 134 140 11.3 139 449
Waiting: 67 72 10.9 71 383
Total: 200 208 11.9 206 516
Percentage of the requests served within a certain time (ms)
50% 206
66% 209
75% 210
80% 211
90% 216
95% 219
98% 225
99% 234
100% 516 (longest request)

As you can see the difference between the results is crazy!

PHP-PM has shown to be almost 6x times faster in this particular case, we managed to deploy this improvement to production in less than a few hours with no additional code change, preventing us for rewriting that service in another lang for now which is huge win for us.

Let me know what you think!

Bonus Tip: If you are using AWS S3 like the source of you files, you can improve image read/get time by almost 2x, adding CloudFront for your bucket and use the HTTP adapter for the source instead of reading directly from the bucket, we are using this one: https://github.com/twistor/flysystem-http

--

--

Joe Cohen

Multipreneur passionate about technology, product, and customers with an engineer and designer background. I love helping to create and grow businesses.