browsers make no more than 2 connections in parallel. so 2 images are being downloaded at the same time if the first 2 requests are taking long time to finish the 3rd and the 4th will take time to start.

Are you re-sizing the images on the fly? how about caching them? also how about getting images of size you need for that page. example: for thumbs view page request only 100px X 100px images not the whole thing.

astroanu said:

browsers make no more than 2 connections in parallel. so 2 images are being downloaded at the same time if the first 2 requests are taking long time to finish the 3rd and the 4th will take time to start.

You have a point although modern browsers seem to open more connections in parallel. Firefox 3+ has a limit of 6 connections which could explain the "steps" pattern with the timing of the first 6 images. But why does it stay at 450ms afterwards? Shouldn't the pattern of the first 6 images repeat? Else it would suggest that the 450ms response time is caused by all 6 connections being open.

Are you re-sizing the images on the fly? how about caching them? also how about getting images of size you need for that page. example: for thumbs view page request only 100px X 100px images not the whole thing.

I'm not altering the images, only checking for user permissions. The images are already resized thumbnails but are not cached in any way. As I said, the timings stay the same even if I don't do anything in the image controller (neither loading the image nor returning it) so it should be a "global" performance issue with lots of requests (of the same client?) at the same time.

Mostly looking at running your images through a optimizer and then using a front end cache to server the images.

Some fine tuning of nginx or varnish should get you into the lower segment of loading .

If you think there's a hidden bug in your code that hinders the performance i suggest you use a bench marking tool such as Xdebug.

astroanu said:

If you think there's a hidden bug in your code that hinders the performance i suggest you use a bench marking tool such as Xdebug.

I don't think there is a bug, really, only some performance bottleneck. Ultimately the bottleneck may be the hardware or the caching but I'd like to optimize the code first.

Profiling a single image request with Xdebug, I get an output like this in KCachegrind. Most of the time seems to be spent on internal Laravel stuff but looking at the callee map there seems to be a repetition of these two large blocks. Maybe one of them can be avoided but I can't really figure out what all of it means...