My guess would be that your webapp is serving images in a blocking fashion, meaning every time a use requests an image it will fetch the image for the user AND block the http serving thread until the image is uploaded. Can you provide more context (eg: tech stack)?

What's blocking is number of http connections between browser and server. Most browsers only allow 6, each tile takes about 100ms so getting 10 in under second doesn't always happen.

But this itself wouldn't cause the "struggling" you mention with more than 2 concurrent users per core

Do you know if the old open street map trick of having multiple tile servers (that are each just aliases of the same server) still works? I think this was how they tried circumventing the 6 connection limit

That's no longer necessary thanks to HTTP/2

Your webserver still has to spin off a thread for each request if you want to do substantial CPU work for each request, but rest assured you'll get all the requests at once from the browser. Not 6 at a time like in the dark ages

The RFC recommends at least 100 streams. See SETTINGS_MAX_CONCURRENT_STREAMS https://tools.ietf.org/html/rfc7540#section-6.5.2

Have you tried combining the tiles on-the-fly as image sprites?

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Images/...

That's a lot of CPU usage per user! Is it doing some super-intensive process to generate the images on the fly?

Is it doing anything weird or fancy with those images?

If you're just serving them (eg no image manipulation), that sounds like there's a problem somewhere.

What http server do you use ? Are they static images ?