22 ms·

I have a web app that's struggling if there are more than 2 concurrent users per CPU core. It's displaying incompressible large resolution images with <100ms la

by yread 6y ago

I have a web app that's struggling if there are more than 2 concurrent users per CPU core. It's displaying incompressible large resolution images with <100ms latency EDIT: not sure why I'm downvoted, I'm just presenting my use case. They are multigigabyte images encoded with custom wavelet compression that are cut into tiles (think google earth), each user needs 5-10 tiles every second

csande17 6y ago
That's a lot of CPU usage per user! Is it doing some super-intensive process to generate the images on the fly?
deleted 6y ago
[deleted]
justinclift 6y ago
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.
matt42 6y ago
What http server do you use ? Are they static images ?
mping 6y ago
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)?
- yread 6y ago
  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.
  - brendawalsh 6y ago
    Have you tried combining the tiles on-the-fly as image sprites? https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Images/Implementing_image_sprites_in_CSS https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Images/...
  - durkie 6y ago
    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
    - NavinF 6y ago
      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 https://tools.ietf.org/html/rfc7540#section-6.5.2
  - mping 6y ago
    But this itself wouldn't cause the "struggling" you mention with more than 2 concurrent users per core

by yread 6y ago

csande17 6y ago

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

deleted 6y ago

[deleted]

justinclift 6y ago

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.

matt42 6y ago

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

mping 6y ago

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)?

yread 6y ago
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.
- brendawalsh 6y ago
  Have you tried combining the tiles on-the-fly as image sprites? https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Images/Implementing_image_sprites_in_CSS https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Images/...
- durkie 6y ago
  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
  - NavinF 6y ago
    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 https://tools.ietf.org/html/rfc7540#section-6.5.2
- mping 6y ago
  But this itself wouldn't cause the "struggling" you mention with more than 2 concurrent users per core